The end of standard support for Amazon Linux 2 was June 30, 2026 – which has now passed. If you are still running AL2-based Storage Gateway appliances, you are in the unsupported window, and here’s how to remediate: the method AWS supports, and the operational lessons that make it go smoothly.

If you run AWS Storage Gateway, one deadline already changed your roadmap — and it’s in the rearview mirror: *Amazon Linux 2 (AL2) will reach end of standard support on June 30, 2026. * That date has passed so any AL2-based gateway appliance in operation is no longer receiving software updates, security patches or bug fixes. You can keep running them but now the upkeep of them is your problem and in any environment where there is a compliance or audit obligation, each day in this window is adding up exposure.

Storage Gateway is worth calling out specifically because it does not behave like a normal EC2 workload in this transition. For a simple EC2 instance you might re-bake an AMI and redeploy. For Storage Gateway, there is no in-place upgrade path from AL2 to AL2023 — the appliance OS is managed by AWS, and you move to AL2023 by replacing the underlying instance of the gateway, not patching it.

This is a guide to planning and lessons learned, not a runbook with exact click-by-click instructions (the exact commands are in AWS’s own docs and I link to them below). The idea is to give you the shape of the migration and the operational judgment around it, so whether it’s one gateway or a fleet, you go in with your eyes open.

The time line and where we are now

AWS had a particular migration campaign. All these dates are now in the past but it is useful to have them in front of you to understand the current state:

  • October 28, 2025 — new gateway deployments from Storage Gateway console started to default to AL2023 images.
  • January 5, 2026 — AWS started limiting new AL2 gateway activations.
  • June 30, 2026 — No software updates for AL2 based gateways and no AWS support.

This change applies to all versions of AL2-based appliances in the S3 File Gateway, Tape Gateway, and Volume Gateway families. That final date has passed so any AL2 gateway you’re still running is in the unsupported window right now, so this is no longer “planned work” it’s remediation and should be prioritized accordingly. Sequence by risk (internet facing and compliance critical gateways first) and work the fleet down systematically.

How to identify affected gateways

Take a careful inventory before you make any plans. AWS gives you 3 different ways to identify gateways to be migrated and I would use more than one to crosscheck:

  • In the Details tab of the affected gateway, the AWS Console displays a deprecation message.
  • The DescribeGatewayInformation API exposes a deprecation-date field, which is the programmatic way to sweep many gateways at once.
  • In the AWS Health Dashboard, on the Affected resources tab, you can view the affected gateways.

If you have more than a handful of gateways, the API is your friend, script the check across every account and Region rather than clicking through consoles. These migrations have one thing in common. They fail because they don’t take inventory. You can’t migrate the gateway you forgot about.

Migration approach supported

AWS documents a replacement procedure for an S3 File Gateway that retains the cache disk and the current gateway ID. The important part here is to keep that gateway-ID; it is what keeps your file shares, their names and their configuration during the move. Conceptually the flow is:

  1. Stop the applications through the gateway so that nothing is writing during the swap.
  2. Deploy a new AL2023 gateway instance from the latest gateway image.
  3. Detach the cache disk(s) from the old instance and attach to the new instance.
  4. Make the migration API call to take over the existing gateway ID and configuration on the new instance.
  5. Check result — shares are there, available, and healthy.

There are two constraints from the docs: data can only be moved between the same gateway type and the documented migration steps are for appliance version 2.x and cannot be used for older versions, so part of your pre-work might be getting the current version first.

I am intentionally not reproducing the exact console clicks and API parameters here, because AWS keeps the authoritative version current. Replace your existing S3 File Gateway with a new instance Begin with the "Storage Gateway AL2 to AL2023 Migration Campaign" pre-migration checklist (linked at the end) and adhere to them to the letter.

If you have more than a few, automate it

The stop-detach-attach-migrate-verify dance is fine manually for one or two gateways. It’s slow and error-prone across dozens or hundreds – across multiple accounts and Regions.

AWS has released a migration example inside the Storage Gateway Terraform module that automates the AL2-to-AL2023 upgrade, and a corresponding Ansible playbook that orchestrates the disk-swap and migration API steps. That combination provides you a repeatable, auditable, scalable path for an entire fleet. If you are running at any kind of real scale, think about the IaC route before you engage an engineer to do weeks of manual cutovers. The auditability alone (a git history of exactly what changed, when) is worth it in a regulated shop.

The important lessons you need to know

The above mechanics are the easy 20%. Here’s where migrations succeed or are held up: broad principles that apply far beyond Storage Gateway.

  1. The single most important thing for your whole cutover is the gateway

The migration replaces the underlying instance, so the IP address for the gateway changes. Whether that turns out to be a non-event or fire drill depends on one question: do clients connect by DNS name, or by hardcoded IP address?

  • Clean DNS clients. A new instance pops up, you just repoint one DNS record during the maintenance window, and clients keep using the same hostname: they never know anything moved. -The painful case is IP-hardcoded clients. New IP means every client pointing at the old address is now pointing at nothing until it gets updated. Those updates tend to live with a different team, on a different schedule, dragging their timeline into yours.

*Before you migrate anything, inventory how each client connects. And make the migration the forcing function to replace a raw IP with a proper DNS name anywhere you still have raw IPs — so the *next lifecycle event is a one-line DNS change instead of a fleet-wide push. This is the most high-leverage habit in the whole exercise.

2. Don’t modify the old instance, treat it as immutable infrastructure

The best mental model for this kind of migration is replace, don’t modify.* Your old AL2 instance is your rollback baseline, This is exactly how you break the thing you were trying to preserve. Little OS level tweaks to a production appliance to "make it work". Build the new AL2023 instance clean, cut over, and leave the old one untouched as your safety net.

3. You’re rolling back to the old instance, so don’t kill it prematurely

The biggest comfort of the replace-and-reserved strategy is that *your back-out plan is "the old instance is still sitting there, stopped. * You moved its cache disks out, but the instance itself is okay.

Make it a rule to leave the old instance stopped for a period of time after cutover — long enough so that if a problem arises a day or two later under real load, you can still roll back without having to provision from scratch. A few weeks of EBS storage and you can sleep. Document the retention window in your change plan, so a well-meaning cleanup process doesn’t kill your safety net three hours after cutover.

4. Different Approaches for State and Stateless Workloads

Storage Gateway is stateful - there's cache data to preserve - so that's why the disk-and-gateway-ID method exists. If your broader AL2 estate includes other workload types, don’t apply one playbook to all:

Stateful EC2: multiple instances, data sync verified, DNS cutover managed.

  • Auto Scaling Groups: Deploy a new AL2023 AMI with a canary and a guarded instance refresh.
  • EKS nodes: add AL2023 node groups, stop new pods from scheduling on AL2 nodes, verify cluster add-ons (VPC CNI, CoreDNS, kube-proxy) are compatible with AL2023 AMIs, then cordon/drain/remove the AL2 nodes once stable.

The through-line: introduce the new, validate under real conditions, remove the old last - keep rollback available until final step.

5. Validation is a checklist, not a gut feeling

“The shares are back” is not a status. Decide ahead of time what proven healthy looks like — the share is reachable, the correct share list is present, a test read and write both succeed — and write those checks into the runbook so that any engineer running the cutover knows the exact bar for success. This is even more important when you automate: your playbook should assert health, not assume it.

6. Map the human dependencies before the technical

AWS steps are easy to learn in an afternoon. The one thing you can't shortcut is the web of people a cutover touches: whoever owns DNS, whoever pushes config to IP-hardcoded clients, the application owners who need to validate afterward (and be told in advance their shares will blink), and AWS support or your TAM for the higher-stakes waves. Draw that dependency map per gateway before you touch anything and make “who has to act inside my maintenance window” a first class part of the plan.

7. Beyond the deadline – Risk sequence and deliberate move

The technical work per gateway is small; it is the organizational run to schedule production changes across teams that takes time. But with June 30, 2026 in the rear view, there’s no “early” to be anymore — but that’s no reason to rush sloppily. The right answer is to triage: identify which gateways are most at risk in an unsupported state (internet facing, compliance scoped, highest data sensitivity), and book the change windows for those first, working down the fleet in a controlled sequence. Compressed urgency + organized order > either panic or complacency.

The takeaway

Amazon Linux 2 is now at the end of standard support and we have passed the deadline. Are AL2-based Storage Gateways still out there? The good news is that the technical migration to AL2023 is really not the hard part — AWS’s replace-and-preserve method keeps your gateway ID, cache data, and share configuration intact, and there’s now IaC tooling to run it at fleet scale.

The hard part is everything else: knowing exactly which gateways are affected, how clients actually get to them (DNS or IP), keeping a real rollback path alive through cutover, and coordinating the humans whose actions land within your maintenance window. Follow the mechanics in the AWS docs and the OS swap becomes the easy step it should be. Expect those.

Reliable sources

  • Storage Gateway AL2 to AL2023 Migration Campaign (pre-migration checklist, timeline, impacted versions) — docs.aws.amazon.com/filegateway/latest/files3/al2-to-al2023-migration.html.
  • Creating a new file gateway instance to replace your existing S3 File Gateway (supported method) — docs.aws.amazon.com/filegateway/latest/files3/migrate-data.html -Scale your AWS Storage Gateway AL2023 migration with infrastructure as code (Terraform + Ansible) — aws.amazon.com/blogs/storage/scale-your-aws-storage-gateway-al2023-migration-with-infrastructure-as-code/
  • Migrate an EC2 instance from AL2 to AL2023 (general EC2 guidance) — `repost.aws/knowledge-center/al2-migrate-al2023

Always refer back to the current AWS documentation for exact steps — dates, image versions, and procedures are updated, and the docs are the source of truth.