AWS Lambda Managed Instances (LMI)

Quick Decision: Is LMI Right for This Workload?

Routing

• Capacity provider stuck in CREATING → most common cause is private subnets missing a NAT gateway route (instances need outbound internet for image pull and Lambda service communication)
• Function not scaling → check that a version is published (PublishToLatestPublished: true)
• Memory errors → LMI minimum is 2048 MB

Workflow

Step 1: Assess the Workload

1. Traffic pattern: Steady vs bursty? Requests per second?
2. Current costs: Monthly Lambda spend? Existing Savings Plans?
3. Runtime: Node.js, Java, .NET, or Python?
4. Memory/CPU: How much memory? CPU-bound or I/O-bound?
5. Execution duration: Average and P99?
6. Concurrency readiness: Thread safety? Shared

   /tmp

   paths? Per-invocation DB connections?
7. VPC: Already in a VPC? Private resource access needed?

Step 2: Build the Cost Comparison

Step 3: Configure the Deployment

• Instance families (400+ types, .large and up): C-series (compute), M-series (general), R-series (memory). ARM (Graviton) for best price-performance.
• When using Graviton instances, MUST set

  Architectures: [arm64]

  in the function configuration to match.
• Memory-to-vCPU ratios: 2:1 (compute), 4:1 (general, default), 8:1 (memory). Min 2 GB, max 32 GB.
• Multi-concurrency per-vCPU maximums: Node.js 64, Java 32, .NET 32, Python 16. These are system caps — the actual setting is PerExecutionEnvironmentMaxConcurrency (per execution environment, not per vCPU).
• For I/O-bound workloads: use the runtime default or higher PerExecutionEnvironmentMaxConcurrency (e.g., 10 for Node.js) since each request uses minimal CPU while waiting on network.
• For CPU-bound workloads: set PerExecutionEnvironmentMaxConcurrency to 1-2 per vCPU since each request saturates CPU.
• Scaling: MinExecutionEnvironments (default 3), MaxVCpuCount (optional, default 400 — set explicitly as best practice), TargetResourceUtilization.

Step 4: Migrate the Code

• Python: Process-based isolation — globals are NOT shared. No thread-safety changes needed. Focus on

  /tmp

  conflicts and memory sizing.
• Node.js: Worker threads — globals shared within a worker. Requires async safety.
• Java/.NET: OS threads/Tasks — handler shared across threads. Requires full thread safety.

Step 5: Set Up Infrastructure

1. Create two IAM roles: execution role (for the function) and operator role (for capacity provider EC2 management)
2. Configure VPC with subnets across 3+ AZs
3. Create capacity provider with VPC config and scaling limits
4. Create or update function with capacity provider attachment
5. Publish a version (triggers instance provisioning)

Step 6: Validate and Cut Over

1. Deploy to a non-production environment first
2. Monitor CloudWatch: CPU utilization, memory, concurrency, throttle rate
3. Gradual traffic shift with weighted aliases (10% → 50% → 100%)
4. Compare costs after 1-2 weeks of production data
5. Decommission standard Lambda once stable

Best Practices

Pricing (always mention when discussing costs)

• Three components: EC2 instance hours + 15% management fee + $0.20/1M requests
• Savings Plans: Compute Savings Plans apply to the EC2 portion (up to 60-72% discount)
• The 15% fee is charged on top of EC2 cost for AWS managing provisioning, patching, scaling, lifecycle

Scaling (always mention when discussing scaling or traffic)

• LMI absorbs a 50% traffic spike immediately and doubles capacity within 5 minutes — if traffic more than doubles faster, requests throttle
• Standard Lambda bursts to 3000 instantly — LMI cannot match this
• Pre-warm with MinExecutionEnvironments before known spikes
• MaxVCpuCount (default 400) — set explicitly as a cost ceiling
• Shape: Reduce MinExecutionEnvironments to lower capacity during off-hours (minimum 3 for AZ resiliency)

Instance Sizing

• 1 vCPU + 1 GB reserved per instance for OS overhead (not available to your function)
• Usable capacity = total - overhead

Configuration

• Start with 4:1 ratio and runtime default concurrency
• Use ARM (Graviton) unless x86 dependencies exist
• Let Lambda choose instance types unless specific hardware needed
• Set MaxVCpuCount to control cost ceiling
• Never set MinExecutionEnvironments below 3 (breaks AZ resiliency)

Migration

• Start with I/O-heavy functions (benefit most from multi-concurrency)
• Review code for concurrency safety before attaching to capacity provider
• Use weighted aliases for gradual traffic shift
• Include request IDs in all log statements
• Initialize DB pools and SDK clients outside the handler

Operations

• Set CloudWatch alarms on throttle rate > 1% and CPU > 80%
• Plan for 14-day instance rotation (automatic)
• Never manually terminate LMI EC2 instances (delete the capacity provider instead)
• Always publish a version — unpublished functions cannot run on LMI

Limits Quick Reference

Security Considerations

• Operator role scoping: Add

  aws:SourceAccount

  and

  aws:SourceArn

  conditions to trust policies to prevent confused deputy attacks.
• VPC egress: Scope security group egress to VPC endpoint security groups or AWS prefix lists rather than 0.0.0.0/0.
• Credentials: Use AWS Secrets Manager or Parameter Store for database credentials — never environment variables for secrets.
• Encryption: Enable SQS SSE, CloudWatch Logs encryption (KMS), and S3 default encryption for any data at rest.
• Logging: Set CloudWatch Log group retention policies. Avoid logging PII or credentials. Enable CloudTrail data events for Lambda.
• Instance rotation: The 14-day automatic rotation ensures security patches are applied without manual intervention.
• References: Lambda Security Best Practices, IAM Best Practices

Files