This PR divides the CI time by ~2
## Issue #
N/A
## Description of changes
This PR makes two changes to the integration tests workflow:
1. Replace the manual `git clone` checkout with `actions/checkout@v4` in
the `test-examples` job. The container image was updated from Amazon
Linux 2 to `swift:6.2` (Ubuntu-based), which supports Node.js-based
GitHub Actions. This also removes the now-unnecessary
`working-directory` overrides that pointed to the repository
subdirectory created by the manual clone.
2. Add SPM dependency caching (`actions/cache@v4`) to the
`test-examples`, `test-archive-plugin`, and `check-foundation` jobs.
Each example's `.build` directory is cached with a key scoped per
example name, avoiding cross-contamination between different dependency
sets.
## New/existing dependencies impact assessment, if applicable
No new dependencies were added to this change. This only adds the
`actions/cache@v4` GitHub Action to the CI workflow.
## Conventional Commits
`ci: switch to actions/checkout and add SPM dependency caching in
integration tests`
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license.
---------
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
Co-authored-by: Tim Condon <0xTim@users.noreply.github.com>
This PR builds on
https://github.com/awslabs/swift-aws-lambda-runtime/pull/629 to add
convenience structs (Handlers and Adapters) that are `Sendable`
**Changes**
- **Added Sendable adapter types**: Implemented `ClosureHandlerSendable`
- a thread-safe version of existing closure handler that enforces
`Sendable` conformance for concurrent execution environments - and added
conditional conformance to `Sendable` for other Adapters when the
Handler is `Sendable`
- **Enhanced handler protocols for concurrency**: Extended handler
protocols to support `Sendable` constraints and concurrent response
writing through `LambdaResponseStreamWriter & Sendable`, enabling safe
multi-threaded invocation processing
- **Created comprehensive Lambda Managed Instances examples**: Built
three demonstration functions showcasing concurrent execution
capabilities, streaming responses, and background processing patterns
specific to the new managed instances deployment model
**Context**
Lambda Managed Instances support multi-concurrent invocations where
multiple invocations execute simultaneously within the same execution
environment. The runtime now detects the configured concurrency level
and launches the appropriate number of RICs to handle concurrent
requests efficiently.
When `AWS_LAMBDA_MAX_CONCURRENCY` is 1 or unset, the runtime maintains
the existing single-threaded behaviour for optimal performance on
traditional Lambda deployments.
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
## Overview
This PR reorganizes and enhances the streaming Lambda examples by
splitting them into two distinct examples that demonstrate different
invocation methods:
1. **Streaming+FunctionUrl** - Streaming responses via Lambda Function
URLs
2. **Streaming+APIGateway** - Streaming responses via API Gateway REST
API
## Changes
### 🔄 Restructured Examples
- **Renamed**: `Examples/Streaming/` → `Examples/Streaming+FunctionUrl/`
- Maintains the original streaming example using Lambda Function URLs
- Updated documentation to clarify Function URL-specific configuration
- Improved AWS credentials handling in curl examples
- **New**: `Examples/Streaming+APIGateway/`
- Comprehensive example demonstrating API Gateway REST API with response
streaming
- Complete SAM template with proper IAM roles and streaming
configuration
- Detailed documentation covering API Gateway-specific setup
### 📚 Documentation Improvements
#### Streaming+FunctionUrl
- Clarified that this example uses Lambda Function URLs
- Updated curl examples to use `eval $(aws configure export-credentials
--format env)` for cleaner credential handling
- Maintained all existing functionality and deployment instructions
#### Streaming+APIGateway (New)
- **316-line comprehensive README** covering:
- Response streaming concepts and benefits
- HTTP status code and header configuration
- Streaming response body patterns
- Local testing instructions
- Complete SAM deployment guide with detailed template explanation
- API Gateway-specific invocation with AWS Sigv4 authentication
- Payload format documentation with example JSON
- Security and reliability best practices
- How API Gateway streaming works under the hood
### 🛠️ Technical Details
#### API Gateway Streaming Configuration
The new example demonstrates:
- Special Lambda URI: `/response-streaming-invocations` endpoint
- `responseTransferMode: STREAM` configuration
- IAM role with both `lambda:InvokeFunction` and
`lambda:InvokeWithResponseStream` permissions
- Proper timeout configuration (60s) to accommodate streaming duration
#### SAM Template Features
```yaml
- Lambda function with streaming support (arm64, provided.al2)
- API Gateway REST API with OpenAPI 3.0 definition
- IAM execution role for API Gateway to invoke Lambda with streaming
- Complete outputs for easy testing (API URL and Lambda ARN)
```
### 🔐 Security Enhancements
Both examples now include comprehensive security best practices:
- API Gateway access logging
- Throttling configuration
- AWS WAF integration recommendations
- Lambda concurrent execution limits
- Environment variable encryption
- Dead Letter Queue (DLQ) configuration
- VPC configuration guidance
### 🧪 Testing
Both examples support:
- **Local testing**: `swift run` with curl invocation on port 7000
- **AWS deployment**: Complete SAM templates with deployment
instructions
- **Authenticated invocation**: AWS Sigv4 examples with proper
credential handling
## Benefits
1. **Clearer separation**: Developers can now easily choose between
Function URLs and API Gateway based on their use case
2. **Better documentation**: Each example has tailored documentation for
its specific invocation method
3. **Production-ready**: Includes security best practices and proper IAM
configuration
4. **Easier testing**: Improved credential handling in curl examples
## Breaking Changes
None - this is purely additive. The original streaming example is
preserved as `Streaming+FunctionUrl`.
## Testing Checklist
- [x] Local testing works for both examples
- [x] SAM deployment templates are valid
- [x] Documentation is comprehensive and accurate
- [x] Security best practices are documented
- [x] Curl examples work with proper authentication
## Related Documentation
- [AWS Lambda Response
Streaming](https://docs.aws.amazon.com/lambda/latest/dg/configuration-response-streaming.html)
- [API Gateway Lambda Proxy Integration with
Streaming](https://docs.aws.amazon.com/apigateway/latest/developerguide/response-streaming-lambda-configure.html)
- [Lambda Function
URLs](https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html)
EOF
---------
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
Remove a dependency on Swift NIO's GitHub workflows and use Swiftlang's
github action for unit tests instead
---------
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
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>
This PR adds a new example demonstrating how to build a Lambda function
that handles requests from multiple sources (Application Load Balancer
and API Gateway V2) using a single handler.
### What's New
**New Example: `Examples/MultiSourceAPI`**
A Lambda function that:
- Implements `StreamingLambdaHandler` to accept raw `ByteBuffer` events
- Dynamically decodes events as either `ALBTargetGroupRequest` or
`APIGatewayV2Request`
- Returns appropriate responses based on the detected event source
- Demonstrates handling multiple AWS service integrations with a single
function
### Key Features
- **Type-safe event detection**: Uses Swift's `Decodable` to identify
the event source at runtime
- **Streaming response**: Implements `StreamingLambdaHandler` for
efficient response handling
- **Complete deployment**: Includes SAM template with both ALB and API
Gateway V2 infrastructure
- **Production-ready**: Full VPC setup with subnets, security groups,
and load balancer configuration
### Files Added
- `Examples/MultiSourceAPI/Sources/main.swift` - Lambda handler
implementation
- `Examples/MultiSourceAPI/Package.swift` - Swift package configuration
- `Examples/MultiSourceAPI/template.yaml` - SAM deployment template with
ALB and API Gateway V2
- `Examples/MultiSourceAPI/README.md` - Documentation with build,
deploy, and test instructions
- Updated CI to include the new example
### Use Case
This pattern is useful when you want to:
- Expose the same Lambda function through multiple AWS services
- Reduce code duplication by handling similar requests from different
sources
- Maintain a single codebase for multi-channel APIs
---------
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
Co-authored-by: Josh Elkins <jbelkins@users.noreply.github.com>
- Adjust notice, security reporting, code of conduct, contribution
process to the standard AWS documents
- Adjust GitHub issue templates to AWS standard ones.
- Adjust the license header in all source files
---------
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
Fix errors in the CI
The script that checks the presence of `libFoundation` in the binary
started to fail.
I can't think about a recent change that would cause this.
This PR change the test script to use the `HelloWorld` example instead
of `APIGAtewayV2`
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
Apply recommendations in code and documentation
- [CI] restrict permissions to read-all instead of the default write-all
- All examples README.md : add a note about Lambda functions
configuration with improved security and scalability changes for
production environment
- Swift docc documentation: add a note about Lambda functions
configuration with improved security and scalability changes for
production environment
---------
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
In preparation for the 2.0.0 GA release,
- Update `.swift-version`, `Package.swift` and all examples'
`package.swift` to Swift 6.2
- Update all references to `2.0.0-beta.3` to `2.0.0`. This includes the
doc and readme, but also the dependencies in the examples
`Package.swift`. This will temporary break the build of the examples,
until we tag v2.0.0. Note the CI will not be affected as its consumes
the local version of the library
- [CI] Use Swift-6.2-noble for all testing tasks
- Reinstate the script to generate the contributors list and update the
list
Make required changed to ensure the library compiles when no traits are
enabled (fix:
https://github.com/swift-server/swift-aws-lambda-runtime/issues/562)
Add an example project that serves as test in the CI
### Motivation:
Recent changes introduced compilation errors when no traits are enabled.
### Modifications:
- `LambdaResponseStreamWriter.writeStatusAndHeaders()` moved to the
`FoundationSupport` directory where all classes and struct depending on
`Encodable` and `Decodable` are located, protected by `#if
FoundationJSONSupport`
- `LambdaRuntime.run()` method when ServiceLifeCycle is disabled in now
public (and therefore can not be `@inlinable` anymore)
- Add an example that disables all traits.
- Add this example to the CI
### Result:
The Library now compiles when no default traits are enabled.
This is flagged `semver/major` because we change the public API
`LambdaRuntime.run()`
Revert streaming codable handler change and propose it as an example
instead of an handler API.
**Motivation:**
I made a mistake when submitting this PR
https://github.com/swift-server/swift-aws-lambda-runtime/pull/532
It provides a Streaming+Codable handler that conveniently allows
developers to write handlers with `Codable` events for streaming
functions.
This is a mistake for three reasons:
- This is the only handler that assumes a Lamba Event structure as
input. I added a minimal `FunctionUrlRequest` and `FunctionURLResponse`
to avoid importing the AWS Lambda Events library. It is the first
handler to be event-specific. I don't think the runtime should introduce
event specific code.
- The handler only works when Lambda functions are exposed through
Function URLs. Streaming functions can also be invoke by API or CLI.
- The handler hides `FunctionURLRequest` details (HTTP headers, query
parameters, etc.) from developers
Developers were unaware they were trading flexibility for convenience
The lack of clear documentation about these limitations led to incorrect
usage patterns and frustrated developers who needed full request control
or were using other invocation methods.
**Modifications:**
- Removed the Streaming+Codable API from the library
- Moved the Streaming+Codable code to an example
- Added prominent warning section in the example README explaining the
limitations
- Clarified when to use Streaming+Codable vs ByteBuffer approaches
- Added decision rule framework to help developers choose the right
approach
**Result:**
The only API provided by the library to use Streaming Lambda functions
is exposing the raw `ByteBuffer` as input, there is no more `Codable`
handler for Streaming functions available in the API. I kept the
`Streaming+Codable` code an example.
After this change, developers have clear guidance on when to use each
streaming approach:
- Use streaming codable for Function URL + JSON payload + no request
details needed
- Use ByteBuffer StreamingLambdaHandler for full control, other
invocation methods, or request metadata access
This prevents misuse of the API and sets proper expectations about the
handler's capabilities and limitations, leading to better developer
experience and fewer integration issues.
Add Hummingbird web framework integration example for AWS Lambda
**Motivation:**
Developers using the Hummingbird web framework need a clear example of
how to integrate it with AWS Lambda. The existing examples focus on
basic Lambda handlers, but don't demonstrate how to use popular Swift
web frameworks like Hummingbird in a serverless context.
**Modifications:**
Added a complete Hummingbird Lambda example in Examples/Hummingbird/
including Package.swift with Hummingbird Lambda dependencies, main.swift
demonstrating router setup with API Gateway V2 integration, SAM template
for deployment, and comprehensive README documentation with build,
deploy, and usage instructions.
**Result:**
Developers can now easily create AWS Lambda functions using the
Hummingbird web framework, with a working example that shows router
configuration, API Gateway integration, and complete deployment workflow
using familiar Hummingbird syntax.
Add user-facing API for Streaming Lambda functions that receives JSON
events
### Motivation:
Streaming Lambda functions developed by developers had no choice but to
implement a handler that receives incoming data as a `ByteBuffer`. While
this is useful for low-level development, I assume most developers will
want to receive a JSON event to trigger their streaming Lambda function.
Going efficiently from a `ByteBuffer` to a Swift struct requires some
code implemented in the `JSON+ByteBuffer.swift` file of the librray. We
propose to further help developers by providing them with a new
`handler()` function that directly receives their `Decodable` type.
### Modifications:
This PR adds a public facing API (+ unit test + updated README) allowing
developers to write a handler method accepting any `Decodable` struct as
input.
```swift
import AWSLambdaRuntime
import NIOCore
// Define your input event structure
struct StreamingRequest: Decodable {
let count: Int
let message: String
let delayMs: Int?
}
// Use the new streaming handler with JSON decoding
let runtime = LambdaRuntime { (event: StreamingRequest, responseWriter, context: LambdaContext) in
context.logger.info("Received request to send \(event.count) messages")
// Stream the messages
for i in 1...event.count {
let response = "Message \(i)/\(event.count): \(event.message)\n"
try await responseWriter.write(ByteBuffer(string: response))
// Optional delay between messages
if let delay = event.delayMs, delay > 0 {
try await Task.sleep(for: .milliseconds(delay))
}
}
// Finish the stream
try await responseWriter.finish()
// Optional: Execute background work after response is sent
context.logger.info("Background work: processing completed")
}
try await runtime.run()
```
This interface provides:
- **Type-safe JSON input**: Automatic decoding of JSON events into Swift
structs
- **Streaming responses**: Full control over when and how to stream data
back to clients
- **Background work support**: Ability to execute code after the
response stream is finished
- **Familiar API**: Uses the same closure-based pattern as regular
Lambda handlers
Because streaming Lambda functions can be invoked either directly
through the API or through Lambda Function URL, this PR adds the
decoding logic to support both types, shielding developers from working
with Function URL requests and base64 encoding.
We understand these choice will have an impact on the raw performance
for event handling. Those advanced users that want to get the maximum
might use the existing `handler(_ event: ByteBuffer, writer:
LambaStreamingWriter)` function to implement their own custom decoding
logic.
This PR provides a balance between ease of use for 80% of the users vs
ultimate performance, without closing the door for the 20% who need it.
### Result:
Lambda function developers can now use arbitrary `Decodable` Swift
struct or Lambda events to trigger their streaming functions. 🎉
---------
Co-authored-by: Tim Condon <0xTim@users.noreply.github.com>
~~Attempt to fix CI~~
Remove usage of deprecated parameters on unit-test.
- explicitly enable tests on nightly 6.0
- explicitly enable tests on nightly next
- explicitly enable tests on nightly main
At the time of this writing, this resolves to
```
linux_6_0_container_image="swift:6.0-jammy"
linux_nightly_next_container_image="swiftlang/swift:nightly-6.1-jammy"
linux_nightly_main_container_image="swiftlang/swift:nightly-main-jammy"
```
---------
Co-authored-by: Fabian Fett <fabianfett@apple.com>
Resources are not included in the archive on Linux
https://github.com/swift-server/swift-aws-lambda-runtime/issues/505
In addition, the script that checks if the resources are correctly
included in an archive when building on Linux is not working.
It failed to detected missing resources.
This patch fix both the plugin and the CI script
When we include Traits, we changed the CI container from Swift 6.0
Amazon Linux to Swift 6.1 Nightly on Ubuntu.
This broke the CI because AWS SDK used in the `Examples/S3_AWSSDK`
example depends on `libssl-devel` which is not installed by default on
Jammy images.
This PR reverts back the container used to test all examples to an
Amazon Linux 2, but this time the 6.1-nightly version to allow to
compile the package traits.
This should address
https://github.com/swift-server/swift-aws-lambda-runtime/issues/494
Add `S3EventNotifier` example
### Motivation:
There is currently no example regarding an AWS event triggered lambda,
such as a lambda that gets invoked on an S3 object upload. I've had to
look for a while to figure out that the `AWSLambdaEvents` exists and
that it can be used for that (had to find out via a Java example! 😜) so
I think this could be useful and a somewhat common use case
### Modifications:
Added an example of a lambda that gets triggered when an object gets
uploaded to an S3 bucket.
I have not described how to set up the actual S3 event in AWS because I
figured if you needed such a lambda you'd know, but I can describe that
too in the README if needed
---------
Co-authored-by: Sébastien Stormacq <sebastien.stormacq@gmail.com>
When including resources in the package and packaging on Ubuntu,
`FileManager` throws a FilePermission error. The docker daemon runs as
root and files to be copied are owned by `root` while the archiver runs
as the current user (`ubuntu` on EC2 Ubuntu). The `FileManager` manages
to copy the files but throws an error after the copy. We suspect the
`FileManager` to perform some kind of operation after the copy and it
fails because of the `root` permission of the files.
See
https://github.com/swift-server/swift-aws-lambda-runtime/issues/449#issuecomment-2595978246
for a description of the problem.
This PR contains code to reproduce the problem, a very simple
workaround, and an integration test.
The workaround consists of
- trapping all errors
- verify if the error is the permission error (Code = 513)
- verify if the files have been copied or not
- if the two above conditions are met, ignore the error, otherwise
re-throw it
I would rather prefer a solution that solves the root cause rather than
just ignoring the error.
We're still investigating the root cause (see [this
thread](https://forums.swift.org/t/filemanager-copyitem-on-linux-fails-after-copying-the-files/77282)
on the Swift Forum and this issue on Swift Foundation
https://github.com/swiftlang/swift-foundation/issues/1125
Add an example of an APIGateway Lambda Authorizer
### Motivation:
Lambda Authorizers allow developers to write custom logic to validate
HTTP REST requests.
This example shows how to write a Lambda Authorizer in Swift and how to
configure an API Gateway to use a Lambda Authorizer.
This example use a SAM template to deploy the resources.
### Modifications:
- Add `Examples/APIGateway+LambdaAuthorizer` directory with the source
code, a `template.yaml`, and a `README` file.
- Add a reference to the new example in `Examples/README`
- Modify CI to build the new example
### Result:
There is a new example showing how to develop a Lambda authorizer in
Swift and how to attach it to an APIGateway with SAM
This adds a test in the `integration_test.yml` workflow to verify that
`libFoundation.so`, `libFoundationInternationalization.so`, and
`lib_FoundationICU.so` and not linked the the function binary.
This is a follow up from the work make by @t089 to ensure that we don't
accidentally link Foundation again in the future.
Remove Foundation :
https://github.com/swift-server/swift-aws-lambda-runtime/pull/436
Add test in CI to ensure we don't link to foundation :
https://github.com/swift-server/swift-aws-lambda-runtime/issues/402
_[One line description of your change]_
### Motivation:
_[Explain here the context, and why you're making that change. What is
the problem you're trying to solve.]_
### Modifications:
_[Describe the modifications you've done.]_
### Result:
_[After your change, what will change.]_
_[One line description of your change]_
### Motivation:
_[Explain here the context, and why you're making that change. What is
the problem you're trying to solve.]_
### Modifications:
_[Describe the modifications you've done.]_
### Result:
_[After your change, what will change.]_
* add aws sdk example
* add soto example
* use amazonlinux docker image instead of ubuntu
* dynamically add runtime dependency based on env var
* remove import of Foundation.ProcessInfo
* workaround https://github.com/actions/checkout/issues/1487
Sébastien Stormacq
Konrad `ktoso` Malawski
Fabian Fett
Paul Toffoloni
Franz Busch