Sébastien Stormacq
b1553d2766
Closing https://github.com/swift-server/swift-aws-lambda-runtime/issues/584 The LocalServer now queues concurrent `POST /invoke` requests from testing client applications and ensures that the requests are delivered to the Lambda Runtime one by one, just like the AWS Lambda Runtime environment does. The `Pool` has now two modes : pure FIFO (one element get exactly one `next()`) and one mode where multiple elements can get pushed and multiple `next(for requestId:String)` can be called concurrently. The two modes are needed because invocations are 1:1 (one `POST /invoke` is always by one matching `GET /next`) but responses are n:n (a response can have multiple chunks and concurrent invocations can trigger multiple `next(for requestId: String)` I made a couple of additional changes while working on this PR - I moved the `Pool` code in a separate file for improved readability - I removed an instance of `DispatchTime` that was hiding in the code, unnoticed until today - I removed the `async` requirement on `Pool.push(_)` function. This was not required (thank you @t089 for having reported this) - I removed the `fatalError()` that was in the `Pool` implementation. The pool now throws an error when `next()` is invoked concurrently, making it easier to test. - I added extensive unit tests to validate the Pool behavior - I added a test to verify that a rapid succession of client invocations are correctly queued and return no error - I moved a `continuation(resume:)` outside of a lock. Generally speaking, it's a bad idea to resume continuation while owning a lock. I suspect this is causing a error during test execution when we spawn and tear down mutliple `Task` very quickly. In some rare occasions, the test was failing with an invalid assertion in NIO : `NIOCore/NIOAsyncWriter.swift:177: Fatal error: Deinited NIOAsyncWriter without calling finish()` --------- Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu> Co-authored-by: Copilot <175728472+Copilot@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)