There are really two primary camps - RedHat based (CentOS, Rocky Linux, Amazon Linux, etc) and Debian based (Debian, Ubuntu, etc). There are of course many other bloodlines - but these are the most common in production environments and more specifically cloud env. If you are familiar with one version of linux that is RH based, you will tend to gravitate to others with similar DNA. Likewise, if you come from Debian/Ubuntu you will tend to stick with those. At the end of the day they are both Linux, but each has their own approach to configuration, where things go, package management, etc.
You really can't go wrong with either - use what you prefer.
FWIW, the real brunt of my question was why one would go with a cloud-provider specific operating system over one from a group like Canonical or RedHat, as I would naively expect it to have less support and particularly less ecosystem-wide understanding and experience while not being available for other systems, and so it would seem like an easily-avoidable source of vendor lock-in. If I were be part of Camp RedHat I would personally use CentOS, not "Amazon Linux", unless there was some extremely good reason why Amazon Linux in specific was awesome.
AWS’ flavor of Linux is open source, though. You can run it anywhere, not just Amazon. I don’t see this as a vendor lock in issue, personally.
Ideally you build your software such that the OS is just an implementation detail that’s abstracted away. In the server world a switch from RHEL to Ubuntu is not as hard as a move from, for instance, Google BigTable to AWS DynamoDB
Besides going the path of least resistance in AWS, possibly to get OS & package support from AWS if there's already an enterprise-level support plan in place, rather than needing to buy other support subscriptions (eg, RHEL)?
AM2 is able to run in other places so there doesn't seem to be much vendor lock-in compared to a service like DynamoDB, though.
It provides newer versions for a few key packages, e.g.: Docker 20.10, PostgreSQL 13, Ruby 3.0, Kernel 5.10, nginx 1.20, PHP 8.0, Python 3.8, Redis 6.2, Go 1.15, Rust 1.47, etc.
Some newer packages, e.g. OpenSSL 1.1.1 and zsh 5.7 are provided in the main repo.
Outdated packages wasn't a major pain point in my experience. The bigger issue is a relative small selection of packages.
These are either available via 3rd party repos (e.g. NodeJS) or EPEL (e.g. libsodium), or by recompiling Fedora SRPMS. That can be an inconvenience, but not a big deal overall.
I hope the situation will improve once AL2022 is out, as Fedora comes with a much wider selection of packages.
...and with this new version, a great support for SELinux too (because of Fedora). Some don't like the push for Snaps as well.
I think SELinux is one of the biggest differences and the hardest to adapt to (as changing apt to dnf is not hard).
If you want a good starter on SELinux, my whole book on deployment[0] is SELinux ready with a full dedicated chapter on SELinux and a SELinux cheatsheet. Today also with a 33% off for Black Friday ("blackfriday" discount code at checkout).
I would prefer Fedora, but if I am on AWS and Amazon Linux is the one that gets the awesome Amazon support, then choosing Amazon Linux might be compelling.
Of course I would prefer they use Fedora and contribute to Fedora directly.
