AWS's decision to ship Amazon Linux 2027 in public preview with SELinux enforcing by default is not a small step. It is a deliberate and long-overdue bet on the idea that the default Linux environment for cloud workloads should be secure by design, not just by configuration. For readers who have spent years treating SELinux as a nuisance to disable on first boot, this is the moment to stop ignoring it. The preview is built on the AL2023 baseline with kernel 7.1, but the kernel version is not the story. The story is that AWS has drawn a line in the sand: if your application cannot survive under SELinux enforcing, Amazon Linux 2027 is not for you yet. That is a strong position, and it is the right one for a platform that wants to be taken seriously in regulated industries and multi-account architectures.
But let's be honest about what this means in practice. The announcement gives no end-of-support date for AL2023, no GA date for AL2027, and no in-place migration path. That combination is not an oversight; it is a signal. AWS is telling you to plan for a rebuild, not a lift-and-shift. If you are running on AL2023 today with SELinux in permissive mode, you might be lulled into thinking you are close to ready. You are not. Permissive mode logs denials but does not block them, so your application may be silently relying on rules that will break under enforcing. The gap between "logs a warning" and "blocks the operation" is exactly where production incidents are born. We would tell any reader who asks: assume your current AL2023 image will fail under AL2027 unless you have explicitly tested it with SELinux in enforcing mode. Do not wait for the GA announcement to start that validation.
This move also forces a broader conversation about how we treat security defaults in cloud infrastructure. For years, the industry has leaned on the "secure by default" phrase while shipping systems that require users to opt into the hard parts. Amazon Linux 2027 flips that script by making the hard part the default and letting users who need relaxed policies opt out. That is a progressive approach, but it comes with a cost. It means that the path from AL2023 to AL2027 is not a smooth upgrade; it is a migration project with a security audit attached. For teams that have been running the same AMI for years, this is a wake-up call to modernize their deployment pipelines, their configuration management, and their testing practices. The good news is that this pressure is productive. It forces you to understand your application's actual network and file-system behavior, which is knowledge you should have anyway.
The specific detail to watch is AWS's silence on the AL2023 end-of-support date. That date will define the urgency of your migration. If AWS extends AL2023 support for years, the pressure to adopt AL2027 early is manageable. If the date lands sooner than expected, you could be scrambling. Our advice is to track that date as if it were a compliance deadline, because for many teams it will be. In the meantime, start a small proof-of-concept with AL2027 in a non-production account, turn on SELinux enforcing, and watch your logs. The applications that pass that test are the ones you want in your future. The ones that fail are the ones you need to fix now, not later. That is the concrete takeaway: treat this preview as a compatibility test for your entire estate, not as a curiosity to admire from a distance.