AWS Builder Center

Builder Center

Lambda Managed Instances: When to Leave Default Compute — 90-Min Timeout, Multi-Concurrency, and Cost Break-Even

Lambda Managed Instances now supports a 90-minute timeout on asynchronous invocations, runs multi-concurrent executions inside EC2 Nitro containers, and bills via instance-based EC2 pricing with a 15% management fee. Here's the concurrency model, tenancy isolation, and when the cost break-even favors Managed Instances over default Lambda compute.

Lambda Managed Instances: When to Leave Default Compute

Lambda Managed Instances launched in December 2025 and reached full feature parity by mid-2026. The most visible update: a 90-minute (5,400-second) function timeout for asynchronous invocations and event-source mappings, compared to the default Lambda 15-minute (900-second) ceiling. That single change removes the main blocker for batch processing, video transcoding pipelines, and long-running ETL workflows that previously required Step Functions orchestration or container migration.
This article covers the concurrency and tenancy differences, explains when the 90-minute timeout activates, and provides a cost break-even framework comparing Lambda default (per-request + GB-second billing) against Lambda Managed Instances (EC2 instance-based billing + 15% management fee).

The 90-Minute Timeout: What's New

Default Lambda functions have a hard timeout of 900 seconds (15 minutes). The Lambda documentation explicitly states the extension:
For functions using AWS Lambda Managed Instances, asynchronous invocations and event source mapping invocations (except Amazon MQ and Amazon DocumentDB) support a maximum allowed value of 5,400 seconds (90 minutes).
This applies only to Managed Instances. Default Lambda functions—whether synchronous or asynchronous—remain capped at 15 minutes. If your workload needs 30 minutes of continuous execution, Managed Instances is the only Lambda-native option without splitting the job across multiple invocations.
Key caveats from the documentation:
  • The 90-minute limit applies to asynchronous invocations and event source mappings. Synchronous API Gateway / Lambda Function URL calls still follow the caller timeout (API Gateway has its own 29-second integration timeout).
  • Memory and vCPU settings on Managed Instances start at 2 GB and 1 vCPU. There's no 128 MB or 512 MB option. You pay for the allocated instance resources continuously, not per invocation duration alone.
  • The timeout setting is configured via Timeout in update-function-configuration, same as default Lambda, but the maximum accepted value depends on which compute type the function version runs on.

Concurrency Model: Single vs. Multi-Concurrent

The fundamental execution model difference between Lambda default and Lambda Managed Instances is concurrency:
DimensionLambda DefaultLambda Managed Instances
Execution modelSingle concurrency: one invocation per execution environment at a timeMulti-concurrency: one execution environment handles multiple simultaneous invocations
Scaling triggerScales when no free environment exists (cold start)Scales asynchronously based on CPU utilization and concurrency saturation
Cold startPresent; new environment initialized on demandAbsent; minimum execution environments provisioned continuously
Scaling rate1,000 new environments per 10 seconds per functionNo cold-start scaling limit; scales based on resource consumption
Thread safetyNot required (isolated environments)Required; execution environments share CPU/memory between concurrent invocations
On Managed Instances, the environment variable AWS_LAMBDA_MAX_CONCURRENCY defines the maximum concurrent invocations Lambda routes to a single execution environment. The default balances throughput and resource consumption, but you can adjust it per function:
  • Increase concurrency (up to 64 per vCPU) if invocations are IO-heavy and CPU-light.
  • Decrease concurrency if memory consumption per invocation is high and CPU usage is low.
This multi-concurrency model improves instance utilization significantly for IO-heavy web services or batch jobs where the CPU spends most of its time waiting on external APIs, database queries, or file I/O.

Tenancy and Isolation: Nitro Containers vs. Firecracker MicroVMs

The isolation architecture is different:
Lambda Default (Firecracker MicroVM)
  • Multi-tenant: Lambda manages shared fleets.
  • Isolation via Firecracker MicroVMs—lightweight VMs with sub-second startup.
  • Execution environments are ephemeral and hidden from the account.
  • No VPC-level visibility into underlying instances.
Lambda Managed Instances (EC2 Nitro Containers)
  • Single-tenant within your account: instances launch in your subnets, with your security groups, and are tagged aws:lambda:capacity-provider.
  • Isolation via containers running on EC2 Nitro instances, not MicroVMs.
  • Capacity providers serve as the security boundary. Functions assigned to the same capacity provider must be mutually trusted—containers do not provide strong security isolation between untrusted workloads.
  • Instances are hidden from the EC2 console by default but fully billable. You can adjust visibility via managed resource visibility settings.
  • You cannot terminate instances directly; deleting the capacity provider triggers Lambda-managed termination.
This has direct security implications: separate mutually untrusted workloads by using different capacity providers. If you run a public-facing web service and an internal data processing job on the same capacity provider, they share container isolation—not MicroVM isolation—within the same Nitro instance.

Scaling Behavior and Traffic Planning

Managed Instances scales asynchronously based on resource consumption signals, not on invocation arrival:
  • Lambda Agent monitors CPU utilization and concurrency saturation per instance.
  • Scaling decisions happen continuously, not at cold-start time.
  • If traffic doubles within 5 minutes, throttles are possible because capacity must scale up before demand peaks are fully served.
  • Default behavior: Lambda launches 3 instances for AZ resiliency and starts 3 execution environments before marking a function version ACTIVE.
This makes Managed Instances poorly suited for bursty, unpredictable traffic. If your workload has sudden traffic spikes with no warm-up period, the default Lambda model (scale-to-zero with cold starts) responds faster to unexpected load. Managed Instances excels at steady-state, predictable workloads where continuous instance availability eliminates cold-start latency.

Cost Break-Even Analysis

Managed Instances pricing structure (from AWS Lambda pricing documentation):
  • Instance-based EC2 pricing (On-Demand, Savings Plans, or Reserved Instances apply to the underlying compute).
  • 15% management fee on top of EC2 instance cost.
  • EC2 pricing discounts (Savings Plans, Reserved Instances) apply to the instance cost only—not the 15% management fee.
Compare to Lambda default pricing (US East reference rates):
  • Request charge: $0.20 per 1 million requests.
  • Duration charge: $0.0000166667 per GB-second (x86_64).

Break-Even Formula

To find when Managed Instances is cheaper than default Lambda for a steady workload, solve for the hourly instance cost that equals the Lambda default cost for the same execution profile.
For a workload running continuously on a 4 vCPU / 8 GB instance (approximate c6i.xlarge on-demand rate ~$0.17/hour in us-east-1):
  • Managed Instances hourly cost: ($0.17 EC2 + 15% fee) × 3 instances (minimum AZ-resilient) = $0.586/hour = ~$430/month.
  • Lambda default equivalent: If the same continuous workload uses 8 GB × 3,600 seconds/hour = 28,800 GB-seconds/hour. At $0.0000166667/GB-s = $0.48/hour for duration + request charges. For low-frequency continuous workloads, Lambda default is cheaper. For high-frequency, long-duration invocations, the instance model wins.

When to Choose Managed Instances

Leave default Lambda compute when at least one of these conditions is met:
  1. Timeout exceeds 15 minutes: 90-minute timeout is only available on Managed Instances. Workflows requiring 30, 60, or 90 minutes of continuous execution must use Managed Instances or split into multi-step orchestrations.
  2. Steady-state, predictable traffic: If your workload runs continuously or at predictable intervals, the instance-based model eliminates cold-start overhead and scales smoothly. Bursty, unpredictable traffic is better served by default Lambda's rapid environment provisioning.
  3. Multi-concurrency improves utilization: If your function handles IO-heavy concurrent requests, the multi-concurrency model increases throughput per instance, reducing total instance count needed.
  4. EC2 pricing discounts apply: If you have Savings Plans or Reserved Instances for the underlying instance families, those discounts apply directly to Managed Instances (but not to the 15% management fee).
  5. Performance-critical requirements: Access to latest CPUs (Graviton4, network-optimized instances), configurable memory-to-vCPU ratios, and high-bandwidth networking is only available through Managed Instances.
  6. Regulatory / governance needs: Capacity providers define VPC placement, instance selection, and security groups explicitly—useful when compliance requires granular infrastructure control.

When to Stay on Default Lambda

  • Traffic is sporadic or unpredictable; cold starts are acceptable.
  • Workload completes in under 15 minutes.
  • Scale-to-zero is a primary cost requirement (Managed Instances maintain minimum 3 instances per capacity provider).
  • You don't need multi-concurrency or specialized instance types.

Getting Started: Capacity Provider Setup

Managed Instances requires creating a capacity provider before attaching functions:
1
2
3
4
5
6
aws lambda create-capacity-provider \
--capacity-provider-name production-trusted \
--vpc-config SubnetIds=subnet-1,subnet-2,subnet-3,SecurityGroupIds=sg-default \
--permissions-config CapacityProviderOperatorRoleArn=arn:... \
--instance-requirements Architectures=arm64 \
--capacity-provider-scaling-config ScalingMode=Auto,MaxVCpuCount=400
Key configuration choices:
  • VPC subnets: At least one subnet, maximum 16. Use multiple AZs for resilience.
  • Security group: Defaults to VPC default if not specified.
  • Instance requirements: Let Lambda choose instance types (recommended for availability) or specify allowed/excluded types for cost or performance optimization.
  • Scaling mode: Auto (recommended) or Manual.
  • Max vCPU count: Default 400 per capacity provider.
After creating the capacity provider, publish your function version to it:
1
2
aws lambda publish-version --function-name my-function \
--description v1-managed-instances
The function must have $LATEST.PUBLISHED qualifier linked to the capacity provider. Lambda launches 3 instances by default and starts 3 execution environments before marking the version ACTIVE.

Runtime-Specific Multi-Concurrency Notes

The multi-concurrency execution model requires runtime-specific adjustments:
  • Python: May need a higher memory-to-vCPU ratio (4:1 or 8:1) because Python handles multi-threading differently. Monitor ConcurrencyThrottles, CPUThrottles, MemoryThrottles, and DiskThrottles metrics to identify which resource constraint is causing throttles.
  • Java / Node.js: Thread safety and context isolation must be handled explicitly. Each concurrent invocation within the same execution environment shares process-level state unless isolated by the runtime framework.
  • Custom runtimes: Must implement concurrent invocation handling according to Lambda's runtime API specifications.
The environment variables AWS_LAMBDA_INITIALIZATION_TYPE (set to lambda-managed-instances) and AWS_LAMBDA_MAX_CONCURRENCY expose the execution model to your code at runtime.

Conclusion: The Decision Matrix

Lambda Managed Instances is not a universal replacement for default Lambda compute. It is a specialized compute mode optimized for:
  • Continuous or predictable workloads
  • Long-duration invocations (up to 90 minutes)
  • Multi-concurrent execution patterns
  • Specialized instance family requirements
For the majority of event-driven, short-duration, variable-load serverless workloads, default Lambda remains the simpler, faster-scaling, lower-overhead choice. Use Managed Instances when your workload demands instance-level control, extended execution windows, or the cost profile of continuous instance billing favors your traffic pattern over per-request duration billing.
The 90-minute timeout, Nitro container isolation, and multi-concurrency model represent a significant expansion of Lambda's compute surface. They also impose new operational requirements: capacity provider management, thread-safe code patterns, and continuous instance billing. Evaluate both dimensions—technical capability and operational cost—before migrating production workloads.
# aws-lambda# amazon-ec2# cost-allocation# timeouts# vmware-cloud-aws
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article