Migrating the Swift AWS Lambda archive plugin default from Amazon Linux 2 to Amazon Linux 2023

Migrating the Swift AWS Lambda archive plugin default from Amazon Linux 2 to Amazon Linux 2023

Hey everyone,

We're working through how to transition the swift package archive plugin's default build image from Amazon Linux 2 to Amazon Linux 2023 in swift-aws-lambda-runtime.

Context: Amazon Linux 2 reaches end of life in June 2025 2026. The recommended Lambda runtime is now provided.al2023. Swift 6.3+ Docker images are available for AL2023 on Docker Hub.

The problem: This isn't just a toolchain swap. Binaries built on AL2023 link against glibc 2.34 and OpenSSL 3.x at the system level. If someone deploys an AL2023-built binary to a provided.al2 Lambda (which has glibc 2.26 and OpenSSL 1.1), it will crash at runtime. There's no compile-time signal that anything is wrong.

Our current plan:

  1. Keep amazonlinux2 as the default for now to avoid breaking existing deployments
  2. Print a visible warning when building on AL2, recommending users switch to AL2023
  3. Provide an explicit flag (something like the existing --base-docker-image swift:amazonlinux2023) to opt in
  4. Detect when the plugin is already running inside an AL2023 environment and skip the AL2 pull in that case
  5. Flip the default to AL2023 in a future release once the ecosystem has had time to migrate

We'd appreciate feedback from the community, particularly if you're currently deploying Swift Lambda functions and have opinions on the migration timeline or the warning approach. Are there other concerns we should account for? Would a different opt-in mechanism (environment variable, Package.swift configuration) work better for your workflow?

Discussion started in PR #668.

2 Likes

Small typo, AL2 is EOL in June 2026 not June 2025 :sweat_smile:

1 Like