re:Invent 2025 - Lambda Managed Instances: EC2 Power with Serverless Simplicity

Many organizations have adopted serverless computing to accelerate development and reduce operational overhead. Yet some workloads require specific compute characteristics or pricing models that don't fit the traditional serverless execution model. Stephen Liedig, Principal Solutions Architect with the Serverless team at AWS, and Archana Srikanta, Principal Engineer with the AWS Lambda Team, introduced Lambda Managed Instances to address this gap. In this post, we'll walk through what Lambda Managed Instances enables, when you should consider using it, and how it differs from the Lambda experience you know today.

Expanding the Serverless Model to Your Infrastructure

AWS Lambda has pioneered serverless computing over the past decade, continuously innovating to support diverse workloads. However, customers have consistently asked for more control over where their functions run and what compute resources power them. Some need specialized instance types for memory-intensive workloads. Others want to apply Amazon EC2 Savings Plans or Reserved Instances to their serverless applications. Still others need higher throughput for sustained, high-traffic applications.

Lambda Managed Instances addresses these needs by running your Lambda functions on EC2 instances in your account. You select from over 400 instance types across compute-optimized, memory-optimized, and general-purpose families. AWS handles the complete operational lifecycle, including instance provisioning, operating system patching, runtime updates, routing, and auto scaling. You maintain the same Lambda programming model and can apply EC2 pricing instruments like Savings Plans and Reserved Instances to reduce costs.

This capability targets specific workload profiles. You should consider Lambda Managed Instances for high-traffic, steady-state workloads with predictable traffic patterns. Applications with specialized computational, memory, or network throughput requirements also benefit. For workloads with unpredictable traffic, short duration, or infrequent invocations, continue using Lambda's default infrastructure. The two options complement each other, giving you flexibility to match your application characteristics to the most appropriate compute model.

Setting Up Lambda Managed Instances

The setup process introduces one new concept while keeping the Lambda experience largely familiar. You start by creating a capacity provider, which contains all your instance-level configuration. This includes the Virtual Private Cloud (VPC) where instances launch, the instance types Lambda can select, and scaling guardrails. The capacity provider requires an Identity and Access Management (IAM) role granting Lambda permissions to launch and manage EC2 instances in your account, plus VPC configuration specifying subnets and security groups.

Your capacity provider VPC configuration determines networking behavior. Lambda launches instances with a primary network interface in your VPC, and all outbound traffic from your functions transits through this interface. This means your function code can reach downstream dependencies through your VPC routing tables, and application logs flow to Amazon CloudWatch through the same path. You should provide subnets across three availability zones for production applications, because Lambda spreads instances and execution environments evenly across them for high availability.

After creating a capacity provider, you create a function and associate it with that provider through a new CapacityProviderConfig parameter. This single line in your create-function call designates it as a Lambda Managed Instances function. The rest of the function creation experience remains unchanged. You specify your code, runtime, memory, and other settings just as you do today. Lambda Managed Instances supports OCI containers and Zip packaging formats, plus the latest versions of Java, Python, Node.js, and .NET runtimes.

The final step triggers deployment. You publish a function version, which causes Lambda to launch EC2 instances in your account and initialize execution environments on them. By default, Lambda initializes three execution environments across three availability zones. Your function enters a pending state during initialization and becomes active once ready to accept traffic. Publishing versions is optional with Lambda's default infrastructure but required for Lambda Managed Instances to trigger the deployment process.

Understanding Multi-Concurrency and Scaling

Lambda Managed Instances introduces two significant behavioral differences from Lambda's default infrastructure, both stemming from the shift to EC2 instances in your account. The first relates to concurrency. In Lambda's default infrastructure, each execution environment handles one invoke at a time. With Lambda Managed Instances, a single execution environment can handle multiple concurrent invokes simultaneously. This multi-concurrency model means you need fewer execution environments to serve the same request volume.

Lambda sets default maximum concurrency values per execution environment based on the programming language, derived from analyzing workload patterns across AWS. You can override these defaults if your application has specific constraints. To prevent execution environments from becoming overloaded, Lambda monitors resource utilization (CPU, memory, and disk) continuously. If an execution environment approaches saturation, Lambda's agent on the instance redirects new invokes to other execution environments. If the environments show high resource pressure, Lambda throttles additional requests to maintain application stability. CloudWatch metrics show the specific bottleneck resource causing throttles, helping you tune your configuration.

Multi-concurrency requires attention to thread safety in your code. Unlike single-concurrent execution environments, where only one invoke runs at a time, multiple invokes now share the same environment simultaneously. Avoid mutating shared objects or global variables. Use thread-local storage for request-specific data. Any shared clients or connections you initialize should have immutable configuration during invokes. When writing to the /tmp directory, use request-specific file names to prevent concurrent invokes from overwriting each other's data.

The second key difference involves scaling. Lambda's default infrastructure scales by initializing new execution environments in the request path, which you experience as cold starts. Lambda Managed Instances pre-initializes execution environments, so there are no cold starts. Instead, scaling happens asynchronously based on resource utilization. Lambda continuously monitors CPU usage across your capacity provider and functions. When average CPU utilization exceeds a target threshold, Lambda scales up by deploying additional execution environments. If existing instances have available capacity, it uses them. Otherwise, it launches new EC2 instances.

This resource-based scaling works well for steady-state traffic patterns with predictable load curves. However, if traffic spikes faster than Lambda can launch new instances and execution environments, CPU utilization may rise high enough to trigger request throttling. Lambda protects your application by limiting incoming traffic rather than allowing resource exhaustion. As new capacity comes online, throttling stops. You can monitor CPU and memory utilization, concurrent executions, and execution environment counts through CloudWatch metrics at both the function and capacity provider levels. These metrics help you understand scaling behavior and identify if you need to adjust your configuration.

Pricing and Ecosystem Support

Lambda Managed Instances uses EC2 pricing with a 15% management fee added to instance costs. The management fee applies to the default EC2 instance price, even when you receive discounts through Savings Plans or Reserved Instances. You still pay the standard per-invocation charge but no longer pay duration charges, since your functions run on instances you're already being billed for. This pricing model can reduce costs significantly for high-traffic workloads, particularly when combined with EC2 commitment-based discounts.

The Lambda ecosystem supports Lambda Managed Instances from day one. Datadog provides full observability with automatic trace propagation through its extension. Sedai identifies strong candidates for migration and enables one-click function migration through its autonomous optimization platform. AWS AppConfig feature flags work seamlessly through the Lambda Extension. CloudWatch Lambda Insights offers one-click deployment with 12 key metrics at one-minute granularity. AWS Lambda Powertools provides thread-safe utilities for observability, batch processing, and other common patterns.

Infrastructure as code tools support the new APIs immediately. AWS CloudFormation, AWS Serverless Application Model (SAM), AWS Cloud Development Kit (CDK), and Terraform all recognize capacity providers and the associated function configuration. This means you can incorporate Lambda Managed Instances into your existing deployment pipelines without changing your tooling.

Conclusion

Lambda Managed Instances extends the serverless programming model to workloads requiring specialized compute or predictable pricing. You maintain the Lambda development experience, architecture patterns, and operational simplicity while gaining control over instance types and access to EC2 pricing mechanisms. The multi-concurrency model and resource-based scaling suit high-traffic applications with steady demand patterns. For spiky or unpredictable workloads, Lambda's default infrastructure remains the better choice.

The key is matching workload characteristics to compute models. Lambda Managed Instances complements rather than replaces Lambda's default infrastructure. Together, they expand the range of applications you can build with serverless patterns. Start by identifying high-traffic functions with consistent load profiles or those requiring specific instance capabilities. Create a capacity provider, associate your functions, and publish a version to deploy. Monitor your resource utilization and scaling behavior through CloudWatch metrics, adjusting your configuration as needed.

Full session recording is available on: AWS re:Invent 2025 - Lambda Managed Instances: EC2 Power with Serverless Simplicity (CNS382)