How to Migrate to Amazon Linux 2027: Full Tutorial

If you want to migrate to Amazon Linux 2027 before everyone else figures out it’s worth the trip, now’s your window. AWS just dropped the public preview, it’s free to poke at, and this tutorial walks you through the whole thing: launch a preview instance, install your packages, move a containerized app over, and prove — with actual command output, not vibes — that it behaves exactly like the AL2023 box it’s replacing.

AL2027 isn’t a cosmetic point release. It runs on kernel 7.1+, it’s built on the AL2023 baseline so your muscle memory mostly still works, and AWS is pitching it for the stuff that actually runs the internet: web apps, databases, containerized microservices, and AI/ML workloads. The announcement showed up in the AWS Weekly Roundup for September 7, 2026, alongside the official “Announcing Amazon Linux 2027” post. It’s a preview, so treat it like one: dev and test workloads, nothing you’d stake an on-call rotation on just yet.

Why bother now instead of waiting for GA? Because the whole point of a public preview is that you get to find the rough edges before they’re your production rough edges. If your fleet is still on AL2023 — which, fine, most fleets are — this is the cheapest possible way to see what a kernel jump from 6.1 to 7.1 actually changes for your specific app, instead of reading a changelog and hoping for the best. Worst case, you spin the instance down and you’re out twenty minutes. Best case, you walk into next year’s OS upgrade cycle already knowing exactly what breaks and what doesn’t.

What You Need Before You Migrate to Amazon Linux 2027

• An AWS account with permission to launch EC2 instances (ec2:RunInstances, ec2:DescribeImages, and the usual suspects)
• AWS CLI v2 installed and configured, either via aws configure or an SSO profile
• An existing AL2023 EC2 instance or AMI running your workload today, so you actually have a baseline to compare against
• A Dockerfile or container image for the app you’re moving — we’ll use plain nginx below if you don’t have one on hand
• An IAM role with the AmazonSSMManagedInstanceCore policy attached, if you’d rather connect over Session Manager than fight with SSH keys
• Basic comfort with SSH or SSM, and enough Docker to not flinch at a Compose file

The Migration, Step by Step

1. Find the AL2027 preview AMI. Amazon Linux AMI IDs are published through Systems Manager Parameter Store instead of making you hunt through the console, which is one of the few genuinely good defaults in EC2. Query for the preview parameter:

   aws ssm get-parameters-by-path \
     --path "/aws/service/ami-amazon-linux-latest" \
     --query "Parameters[?contains(Name,'al2027')].Name" \
     --output table
   

   Then pull the actual AMI ID out of it:

   aws ssm get-parameter \
     --name /aws/service/ami-amazon-linux-latest/al2027-ami-kernel-default-x86_64 \
     --query "Parameter.Value" --output text
   

   If the parameter isn’t visible in your region yet, check the EC2 console AMI catalog and filter for “Amazon Linux 2027 preview” instead — preview rollouts don’t always land in every region on day one. Details on this pattern live in the Parameter Store public AMI parameters guide.

2. Launch the instance. Nothing fancy — same run-instances call you’d use for AL2023, just pointed at the new AMI:

   AMI_ID=$(aws ssm get-parameter \
     --name /aws/service/ami-amazon-linux-latest/al2027-ami-kernel-default-x86_64 \
     --query "Parameter.Value" --output text)
   
   aws ec2 run-instances \
     --image-id $AMI_ID \
     --instance-type t3.medium \
     --key-name my-keypair \
     --security-group-ids sg-0123456789abcdef0 \
     --subnet-id subnet-0123456789abcdef0 \
     --iam-instance-profile Name=SSM-EC2-Role \
     --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=al2027-preview-test}]'
   

   Full flag reference is in the EC2 launch instance documentation, and if you want a side-by-side of what the AL2023 flow looks like, the AL2023 launch guide is basically the same steps with a different AMI ID.

3. Connect to the instance. Session Manager skips the whole key-pair-and-security-group dance, so use it if your IAM role is set up:

   aws ssm start-session --target i-0123456789abcdef0
   

   Or, if you’d rather do it the old-fashioned way:

   ssh -i my-keypair.pem ec2-user@<public-ip>
   

   See the Session Manager user guide if you haven’t wired up the IAM role before.

4. Check the kernel and OS release. This is the whole point of the exercise, so don’t skip it:

   uname -r
   cat /etc/os-release
   

   You should see a 7.1.x kernel and a PRETTY_NAME referencing Amazon Linux 2027 (preview). Run the same two commands on your AL2023 instance and you’ll get a 6.1.x kernel and “Amazon Linux 2023” — that diff is your entire migration story in two lines.

5. Install packages with dnf. AL2027 keeps the dnf-based package manager from AL2023, so this part will feel boring in the best way:

   sudo dnf update -y
   sudo dnf install -y docker git
   

6. Enable Docker and get out of root’s way.

   sudo systemctl enable --now docker
   sudo usermod -aG docker ec2-user
   

   Log out and back in (or run newgrp docker) so the group membership actually applies, then confirm the daemon is alive:

   systemctl status docker --no-pager
   

7. Move your sample containerized app over. If you’ve got a Compose file for the app you’re migrating, copy it up and run docker compose up -d. If you just want a clean smoke test, plain nginx does the job:

   docker run -d --name web-al2027 -p 80:80 nginx:latest
   docker ps
   

   This is the exact command you’d have run on the AL2023 box, unchanged. That’s the entire migration for a stateless container — no rewritten Dockerfile, no new base image, no drama.

8. Validate against the AL2023 baseline. Don’t just eyeball it — pull the same evidence from both boxes and diff it in your head:

   curl -I http://localhost
   systemctl status docker --no-pager
   docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
   

   You’re looking for a matching HTTP/1.1 200 OK, the same nginx version header, an active Docker daemon, and a container reporting “Up” with the same port mapping you had on AL2023. If all four match, your containerized workload doesn’t care which kernel is underneath it — which is exactly the outcome you want from an OS upgrade.

What You Built

You now have a running Amazon Linux 2027 preview instance, provisioned the same way you’d provision any EC2 box, with Docker installed via the same dnf workflow AL2023 users already know. You moved a containerized app onto it without touching the container image, and you validated — with actual curl output and docker ps status, not hope — that the app behaves identically to its AL2023 counterpart. That’s the real headline here: AL2027 gives you a newer kernel and a forward-looking baseline without forcing you to relearn how to run your own infrastructure.

At Enkompass (enkompass.net), this is our home turf. We’ve already run this exact AL2023-to-AL2027 migration path against real containerized workloads in preview, so we know where the rough edges are before your production fleet ever finds them. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.