Amazon Linux 2022 was recently opened to Public Preview during pre:Invent 2021. There's a lot of interesting nuances compared to Amazon Linux 2, so I wanted to consolidate the differences and provide some personal opinions.
This was also all written at time of the announcement of Public Preview, so things are liable to change ahead of General Availability.
Built on Fedora instead of CentOS
Amazon Linux has traditionally been built around CentOS. With the transition from its standard release cycle to CentOS Stream, Amazon has decided transition to using Fedora as the base for Amazon Linux 2022, with the kernel from the Linux LTS versions.
Personal opinion: CentOS Stream is a bad choice for production use, and Amazon made a good decision to not try and shoe-horn it into Amazon Linux. Fedora also makes sense since it was already the upstream origin of CentOS anyway, so we're still in the same ecosystem. We've just cut out a few steps.
Fedora has a well-established lineage, and with the other changes Amazon has made in relation to the OS, it's arguably one of the best choices they could make. But one thing seems to puzzle people:
Rocky Linux is a newer distribution in the Linux Family, intended by the community as a successor to CentOS and its original intent. It's also backed by AWS, among others, including traditional rivals like Microsoft Azure and Google Cloud.
"Why not base Amazon Linux 2022 on Rocky?". I can only speculate, but being a relatively new distribution, and intended for use by Amazon's customers, who are primarily businesses, the longer-term stability and reliability of Fedora, along with being closer to the top of the stream probably makes the most strategic sense in November 2021.
In future? It wouldn't entirely surprise me if we have Amazon Linux 2024 powered by Rocky Linux (heard here first!), but nothing yet guaranteed.
Release Cycle
One thing that distinguishes Amazon Linux 2022 from Fedora is its release cycle. Amazon have announced a release cycle of a new major version every two years, minor versions every three months with LTS for five years.
In a world of daily builds and releases, five years might sound like a long time. But in the world of operating systems and servers, it's truly not. Since a server's OS should be in support for the life of the server being in production, that means the deployment effectively won't be safe to use beyond five years when the security updates cease.
So, is five years long enough? My opinion: Yes, if your solutions are built for it.
Building modern cloud-native applications, where the underlying servers are treated purely as cattle, and it's being actively developed and maintained? Sure, five years is good. You effectively have major n+2 until support stops, and will probably be able to keep pace.
If you're looking at running long-term applications that may not be under active development? Then you'd want to prioritize support cycle even further.
To the very best of my knowledge, and based on linuxlifecycle.com, without paying for RHEL or SUSE, five years is as long as you're going to get in support for a Linux distribution nowadays (except Ubuntu for personal use). And if you truly need it, forking out for RHEL is may still worth it for that.
Version Locking
Latest versions aren't always the best. When running a fleet of servers using heterogeneous versions of software, you can end up with very unusual problems. Instead, you have full power to control the versioning of the repository.
By locking to a specific version of the Amazon Package Repository, this means you should have a very predictable and consistent experience, regardless of what your servers are doing.
There is one very interesting thing worth mentioning: Security Updates aren't installed by default upon launch. Sysadmins breathe out, Infosec breathes in.
Security Updates are a vital part of server management, and cannot be ignored, especially in production environments. But, and sysadmins will know this in their bones, Security Updates can break stuff. Not often, but it does happen. And arbitrary updates can decrease that predictability.
The same principle works both ways: You control the patching. For better, and worse, it's in your hands. But this isn't a new concept.
SELinux - Enforced by Default
Plenty of people probably groaned at the sound of this. Yes, SELinux makes stuff less permissive, but that's the whole point, and it's 2021 for goodness sake. Indeed, there are still applications out there where the developers will specify "SELinux has to be disabled for this to work".
For context, Security-Enhanced Linux (SELinux) is an enhancement to the Linux kernel to provide finer-grained access control within the OS. This helps contain individual programs and daemons. For example, if a single machine ran both a web server and a database server, SELinux helps ensure the database couldn't be compromised, even if someone exploited the web server daemon.
SELinux of 2021 is not SELinux of the 2000's - it's come a long way since then. The tooling is much better, and one of the nice things about more atomic servers is that there's a lot less cases of servers trying to run half a dozen different services, since compute was at a premium.
At the end of the day, yes, you can disable enforcement. But the amount of resources to make it easier now is remarkable, much of the bad reputation is dated, and I seriously doubt you have a good reason to disable SELinux in modern deployments.
What about Amazon Linux 2?
Amazon Linux 2 is due to reach the end of LTS Support by June 30, 2023 according to its FAQ. There's nothing in this announcement to suggest that this will be changed, and I seriously doubt they would move the date forward. Although if you're running workloads on it, it's soon going to be time to think about "where to next?".
The upgrade path, not too surprisingly given the difference in architecture, is "replace and rebuild". Their FAQ promises an in-place upgrade guide once AL2022 reaches GA, which given the architecture differences would be a sight to behold.
So with only 19 months or so until the end of support for Amazon Linux 2, you probably want to have a new OS designated by December 2022 at the latest; hopefully by which time, AL2022 should be much more mature, and stable in GA.
Conclusion?
"It isn't Red Hat!". Nope, nor is it trying to be. It's not the ultra-stable enterprise distribution with decade-plus support. But it's not trying to be a replacement for Red Hat; just a well-built stable operating system for cloud-native deployments.
With a few bugs already bubbling up on the Twittersphere, there's still work to be done, and they're opting to track bugs and feature requests through the amazon-linux-2022 GitHub repository.
If you're already running Amazon Linux 2 or a similar Fedora-based built, including CentOS, once it's released to GA, AL2022 may be a worthwhile solution for several years.
Top comments (3)
AL has never been built off CentOS. AL1 was mostly built from RHEL6 source code, with RHEL7 and Fedora backports. AL2 was mostly built from RHEL7 source code, with RHEL8 and Fedora backports.
Amazon folks have confirmed the shift to base solely on Fedora had nothing to do with the CentOS Stream change. With the new lifecycle of a new major version every two years, it's clear that the choice of Fedora was because they wanted to move faster than CentOS and RHEL, which have a new major version every three years. That's also why your suggestion of AL2024 being based on a RHEL clone doesn't make any sense, as that would be a regression from these changes.
On the point about AL2024, that's me making a complete hip-shoot, and based on how fast the sector changes, anything is possible. As I've said, basing on Fedora is the wisest option anyone could take at this time, but the future remains an unknown. We don't even have AL2022 in GA yet.
Fedora wanting to move faster than its downstream makes total sense, and I don't believe I disputed that. But for running production systems, longer lifespans and stability usually make far more sense, and despite the fact it isn't as long as CentOS's original 10 years, the five year cycle brings it up in-line with most other major distros used in production that doesn't have commericial licensing.
As for the backporting of RHEL as the source, that's something I'll explore more and if necessary, issue amendments, since it's worth confirming for the completeness of the narrative.
Thanks for your thoughts on the subject, it's good to get perspectives from others with deep interest in the subject, mate 🙌
Sure thing, happy to provide clarity where I can.
My comment about wanting to move faster was referring to AL2022, not Fedora. Fedora moves the fastest (new version every 6 months), AL the second fastest (new version every 2 years), and CentOS/RHEL the slowest (new version every 3 years). Basically my take away was that AL wanted to move faster than the 3 year cycle that basing on RHEL gave them, which is why the Stream changes weren't a factor.