AWS Lambda Managed Instances marks a significant evolution in serverless computing. For years, standard Lambda was the default for running code without infrastructure management, but it offered limited control over the underlying hardware. This new capability changes that by combining serverless simplicity with Amazon EC2 flexibility.

 

Announced at AWS re:Invent 2025, this feature enables Lambda functions to run on designated Amazon EC2 instances. You choose the hardware configuration, while AWS manages the infrastructure. This approach combines the simplicity of serverless with the control of dedicated resources.

 

Previously, architects chose between two models, each with significant trade-offs:

AWS Lambda Managed Instances provides a middle ground. You define a Capacity Provider with your chosen EC2 instance family, and AWS manages the instance lifecycle within your account.

This feature addresses specific architectural needs and is not intended as a default replacement for standard Lambda.

The billing structure shifts from a “duration-based” model to a “provisioned capacity” model.

 

As noted earlier, getting started with AWS Lambda Managed Instances is straightforward. In this section, we will walk through a practical, in-depth example of how to implement this new feature in a real-world scenario.

• Step 1.2: Select Trusted Identity
  • Select “AWS service” and choose “Lambda” as the use case. Click “Next”.

• Step 1.3: Attach Policy
  • In the search bar, look for the AWS-managed policy: AWSLambdaManagedEC2ResourceOperator. Check the box next to it.
• 

2. Configuring the Capacity Providers

• Step 2.1: Navigate to Lambda
  • Go to the Lambda Console.

• Step 2.2: Capacity Providers
  • In the left navigation pane, choose “Capacity providers“. Click “Create capacity provider“.
• Step 2.3: Basic Settings
  • Set the Capacity provider name to lambda-capacity.

• Step 2.4: Instance Requirements
  • Set Architecture to arm64 (Graviton) and Allowed instance types to m6g.large (This ensures Graviton-specific optimization).

• Step 2.5: Scaling Configuration
  • Set Scaling Mode to Manual and Target Utilization to 70% (The utilization percentage AWS will try to maintain).

• Step 2.6: Network Configuration
  • Select the Default VPC ID for your region and the single subnet named lambda capacity. Use the VPC’s default security group. For the Infrastructure operator role, select your LambdaManagedInstanceOperatorRole.
• Step 2.7: Create
  • Click “Create capacity provider”. Wait for the status to change from CREATING to ACTIVE.

3. Creating Lambda Function

• Step 3.1: Create Function
  • Navigate to Functions and click “Create function“.

• Step 3.2: Configuration
  • Set Function = lambda-managed-i
  • Set Runtime = Python 3.14
  • Set Architecture = arm64

• Step 3.3: Deploy Code
  • Paste the threaded Python code (using ThreadPoolExecutor) into the code editor and click “Deploy”.

• Step 3.4: Enable Function URL
  • Go to the Configuration tab, choose Function URL, and click “Create function URL“. Use NONE for Auth type for a simple test.

• Step 3.5: Configure General Settings
  • Go to General configuration and click “Edit”. Set Memory to 2048 MB (2 GB).

• Step 3.6: Configure Capacity Provider
  • Go to Capacity Provider and click “Edit”. Change Compute type from Default to Capacity provider. Select the ARN of your lambda-capacity for Capacity Provider.

• Step 3.7: Configure Concurrency
  • Set PerExecutionEnvironmentMaxConcurrency to 2 (This is the 2:1 ratio you requested, as the m6g.large has 2 vCPUs). Set Memory/vCPU to 2048 MB (This ensures that 2 executions share the 2GB memory total).

• Step 3.8: Publish Version
  • After saving all configurations, go to the function dashboard, click “Actions”, and then “Publish new version”. This is critical for the Capacity Provider to start managing the function.

4. Testing Results

We compared the execution behavior of a standard Lambda function against our new Managed Instance setup to highlight the architectural differences.

• Scenario 1 – Standard Lambda Test
  • Observation: Runs into the FileNotFoundError with multiprocessing.Pool or is inefficient with ThreadPoolExecutor.
  • Key Takeaway: Technical Necessity: Standard Lambda cannot run truly parallel, CPU-bound workloads.

• Scenario 2 – Managed Instance Test
  • Observation: Zero Cold Start. First invocation is fast. The total_wall_clock_time is significantly lower than the sum_of_all_task_time (due to true multi-process/multithread parallel execution).
  • Key Takeaway: Performance & Cost: This environment enables peak performance, and the cost is now fixed and discounted via the Graviton/Savings Plan-eligible m6g.large instance.

AWS Lambda Managed Instances signal a pivotal evolution in cloud computing, breaking the long-standing trade-off between agility and control. By merging the hands-off simplicity of serverless with the power and specificity of EC2, organizations can now tailor their compute environments to their most demanding workloads without sacrificing operational efficiency. This innovation empowers teams to architect for scale, optimize for cost, and innovate faster—removing barriers that once constrained the most ambitious projects.

As the boundaries between traditional infrastructure and serverless continue to blur, Lambda Managed Instances stand as a testament to AWS’s commitment to customer-centric cloud evolution. For forward-looking teams, this isn’t just a new feature; it’s a strategic advantage and a catalyst for what’s next.