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>
This directory contains example code for Lambda functions.
Pre-requisites
-
Ensure you have the Swift 6.x toolchain installed. You can install Swift toolchains from Swift.org
-
When developing on macOS, be sure you use macOS 15 (Sequoia) or a more recent macOS version.
-
To build and archive your Lambda functions, you need to install docker.
-
To deploy your Lambda functions and invoke them, you must have an AWS account and install and configure the
awscommand line. -
Some examples are using AWS SAM. Install the SAM CLI before deploying these examples.
-
Some examples are using the AWS CDK. Install the CDK CLI before deploying these examples.
Examples
-
API Gateway V1: an REST API with Amazon API Gateway and a Lambda function as backend (requires AWS SAM).
-
API Gateway V2: an HTTPS API with Amazon API Gateway and a Lambda function as backend (requires AWS SAM).
-
API Gateway V2 with Lambda Authorizer: an HTTPS API with Amazon API Gateway protected by a Lambda authorizer (requires AWS SAM).
-
BackgroundTasks: a Lambda function that continues to run background tasks after having sent the response (requires AWS CLI).
-
CDK: a simple example of an AWS Lambda function invoked through an Amazon API Gateway and deployed with the Cloud Development Kit (CDK).
-
HelloJSON: a Lambda function that accepts JSON as an input parameter and responds with a JSON output (requires AWS CLI).
-
HelloWorld: a simple Lambda function (requires AWS CLI).
-
Hummingbird: a Lambda function using the Hummingbird web framework with API Gateway integration (requires AWS SAM).
-
S3EventNotifier: a Lambda function that receives object-upload notifications from an Amazon S3 bucket.
-
S3_AWSSDK: a Lambda function that uses the AWS SDK for Swift to invoke an Amazon S3 API (requires AWS SAM).
-
S3_Soto: a Lambda function that uses Soto to invoke an Amazon S3 API (requires AWS SAM).
-
Streaming: create a Lambda function exposed as an URL. The Lambda function streams its response over time. (requires AWS SAM).
-
Streaming+Codable: a Lambda function that combines JSON input decoding with response streaming capabilities, demonstrating a streaming codable interface (requires AWS SAM or the AWS CLI).
-
Testing: a test suite for Lambda functions.
AWS Credentials and Signature
This section is a short tutorial on the AWS Signature protocol and the AWS credentials.
What is AWS SigV4?
AWS SigV4, short for "Signature Version 4," is a protocol AWS uses to authenticate and secure requests. When you, as a developer, send a request to an AWS service, AWS SigV4 makes sure the request is verified and hasn’t been tampered with. This is done through a digital signature, which is created by combining your request details with your secret AWS credentials. This signature tells AWS that the request is genuine and is coming from a user who has the right permissions.
How to Obtain AWS Access Keys and Session Tokens
To start making authenticated requests with AWS SigV4, you’ll need three main pieces of information:
-
Access Key ID: This is a unique identifier for your AWS account, IAM (Identity and Access Management) user, or federated user.
-
Secret Access Key: This is a secret code that only you and AWS know. It works together with your access key ID to sign requests.
-
Session Token (Optional): If you're using temporary security credentials, AWS will also provide a session token. This is usually required if you're using temporary access (e.g., through AWS STS, which provides short-lived, temporary credentials, or for federated users).
To obtain these keys, you need an AWS account:
-
Sign up or Log in to AWS Console: Go to the AWS Management Console, log in, or create an AWS account if you don’t have one.
-
Create IAM User: In the console, go to IAM (Identity and Access Management) and create a new user. Ensure you set permissions that match what the user will need for your application (e.g., permissions to access specific AWS services, such as AWS Lambda).
-
Generate Access Key and Secret Access Key: In the IAM user credentials section, find the option to generate an "Access Key" and "Secret Access Key." Save these securely! You’ll need them to authenticate your requests.
-
(Optional) Generate Temporary Security Credentials: If you’re using temporary credentials (which are more secure for short-term access), use AWS Security Token Service (STS). You can call the
GetSessionTokenorAssumeRoleAPI to generate temporary credentials, including a session token.
With these in hand, you can use AWS SigV4 to securely sign your requests and interact with AWS services from your Swift app.
⚠️ Security and Reliability Notice
These are example applications for demonstration purposes. When deploying such infrastructure in production environments, we strongly encourage you to follow these best practices for improved security and resiliency:
- Enable access logging on API Gateway (documentation)
- Ensure that AWS Lambda function is configured for function-level concurrent execution limit (concurrency documentation, configuration guide)
- Check encryption settings for Lambda environment variables (documentation)
- Ensure that AWS Lambda function is configured for a Dead Letter Queue (DLQ) (documentation)
- Ensure that AWS Lambda function is configured inside a VPC when it needs to access private resources (documentation, code example)