Files
swift-aws-lambda-runtime/Examples/MultiSourceAPI
Sébastien Stormacq 9f566bf4f1 [plugin] Display a warning when compiling on Amazon Linux 2 and optin documentation and examples for Amazon Linux 2023 (#668)
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>
2026-05-28 10:26:44 +02:00
..
2025-11-02 21:58:02 +01:00

Multi-Source API Example

This example demonstrates a Lambda function that handles requests from both Application Load Balancer (ALB) and API Gateway V2 by accepting a raw ByteBuffer and decoding the appropriate event type.

Overview

The Lambda handler receives events as ByteBuffer and attempts to decode them as either:

  • ALBTargetGroupRequest - for requests from Application Load Balancer
  • APIGatewayV2Request - for requests from API Gateway V2

Based on the successfully decoded type, it returns an appropriate response.

Building

swift package archive --allow-network-connections docker --base-docker-image swift:amazonlinux2023

Deploying

Deploy using SAM:

sam deploy \
  --resolve-s3 \
  --template-file template.yaml \
  --stack-name MultiSourceAPI \
  --capabilities CAPABILITY_IAM

Testing

After deployment, SAM will output two URLs:

Test API Gateway V2:

curl https://<api-id>.execute-api.<region>.amazonaws.com/apigw/test

Expected response:

{"source":"APIGatewayV2","path":"/apigw/test"}

Test ALB:

curl http://<alb-dns-name>/alb/test

Expected response:

{"source":"ALB","path":"/alb/test"}

How It Works

The handler uses Swift's type-safe decoding to determine the event source:

  1. Receives raw ByteBuffer event
  2. Attempts to decode as ALBTargetGroupRequest
  3. If that fails, attempts to decode as APIGatewayV2Request
  4. Returns appropriate response based on the decoded type
  5. Throws error if neither decoding succeeds

This pattern is useful when a single Lambda function needs to handle requests from multiple sources.