AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

We maintain a large number of PHP applications on Elastic Beanstalk, many of them built on Yii, and we're already working through scheduled updates from PHP 8.2 to 8.4 across them. This retirement is fairly routine, but there are a couple of details in the email that are easy to miss.

What "retire" actually means

From March 31, 2027, the PHP 8.2 on 64bit Amazon Linux 2023 platform branch is marked as retired. Under the Elastic Beanstalk platform support policy that means:

• Elastic Beanstalk stops providing maintenance updates for the branch, including security updates.
• AWS no longer provides technical support for it.
• The branch disappears from the Elastic Beanstalk console for creating new environments. Existing environments get a 90 day grace period, and can still be cloned or rebuilt through the CLI and API.

Your existing environments keep running and AWS doesn't delete anything, but from then on nobody is patching the platform underneath your application.

The date that matters more is December 31, 2026

We'd plan around an earlier date than the one in the email, because PHP 8.2 itself reaches end of security support on December 31, 2026, three months before Elastic Beanstalk retires the platform branch.

From January 1 the PHP project stops releasing fixes for 8.2, so any vulnerability found in the language after that date stays unfixed, whatever AWS does with the platform. For an application that handles customer data or payments, we'd treat the end of December as the real deadline. Auditors and cyber insurance questionnaires increasingly ask about unsupported runtimes, so it's often a compliance question as well as a technical one.

Which PHP version should you move to?

The email lists three PHP versions to move to, each with a different amount of support left:

PHP 8.3 is the smallest jump from 8.2, but it only buys about a year before you get this same email again. We generally recommend going to PHP 8.4, or PHP 8.5 if the application's dependencies already support it. The extra testing tends to be a modest cost compared with doing the whole exercise twice.

It isn't a button in the console

Elastic Beanstalk can update a platform version in place, but only within the same platform branch. PHP 8.2 to PHP 8.4 is a different branch, and AWS recommends a blue/green deployment for that: build a new environment on the new branch, deploy the application to it, test it, then swap the CNAMEs so traffic moves across. Done properly, your users shouldn't notice any downtime.

The infrastructure side is usually the easy part, and we find most of the time goes on the application itself. PHP 8.2 to 8.4 sounds like a minor version bump, but each release changes enough that application code sometimes needs modifying. PHP 8.4 deprecates implicitly nullable parameter types, a pattern that's all over older codebases, and both 8.3 and 8.4 tighten up behaviour that older code and libraries depend on. Across the updates we've done so far, the work tends to fall into the same few areas:

• Test coverage - before changing anything, we make sure the application has a running test suite and that it's green on PHP 8.2. Without that, there's no reliable way to tell whether the upgrade broke something or it was already broken.
• Composer dependencies - older packages may not declare support for newer PHP versions, and some will need upgrading or replacing before composer install will even run.
• Framework versions - an application on an old release of Yii, Laravel or Symfony may need a framework upgrade before it will run cleanly on PHP 8.4. We've written about the bigger version of this in migrating from Yii 1 to Yii 2.
• Deprecation notices - each PHP release deprecates a few more behaviours. They rarely break anything immediately, but they can flood the logs and hide real errors.
• .ebextensions and .platform hooks - custom configuration, installed packages and PHP extensions all need checking against the new platform.

For a typical SME application, we'd usually expect this to be a few days of work rather than weeks, but it varies a lot with how long the code has gone without maintenance.

Finding your affected environments

The quickest place to look is the Affected resources tab of the AWS Health Dashboard event the email links to. The Elastic Beanstalk console also shows a Platform state column on the Environments page.

If you'd rather use the CLI, this lists every environment on the retiring branch in one region. The example in the AWS email points at us-east-1, so change the region to wherever your environments actually live:

aws elasticbeanstalk describe-environments \
  --region eu-west-2 \
  --query "Environments[?contains(PlatformArn, 'PHP 8.2 running on 64bit Amazon Linux 2023')].[EnvironmentName,PlatformArn]" \
  --output table

The email is sent per account and per region, so if you run several AWS accounts, check each one. Forgotten staging environments are often where these old platforms hide.

Still on Amazon Linux 2?

If your environments are on an Amazon Linux 2 platform rather than Amazon Linux 2023, they're already retired: AWS retired every AL2 platform branch on August 6, 2026. Moving from AL2 to AL2023 is a bigger change than a PHP version bump, because the operating system changes too, so we'd do both together and going straight to PHP 8.4 or 8.5 on AL2023.

What happens if I ignore it?

At first, not a lot. The environment keeps serving traffic and nothing visibly changes on March 31.

The risk builds up over time, though, with no security patches from PHP after December and none from AWS after March. AWS also warns that an Elastic Beanstalk API action may eventually stop working for an environment on a retired branch, which would be an awkward thing to discover while trying to deploy an urgent fix.

If you don't have the in-house capacity to make the upgrade, get in touch. We're an AWS Partner based in Manchester and we do this kind of PHP and Elastic Beanstalk upgrade work regularly, whether that's a one-off migration or ongoing support and maintenance.