This PR has been reworked. Instead of silently switching the default
base image based on Swift version, we now:
1. **Keep Amazon Linux 2 as the default** base Docker image for the
packager plugin
2. **Add a prominent deprecation warning** when AL2 is used (either via
Docker or natively), informing developers that AL2 reaches End of Life
on June 30, 2026
3. **Migrate all examples** (READMEs, SAM templates, scripts) to build
and deploy on Amazon Linux 2023 (`provided.al2023` runtime +
`--base-docker-image swift:amazonlinux2023`)
4. **Update documentation** (readme, quick-setup) with migration notes
The warning includes the `--base-docker-image swift:6.3-amazonlinux2023`
flag and reminds developers to use the `provided.al2023` runtime when
deploying.
After June 30, 2026, the default will switch to AL2023.
---
<details>
<summary>Original PR description (superseded)</summary>
~~Now that Docker Hub has official Swift images based on Amazon Linux
2023 (starting with 6.3), the packager plugin picks the right base image
automatically depending on the Swift version:~~
~~- Swift 6.3 and later: `swift:<version>-amazonlinux2023`~~
~~- Earlier versions: `swift:<version>-amazonlinux2` (unchanged
behavior)~~
~~- No version specified (latest): defaults to `amazonlinux2023`~~
~~When only a major version is provided (e.g. `--swift-version 6`
without a minor), we conservatively treat it as 6.0 and use Amazon Linux
2, since we can't be sure it's 6.3+.~~
~~Also added a verbose log line showing the resolved Swift version,
Amazon Linux version, and final base image to help with debugging.~~
~~The `--base-docker-image` flag still overrides everything as before.~~
</details>
---------
Co-authored-by: Sébastien Stormacq <stormacq@amazon.lu>
Drop support fro Swift 6.0 as per ecosystem's policy to support the last
three major versions, now 6.1, 6.2, and 6.3
- CI is updated
- all docs, readme, and examples are updated to 6.3 as default
## Summary
Examples now default to the published `swift-aws-lambda-runtime` package
from GitHub, so they work out of the box when cloned standalone (as
described in the READMEs).
CI scripts swap the dependency to the local path (`../..`) before
building, ensuring we still test against the current branch.
### Changes
- **`Examples/APIGatewayV2/Package.swift`** — Default to remote URL,
local path is commented out with clear instructions.
- **`.github/workflows/scripts/use-local-deps.sh`** (new) — Shared
script that rewrites Package.swift to use the local dependency.
- **`integration_tests.sh`**, **`check-archive-plugin.sh`**,
**`check-link-foundation.sh`** — Source `use-local-deps.sh` before
building.
<!--- Provide a general summary of your changes in the Title above -->
## Issue \#
<!--- If it fixes an issue, please link to the issue here -->
https://github.com/awslabs/swift-aws-lambda-runtime/issues/607
## Description of changes
<!--- Why is this change required? What problem does it solve? -->
The local HTTP server was not forwarding user‑provided headers to the
runtime’s response. It passes all headers through to the runtime. This
it makes local behavior match the Lambda runtime API contract and allows
developers to opt into metadata by sending the appropriate runtime
headers.
## New/existing dependencies impact assessment, if applicable
<!--- No new dependencies were added to this change. -->
<!--- If any dependency was added / modified / removed,
THIRD-PARTY-LICENSES must be updated accordingly. -->
N/A
## Conventional Commits
<!--- Please use conventional commits to let us know what kind of change
this is.-->
<!--- More info can be found here:
https://www.conventionalcommits.org/en/v1.0.0/-->
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license.
---------
Co-authored-by: Sébastien Stormacq <sebastien.stormacq@gmail.com>
See issue #536
All the examples are now depending on the runtime library located at
`../..`. The `Package.swift` files contain a commented line with the
`.package` to use when user wants to fetch the runtime from GitHub.
---------
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
Address https://github.com/awslabs/swift-aws-lambda-runtime/issues/605
NEW Lambda Tenant isolation capability:
https://docs.aws.amazon.com/lambda/latest/dg/tenant-isolation.html
# Add Support for Lambda Tenant Isolation Mode
## Summary
This PR adds support for AWS Lambda's tenant isolation mode to the Swift
AWS Lambda Runtime, enabling developers to build multi-tenant
applications with strict execution environment isolation per tenant.
## Changes
### Runtime Support
- Added `tenantID` property to `LambdaContext` to expose the tenant
identifier
- Extended `InvocationMetadata` to capture the
`Lambda-Runtime-Aws-Tenant-Id` header
- Added `AmazonHeaders.tenantID` constant for the tenant ID header
- Added trace logging for invocation headers to aid debugging
### New Example: MultiTenant
A complete working example demonstrating tenant isolation mode:
- **Request tracking system** that maintains separate counters and
histories per tenant
- **Actor-based storage** (`TenantDataStore`) for thread-safe tenant
data management
- **Immutable data structures** (`TenantData`) following Swift best
practices
- **API Gateway integration** with tenant ID passed via query parameter
- **SAM template** configured with `TenancyConfig.TenantIsolationMode:
PER_TENANT`
- **Comprehensive documentation** covering architecture, deployment,
testing, and best practices
### Testing
- Added unit test for tenant ID extraction from invocation headers
- Integrated MultiTenant example into CI/CD pipeline
### Documentation
The example includes detailed documentation on:
- When to use tenant isolation (user code execution, sensitive data
processing)
- How tenant isolation works (dedicated environments, no cross-tenant
reuse)
- Concurrency limits and scaling considerations
- Pricing implications
- Security best practices
- CloudWatch monitoring with tenant dimensions
## Files Changed
- `Sources/AWSLambdaRuntime/LambdaContext.swift` - Added tenantID
property
- `Sources/AWSLambdaRuntime/ControlPlaneRequest.swift` - Capture tenant
ID from headers
- `Sources/AWSLambdaRuntime/Utils.swift` - Added tenantID header
constant
- `Sources/AWSLambdaRuntime/Lambda.swift` - Pass tenant ID to context
- `Sources/AWSLambdaRuntime/LambdaRuntimeClient+ChannelHandler.swift` -
Added trace logging
- `Tests/AWSLambdaRuntimeTests/InvocationTests.swift` - Added tenant ID
test
- `Examples/MultiTenant/*` - New complete example with SAM template
- `.github/workflows/pull_request.yml` - Added MultiTenant to CI
pipeline
## Testing Instructions
1. Build and deploy the example:
bash
cd Examples/MultiTenant
swift package archive --allow-network-connections docker
sam deploy --guided
2. Test with different tenants:
bash
curl
"https://<api-id>.execute-api.<region>.amazonaws.com/Prod?tenant-id=
alice"
curl
"https://<api-id>.execute-api.<region>.amazonaws.com/Prod?tenant-id=
bob"
3. Verify isolation by checking that each tenant maintains separate
request counts
## Related Documentation
- [AWS Lambda Tenant
Isolation](https://docs.aws.amazon.com/lambda/latest/dg/tenant-isolation.html)
- [AWS Blog: Streamlined Multi-Tenant Application
Development](https://aws.amazon.com/blogs/aws/streamlined-multi-tenant-application-development-with-tenant-isolation-mode-in-aws-lambda/)
---------
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
Co-authored-by: Tim Condon <0xTim@users.noreply.github.com>
Sébastien Stormacq
Manoj Mahapatra