Elastic Beanstalk AL2 Platform Branch Retirement Before June 30, — when and how should I migrate?
Elastic Beanstalk teams need to choose between platform-branch upgrades, Docker-based escape hatches, or platform exit before all AL2-based branches retire no later than June 30, 2026.
Blockers
- capability/elastic-beanstalk-al2-platform-branches — EOL 2026-06-30
- Lock-in via vendor/aws
- Lock-in via vendor/aws
- format/dockerrun-aws-json-v3 incompatible with format/dockerrun-aws-json-v2
- format/dockerrun-aws-json-v3 incompatible with format/dockerrun-aws-json-v1
Who this is for
- low-ops
- cost-sensitive
- small-team
Candidates
Upgrade to a supported Elastic Beanstalk AL2023 managed branch
AWS states that all Elastic Beanstalk AL2-based platform branches retire no later than June 30, 2026, because Amazon Linux 2 reaches end of life then. As of 2026-04-09, Elastic Beanstalk itself has no additional charge; you pay only for the AWS resources the environment uses. The lowest-friction path is usually moving to the matching AL2023 managed branch if one exists and is still within a meaningful support window. The blocker is that some AL2023 branches are also near retirement or already retired: for example PHP 8.1 AL2023 retired on March 31, 2026, while Node.js 20 AL2023, Python 3.9 AL2023, and Ruby 3.2 AL2023 are scheduled for July 31, 2026.
When to choose
Use this when you want the smallest operational change and your app fits a current first-party EB runtime. It is the best option for low-ops teams only if the target AL2023 branch is current enough that you are not immediately facing another migration.
Tradeoffs
Keeps Elastic Beanstalk workflows, health model, and managed platform experience. The downside is limited runway on some language branches and dependence on AWS's branch cadence rather than your own container image lifecycle.
Cautions
Do not assume 'move to AL2023' is sufficient by itself. You must verify the exact target branch retirement date first, because some AL2023 branches have already retired or are scheduled only weeks after the AL2 cutoff.
Standardize on the Elastic Beanstalk Docker AL2023 branch
AWS documents Docker support on both the Docker AL2 and Docker AL2023 branches, including single-container and Docker Compose based deployments. As of 2026-04-09, Elastic Beanstalk still adds no platform fee beyond underlying AWS resources, so this keeps the same pricing model while giving teams an image-based escape hatch from language-branch churn. AWS documentation shows Docker Compose support and `Dockerrun.aws.json v3` for Docker AL2 and AL2023, while non-Compose deployments use `Dockerrun.aws.json v1`. This path is usually the cleanest way to stay on Elastic Beanstalk when the app runtime is drifting faster than AWS-managed language branches.
When to choose
Use this when you want to remain on Elastic Beanstalk but need tighter control over runtime, build tooling, or multi-service packaging. It is decisive when your blocker is runtime/version availability rather than Elastic Beanstalk itself.
Tradeoffs
You keep EB environment management and pricing simplicity, but you take on more responsibility for image creation, dependency patching, and container-level operations. It reduces platform-branch lock-in, but not service-level lock-in to Elastic Beanstalk.
Cautions
This is not the old AL1 multicontainer path. AWS documents Docker Compose on the Docker platform and uses `Dockerrun.aws.json v3` for Compose, while ECS-based Elastic Beanstalk environments use `Dockerrun.aws.json v2`, so packaging conventions differ.
Exit Elastic Beanstalk and replatform to AWS App Runner
AWS's decision guide positions App Runner as one of the separate AWS container services teams can use instead of self-managing containers on EC2 or staying on Elastic Beanstalk. As of 2026-04-09, App Runner pricing in major regions including US East, US West (Oregon), and Europe (Ireland) is $0.007 per GB-hour for provisioned memory and $0.064 per vCPU-hour for active instances; billing is per second, with a one-minute minimum charge for vCPU each time a provisioned instance starts processing requests. App Runner automatically scales active container instances up and down and exposes explicit CPU and memory configurations. This is the clearest EB exit if you want managed containers without continuing to ride Elastic Beanstalk platform-branch retirements.
When to choose
Use this when the real issue is Elastic Beanstalk platform policy, not just AL2. It fits small teams that can package the app as a container and want a managed service with explicit usage-based compute pricing instead of EB plus EC2 plus load balancer composition.
Tradeoffs
You remove Elastic Beanstalk branch retirement pressure and move to a container-native service with autoscaling. The cost model changes materially, and you must rework deployment, configuration, and operational assumptions around App Runner rather than EB environments.
Cautions
Budgeting changes because App Runner charges for provisioned memory while idle and active vCPU while serving traffic. If you need exact EC2-style cost control or broader container orchestration features, compare App Runner against other AWS container services before committing.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Elastic Beanstalk AL2 Platform Branch Retirement Before June 30, — when and how should I migrate?"