# Swift AWS Lambda Runtime Supports Lambda Managed Instances **URL:** \ **Category:** Server\ **Tags:** lambda\ **Created:** [December 6, 2025, 4:01pm UTC](https://forums.swift.org/t/swift-aws-lambda-runtime-supports-lambda-managed-instances/83589 "2025-12-06T16:01:30Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![sebsto](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sebsto/32/27165_2.png) [@sebsto](https://forums.swift.org/u/sebsto)\ **Post date:** [December 6, 2025, 4:01pm UTC](https://forums.swift.org/t/swift-aws-lambda-runtime-supports-lambda-managed-instances/83589/1 "2025-12-06T16:01:30Z")
AWS recently announced [Lambda Managed Instances](https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html), a new deployment option that runs Lambda functions on customer-owned EC2 instances while AWS manages the operational aspects. This brings an important change to the Lambda programming model. ## What's Different: Multi-Concurrent Invocations Unlike traditional Lambda functions where one execution environment handles one invocation at a time, **Lambda Managed Instances support multi-concurrent invocations**. This means one execution environment can handle multiple invocations simultaneously, each processed by a different runtime worker. As AWS describes it: > Multiple invocations can execute simultaneously within the same execution environment, each handled by a different runtime worker. The execution environment remains continuously active, processing invocations as they arrive without freezing between invocations. This yields better utilization of underlying EC2 instances. Lambda Managed Instances are best suited for: - **High volume-predictable workloads** - Steady-state workloads without unexpected traffic spikes - **Performance-critical applications** - Access to latest CPUs, varying memory-CPU ratios, and high network throughput - **Regulatory requirements** - Granular governance with control over VPC and instance placement - **Variety of applications** - Event-driven applications, media/data processing, web applications, and legacy workloads migrating to serverless ## Swift Runtime: Built for Concurrency from Day One Good news: **the Swift AWS Lambda Runtime was designed with concurrency support from the beginning**. However, in it's current form, the Swift runtime handles invocations in sequence. We've tested it with Lambda Managed Instances and confirmed it works as expected, handling multiple invocations correctly without cross-contamination between requests. In the future, we might consider adding support for concurrent invocations (handling multiple requests in parallel), depending on user feedback and demand. There are multiple strategies to implement this: launch multiple Swift processes, each polling for events and handling them in sequence in a process, or create a Task upon reception of events and run your handler in the Task. ## Important Considerations for Your Code While the runtime handles concurrency safely, you need to ensure your function code is concurrency-safe: ### 1. Respect Swift Concurrency Safety If you're using workarounds to bypass Swift's concurrency safety checks (such as `@unchecked Sendable` or unsafe transfer mechanisms), your code may break in a multi-concurrent environment. The compiler's concurrency safety features exist for good reasons—trust them. ### 2. Avoid Shared State Between Invocations Each invocation must be isolated. Pay special attention to: - **File operations** : Use unique file names for each invocation. Include the request ID in file names to prevent conflicts: ```swift let fileName = "/tmp/\(context.requestID)-data.json" ``` - **Global variables** : Avoid mutable global state that could be accessed by multiple concurrent invocations - **Shared resources** : Database connections, file handles, and other resources must be managed with concurrency in mind ## Getting Started The Swift AWS Lambda Runtime works seamlessly with Lambda Managed Instances—no code changes required if your function is already concurrency-safe. Simply configure your Lambda function with a capacity provider and deploy. For more details on Lambda Managed Instances and the multi-concurrent execution model, see the [AWS documentation](https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-execution-environment.html). ---
**Author:** ![Honza\_Dvorsky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/honza_dvorsky/32/29867_2.png) [@Honza\_Dvorsky](https://forums.swift.org/u/Honza_Dvorsky)\ **Post date:** [December 6, 2025, 4:22pm UTC](https://forums.swift.org/t/swift-aws-lambda-runtime-supports-lambda-managed-instances/83589/2 "2025-12-06T16:22:16Z")
> [@sebsto](#): > > We've tested it with Lambda Managed Instances and confirmed it works as expected, handling multiple concurrent invocations correctly without cross-contamination between requests. What's the isolation model? Is this running a single process with different tasks handling concurrent requests? Multiple processes with a shared file system? Multiple containers with sandboxed file system? ---
**Author:** ![sebsto](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sebsto/32/27165_2.png) [@sebsto](https://forums.swift.org/u/sebsto)\ **Post date:** [December 6, 2025, 4:34pm UTC](https://forums.swift.org/t/swift-aws-lambda-runtime-supports-lambda-managed-instances/83589/3 "2025-12-06T16:34:03Z")
Lambda starts one runtime per EC2 instance. The Runtime can create multiple "worker" This is the AWS wording from [Understanding the Lambda Managed Instances execution environment - AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-execution-environment.html) For the Swift runtime, it translates to one process is started and polls events. It process events as they are received. ---
**Author:** ![Honza\_Dvorsky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/honza_dvorsky/32/29867_2.png) [@Honza\_Dvorsky](https://forums.swift.org/u/Honza_Dvorsky)\ **Post date:** [December 6, 2025, 6:23pm UTC](https://forums.swift.org/t/swift-aws-lambda-runtime-supports-lambda-managed-instances/83589/4 "2025-12-06T18:23:31Z")
So it's one Swift process per EC2 instance, and that one process handles concurrent Lambda invocations? // Edit: when you say “it”, does it mean one Swift process is one worker, or one “runtime”? ---
**Author:** ![sebsto](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sebsto/32/27165_2.png) [@sebsto](https://forums.swift.org/u/sebsto)\ **Post date:** [December 6, 2025, 7:15pm UTC](https://forums.swift.org/t/swift-aws-lambda-runtime-supports-lambda-managed-instances/83589/5 "2025-12-06T19:15:18Z")
Apologies, my original post was ambiguous. I edited it for clarification. With current version of the Swift runtime: there is one Swift process per EC2 instance and that process handles events in sequence. The big difference from traditional Lambda is that the runtime keeps running for a long period of time (as long as the EC2 instance is up or until the runtime crashes :-) ) It doesn't freeze in between invocations and is never terminated. At the moment, there is no concurrent invocation of the user `handler()` in the Swift process. That would require an API change (the handler and the writers must conform to `Sendable`) **Question for the community:** What would be the best strategy to implement concurrent event handling on a single EC2 instance ? 1. The Python runtime choose to spawn multiple processes. 2. The NodeJS runtime [choose to spawn threads in the same process.](https://github.com/aws/aws-lambda-nodejs-runtime-interface-client/blob/nodejs24.x/src/worker/ignition.ts) Each thread contains the full runtime interface client (each thread has its own HTTP GET /next event loop) 3. Keep one HTTP client loop and run the user handler in a separate Task (one Task per event). That would required to make the `handler()` and the `writers` conform to `Sendable`. The first approach is the simplest and doesn't require change in the API. The second option has minimal API changes. The Swift process will start multiple "workers" (Task) made of the current implementation. The number of workers might be configurable with an environment variable. The third approach will require a change in the API to add conformance to `Sendable` ---
**Author:** ![Honza\_Dvorsky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/honza_dvorsky/32/29867_2.png) [@Honza\_Dvorsky](https://forums.swift.org/u/Honza_Dvorsky)\ **Post date:** [December 7, 2025, 12:17am UTC](https://forums.swift.org/t/swift-aws-lambda-runtime-supports-lambda-managed-instances/83589/6 "2025-12-07T00:17:34Z")
I’d probably vote for (1), multiple processes. One reason why (3) could be interesting is if there are expensive caches you want to keep warm inside a single instance and multiple parallel workers. But it also increases the blast radius (data leaks, crashes affecting more unrelated requests.) So not sure it’s worth it. ---
**Author:** ![sebsto](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sebsto/32/27165_2.png) [@sebsto](https://forums.swift.org/u/sebsto)\ **Post date:** [December 7, 2025, 12:24am UTC](https://forums.swift.org/t/swift-aws-lambda-runtime-supports-lambda-managed-instances/83589/7 "2025-12-07T00:24:55Z")
Here is a PR to see what it would like with 2/ > > > This PR adds support for running multiple Runtime Interface Clients (RICs) concu…rrently when deployed on Lambda Managed Instances, enabling the runtime to handle multiple invocations simultaneously within a single execution environment. > > \*\*Changes\*\* > \- Modified \`LambdaRuntime.\_run()\` to spawn multiple RICs based on the \`AWS\_LAMBDA\_MAX\_CONCURRENCY\` environment variable > \- Each RIC runs in its own task, polling for and processing invocations independently > \- Removed \`UnsafeTransfer\` and mark the \`handler()\` (and all the types in uses in various form) \`Sendable\` > \- Added \`waitForAll()\` to ensure proper error propagation from all RIC tasks > \- Improved logging with RIC identifiers (RIC=1 through RIC=N) for better observability > > \*\*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 behavior for optimal performance on traditional Lambda deployments. This creates multiple Runtime HTTP Clients (Lambda calls these Runtime Interface Client or RIC) as per the `AWS_LAMBDA_MAX_CONCURRENCY` env variable. Each RIC runs in its own Task. When `AWS_LAMBDA_MAX_CONCURRENCY` is absent or ==1, no Task are created and existing behavior is preserved. The downside is that the `LambdaHandler` protocol and all the types it touches must be marked `Sendable`, which I know @fabianfett worked hard to avoid so far. If we choose this, this would require a major version bump. ---
**Author:** ![sebsto](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sebsto/32/27165_2.png) [@sebsto](https://forums.swift.org/u/sebsto)\ **Post date:** [December 7, 2025, 12:26am UTC](https://forums.swift.org/t/swift-aws-lambda-runtime-supports-lambda-managed-instances/83589/8 "2025-12-07T00:26:20Z")
I'll try a PR for 1/ too but I have to figure out a DX friendly way to do it. The process entry point is under the control of the user, not the library. I'll need more thinking. Now that I made the hard work for making `LambdaHandler` conform to `Sendable`, implementing 3 should not be too hard. It's just the matter of where to start the Taskgroup. With the existing PR for 2/, it is started in the `LambdaRuntime` class. With 3/, it would be in the `Lambda.runLoop()` function ---
**Author:** ![sebsto](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sebsto/32/27165_2.png) [@sebsto](https://forums.swift.org/u/sebsto)\ **Post date:** [January 18, 2026, 8:26pm UTC](https://forums.swift.org/t/swift-aws-lambda-runtime-supports-lambda-managed-instances/83589/9 "2026-01-18T20:26:41Z")
Based on other community feedback, we decided to not make change to the current API and to implement a separate `LambdaRuntime` struct that will enforce your handler function to be `Sendable`. The new `LambdaManagedRuntime` has the same signature API as the existing `LambdaRuntime` but will enforce its handler to conform to `Sendable`. That runtime starts multiple HTTP Client loop to fetch events from Lambda and dispatch them to your handler function in parallel (using `TaskGroups`). You control in the console (or the function configuration) the maximum number of concurrent handler execution per EC2 instance. This is work in progress. We need code reviewers. Here is the PR with the core changes, i.e. the introduction of a `LambdaManagedInstance` struct. > > > AWS launched \[Lambda Managed Instance\](https://docs.aws.amazon.com/lambda/latest…/dg/lambda-managed-instances.html), i.e Lambda functions running on EC2 instances. > > This comes with \[a major change in the programming model\](https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html#lambda-managed-instances-concurrency-model) as function handlers are now allowed to run concurrently on the same machine (multiple in flight events being processed in parallel in the same execution environment). The maximum concurrency per runtime environment is controlled by the user. > > This PR adds support for running multiple Runtime Interface Clients (RICs) concurrently when deployed on Lambda Managed Instances, enabling the runtime to handle multiple invocations simultaneously within a single execution environment. > > This PR is a followup to https://github.com/awslabs/swift-aws-lambda-runtime/pull/617 which used another approach to support Lambda Managed Instances by changing the public API and requiring that all handlers must conform to \`Sendable\`. The original PR was closed as we agreed that only a fraction of the Lambda functions will be deployed on EC2 and it was not worth adding a \`Sendable\` requirement for all. > > \*\*Changes\*\* > > \- \*\*Introduced thread-safe LambdaManagedRuntime\*\*: Created new Sendable-conforming runtime class that supports concurrent handler execution with atomic guards to prevent multiple runtime instances and thread-safe handler requirements (\`Handler: StreamingLambdaHandler & Sendable\`) > > \- \*\*Implemented ServiceLifecycle integration\*\*: Added managed runtime support for structured concurrency lifecycle management, allowing proper startup/shutdown coordination in multi-concurrent environments > > This PR contains only changes to the core runtime, convenience functions, handlers, adapters, and a comprehensive example will be added in a follow up PR. > > \*\*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. And this is a second PR that adds convenience structs, such as the `Adapters` and `ClosureHandler`. These are mostly copy / paste of existing struct, with the addition of the conformance to `Sendable`. > > > This PR builds on https://github.com/awslabs/swift-aws-lambda-runtime/pull/629 t…o add convenience structs (Handlers and Adapters) that are \`Sendable\` > > \*\*Changes\*\* > > \- \*\*Added Sendable adapter types\*\*: Implemented \`LambdaHandlerAdapterSendable\`, \`LambdaCodableAdapterSendable\`, and \`ClosureHandlerSendable\` - all thread-safe versions of existing adapters that enforce \`Sendable\` conformance for concurrent execution environments > > \- \*\*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. This later PR also includes an extensive example to show the (minimal) code change required for those of you willing to deploy your functions on Lambda Managed Instances. A `LambdaManagedRuntime` can be deployed on a standard Lambda runtime environment. The opposite is not true, unless you paid attention to concurrency. This is what the conformance for `Sendable` will do for you automatically.