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

**URL:** <https://forums.swift.org/t/migrating-the-swift-aws-lambda-archive-plugin-default-from-amazon-linux-2-to-amazon-linux-2023/86738>\
**Category:** Development\
**Tags:** lambda\
**Created:** [May 15, 2026, 8:39am UTC](https://forums.swift.org/t/migrating-the-swift-aws-lambda-archive-plugin-default-from-amazon-linux-2-to-amazon-linux-2023/86738 "2026-05-15T08:39:50Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![sebsto](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sebsto/32/27165_2.png) [@sebsto](https://forums.swift.org/u/sebsto)\
**Post date:** [May 15, 2026, 8:39am UTC](https://forums.swift.org/t/migrating-the-swift-aws-lambda-archive-plugin-default-from-amazon-linux-2-to-amazon-linux-2023/86738/1 "2026-05-15T08:39:50Z")

</div>

## 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](https://github.com/awslabs/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](https://github.com/awslabs/swift-aws-lambda-runtime/pull/668).

---

<div class="post-metadata">

**Author:** ![0xTim](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/0xtim/32/27968_2.png) [@0xTim](https://forums.swift.org/u/0xTim)\
**Post date:** [May 15, 2026, 10:15am UTC](https://forums.swift.org/t/migrating-the-swift-aws-lambda-archive-plugin-default-from-amazon-linux-2-to-amazon-linux-2023/86738/2 "2026-05-15T10:15:00Z")

</div>

Small typo, AL2 is EOL in June 2026 not June 2025 😅