Aws Lambda Managed Instances

AWS Lambda Managed Instances (LMI)

Run Lambda functions on current-generation EC2 instances in your account while AWS manages provisioning, patching, scaling, routing, and load balancing. Combines Lambda's developer experience with EC2's pricing and hardware options.

For standard Lambda development, see aws-lambda skill. For SAM/CDK deployment, see aws-serverless-deployment skill.

When to Load Reference Files

• Cost comparison, pricing analysis, Lambda vs LMI cost, Savings Plans, or Reserved Instances -> see references/cost-comparison.md
• Instance types, memory sizing, vCPU ratios, scaling tuning, or capacity provider config -> see references/configuration-guide.md
• Thread safety, concurrency model, code review checklist, Powertools compatibility, or multi-concurrency readiness -> see references/thread-safety.md
• Before/after code examples, runtime-specific migration (Node.js, Python, Java, .NET), or connection pooling -> see references/migration-patterns.md
• IAM roles, VPC setup, CLI commands, SAM template, or CDK example -> see references/infrastructure-setup.md and scripts/setup-lmi.sh
• Errors, throttling, debugging, or stuck deployments -> see references/troubleshooting.md

Quick Decision: Is LMI Right for This Workload?

Instructions

Step 1: Assess the Workload

Gather these signals before recommending:

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 (Node.js/Java/.NET)? Shared /tmp paths? Per-invocation DB connections? 7. VPC: Already in a VPC? Private resource access needed?

Step 2: Build the Cost Comparison

REQUIRED: Present a cost comparison before recommending LMI. Compare at minimum:

Rule of thumb: LMI becomes cost-competitive when your Lambda spend exceeds ~$1,000/month with steady traffic.

For discount analysis (Savings Plans, Reserved Instances), refer users to the AWS Pricing Calculator and references/cost-comparison.md for formulas and worked examples. Discount recommendations require workload-specific forecasting beyond this skill's scope.

Step 3: Configure the Deployment

Instance families (~450 types): C-series (compute, .xlarge+), M-series (general, .large+), R-series (memory, .large+). ARM (Graviton) for best price-performance.

Memory-to-vCPU ratios: 2:1 (compute), 4:1 (general, default), 8:1 (memory). Min 2 GB, max 32 GB.

Multi-concurrency defaults/vCPU: Node.js 64, Java 32, .NET 32, Python 16.

Scaling: MinExecutionEnvironments (default 3), MaxVCpuCount (default 400), TargetResourceUtilization.

See references/configuration-guide.md for decision trees and detailed tuning.

Step 4: Migrate the Code

Review code for concurrency safety. LMI runs multiple invocations concurrently per execution environment, but the model differs by runtime:

• Python: Process-based isolation — globals are NOT shared. No thread-safety changes needed. Focus on /tmp conflicts and memory sizing (per-process × concurrency).
• Node.js: Worker threads — globals shared within a worker. Requires async safety. Callback handlers not supported on Node.js 22.
• Java/.NET: OS threads/Tasks — handler shared across threads. Requires full thread safety.

Common issues (all runtimes): shared /tmp paths, per-invocation DB connections. Thread-safety issues (Node.js/Java/.NET only): mutable globals, non-thread-safe libs.

See references/thread-safety.md for the review checklist and references/migration-patterns.md for runtime-specific before/after code.

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 multiple AZs (recommended 3+ for resiliency) 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)

See references/infrastructure-setup.md for CLI commands and SAM templates.

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

Configuration

• Do: Start with 4:1 ratio and runtime default concurrency
• Do: Use ARM (Graviton) unless x86 dependencies exist
• Do: Let Lambda choose instance types unless specific hardware needed
• Do: Set MaxVCpuCount to control cost ceiling
• Don't: Set MinExecutionEnvironments below 3 in production (reduces multi-AZ coverage). Non-prod environments can use 1 as the minimum.
• Don't: Over-restrict instance types (lowers availability)

Migration

• Do: Start with I/O-heavy functions (benefit most from multi-concurrency; CPU-bound functions compete for same CPU)
• Do: Review code for concurrency safety before attaching to capacity provider (thread safety for Node.js/Java/.NET; /tmp and memory for Python)
• Do: Use weighted aliases for gradual traffic shift
• Do: Include request IDs in all log statements
• Do: Initialize DB pools and SDK clients outside the handler
• Do: Estimate total /tmp usage under max concurrency
• Don't: Write to hardcoded /tmp paths without request-unique naming
• Don't: Skip cost comparison — LMI is not always cheaper

Operations

• Do: Set CloudWatch alarms on throttle rate > 1% and CPU > 80%
• Don't: Manually terminate LMI EC2 instances (delete the capacity provider instead)
• Don't: Forget to publish a version — unpublished functions cannot run on LMI

Limits Quick Reference

Troubleshooting Quick Reference

See references/troubleshooting.md for detailed resolution steps.

Configuration

AWS CLI Setup

REQUIRED: AWS credentials configured on the host machine.

Verify access: Run aws sts get-caller-identity

Regional Availability

Currently available: us-east-1, us-east-2, us-west-2, ap-northeast-1, eu-west-1. Expanding to all commercial regions soon.

Check the Lambda Managed Instances documentation for the latest regional availability.

Language Selection

Default: TypeScript

Override: "use Python" → Python, "use JavaScript" → JavaScript. When not specified, ALWAYS use TypeScript.

IaC Framework Selection

Default: CDK

Override: "use SAM" → SAM YAML, "use CloudFormation" → CloudFormation YAML. When not specified, ALWAYS use CDK.

Error Scenarios

Serverless MCP Server Unavailable

• Inform user: "AWS Serverless MCP not responding"
• Ask: "Proceed without MCP support?"
• DO NOT continue without user confirmation

Unsupported Runtime

• State: "Lambda Managed Instances does not yet support [runtime]"
• List supported runtimes
• Suggest standard Lambda as alternative

Unsupported Region

• State: "Lambda Managed Instances is not yet available in [region]"
• List available regions

Resources

• Lambda Managed Instances Docs
• Introducing LMI (AWS Blog)
• Build High-Performance Apps with LMI
• Migrating Functions to LMI (AWS Blog)
• LMI Pricing Calculator
• LMI Samples Repository
• AWS Lambda Pricing

LMI Configuration Guide

Instance Type Decision Tree

• CPU-intensive (encoding, ML, compression) → C-series, 2:1 ratio, concurrency=1/vCPU
• Memory-intensive (caching, large datasets) → R-series, 8:1 ratio
• Network-intensive (streaming, data transfer) → Use AllowedInstanceTypes for n-suffix types, 4:1 ratio
• General/balanced (web APIs, microservices) → M-series, 4:1 ratio, default concurrency

Architecture: ARM (Graviton, g-suffix) for price-performance. x86 (i=Intel, a=AMD) when dependencies require it.

Memory-to-vCPU Ratios

Min: 2 GB / 1 vCPU. Max: 32 GB. Memory must align with ratio multiples.

Memory Sizing from Existing Lambda

Concurrency Tuning

Total capacity = MinExecutionEnvironments × PerExecutionEnvironmentMaxConcurrency

Capacity Provider Scaling Controls

Monitoring Thresholds

• CPU > 80%: reduce concurrency or add vCPUs
• CPU < 20%: increase concurrency for better utilization
• Throttle rate (429s) > 1%: increase MinExecutionEnvironments or reduce utilization target
• Memory > 90%: increase memory or reduce concurrency
• ExecutionEnvironmentConcurrency near ExecutionEnvironmentConcurrencyLimit: saturation — reduce concurrency or scale out

CloudWatch Metrics Dimensions

LMI metrics are split across two CloudWatch dimensions:

• Alias (live): Invocations, Errors, Throttles, Duration
• Version ($LATEST or numbered): CPUUtilization, MemoryUtilization, ExecutionEnvironmentConcurrency, ExecutionEnvironmentCount

Create a unified dashboard combining both views to monitor LMI performance effectively.

Lambda vs LMI Cost Comparison

Use the LMI Pricing Calculator for accurate, up-to-date cost comparisons based on your specific workload parameters (region, instance type, request volume, duration).

When building a cost comparison for a user, gather: region, runtime, requests/month, average duration, memory, and architecture (x86 vs ARM). Plug these into the calculator rather than relying on hardcoded estimates.

When LMI is NOT Cheaper

• Lambda spend below ~$1,000/month (fixed minimum execution environment cost exceeds Lambda)
• Very short functions (< 100ms duration)
• Highly bursty, unpredictable traffic
• Workloads needing scale-to-zero

Tools

• LMI Pricing Calculator — interactive comparison tool
• AWS Pricing Calculator — general AWS cost estimation

LMI Infrastructure Setup

IAM Roles (Two Required)

1. Execution Role (for the function)

Trust policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "lambda.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

Minimum permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/*"
    }
  ]
}

Add VPC permissions only if the function accesses VPC resources:

{
  "Effect": "Allow",
  "Action": [
    "ec2:CreateNetworkInterface",
    "ec2:DescribeNetworkInterfaces",
    "ec2:DeleteNetworkInterface"
  ],
  "Resource": "*"
}

2. Operator Role (for capacity provider EC2 management)

Trust policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "lambda.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

Minimum permissions (scoped with conditions):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:RunInstances", "ec2:CreateTags", "ec2:AttachNetworkInterface"],
      "Resource": [
        "arn:aws:ec2:*:*:instance/*",
        "arn:aws:ec2:*:*:network-interface/*",
        "arn:aws:ec2:*:*:volume/*"
      ],
      "Condition": {
        "StringEquals": {
          "ec2:ManagedResourceOperator": "scaler.lambda.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeCapacityReservations",
        "ec2:DescribeInstances",
        "ec2:DescribeInstanceStatus",
        "ec2:DescribeInstanceTypeOfferings",
        "ec2:DescribeInstanceTypes",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": ["ec2:RunInstances", "ec2:CreateNetworkInterface"],
      "Resource": [
        "arn:aws:ec2:*:*:subnet/*",
        "arn:aws:ec2:*:*:security-group/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:image/*",
      "Condition": {
        "StringEquals": { "ec2:Owner": "amazon" }
      }
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "<execution-role-arn>"
    }
  ]
}

The ec2:ManagedResourceOperator condition ensures RunInstances/CreateTags only apply to Lambda-managed instances. First-time capacity provider creation also requires iam:CreateServiceLinkedRole.

VPC Requirements

LMI runs functions on EC2 instances inside the VPC. These instances need VPC endpoints or NAT to reach AWS services.

• Subnets across multiple AZs recommended (minimum 1 required; 3+ for multi-AZ resiliency)
• Security groups: HTTPS egress (port 443) for AWS API calls; no ingress needed
• VPC endpoints (if no NAT gateway) for AWS service access:

CLI Workflow

Required Parameters

Automated Setup

See `scripts/setup-lmi.sh` — set the environment variables above and run:

./scripts/setup-lmi.sh <function-name> <capacity-provider-name> <architecture>

Manual Steps

# 1. Create capacity provider
aws lambda create-capacity-provider \
  --capacity-provider-name $CP_NAME \
  --vpc-config "SubnetIds=[$SUBNET_IDS],SecurityGroupIds=[$SECURITY_GROUP_ID]" \
  --permissions-config "CapacityProviderOperatorRoleArn=$OPERATOR_ROLE_ARN" \
  --instance-requirements "Architectures=[$ARCHITECTURE]" \
  --capacity-provider-scaling-config "MaxVCpuCount=30"

# 2. Create function
aws lambda create-function --function-name $FUNCTION_NAME --runtime python3.13 \
  --handler app.handler --zip-file fileb://function.zip \
  --role $EXECUTION_ROLE_ARN --architectures $ARCHITECTURE \
  --memory-size 4096 \
  --capacity-provider-config \
    "LambdaManagedInstancesCapacityProviderConfig={CapacityProviderArn=arn:aws:lambda:$AWS_REGION:$ACCOUNT_ID:capacity-provider:$CP_NAME}"

# 3. Publish version (triggers provisioning — takes several minutes)
aws lambda publish-version --function-name $FUNCTION_NAME

# 4. Invoke (must use versioned ARN)
aws lambda invoke --function-name $FUNCTION_NAME:1 --payload '{}' response.json

Architecture must match between function and capacity provider.

SAM Template

Resources:
  MyCP:
    Type: AWS::Lambda::CapacityProvider
    Properties:
      CapacityProviderName: my-cp
      VpcConfig:
        SubnetIds: [!Ref Sub1, !Ref Sub2, !Ref Sub3]
        SecurityGroupIds: [!Ref SG]
      PermissionsConfig:
        CapacityProviderOperatorRoleArn: !GetAtt OpRole.Arn
      InstanceRequirements:
        Architectures: [arm64]
      CapacityProviderScalingConfig:
        MaxVCpuCount: 30

  MyFn:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.13
      Handler: app.handler
      MemorySize: 4096
      Architectures: [arm64]
      CapacityProviderConfig:
        LambdaManagedInstancesCapacityProviderConfig:
          CapacityProviderArn: !GetAtt MyCP.Arn

Cleanup

aws lambda delete-function --function-name my-fn
aws lambda delete-capacity-provider --capacity-provider-name my-cp

Deleting the capacity provider destroys all associated EC2 instances.

LMI Migration Patterns

Before/after code examples for migrating to multi-concurrency.

Node.js

Global State

// BEFORE (race condition)
let requestCount = 0;
exports.handler = async (event) => {
  requestCount++;
  return { count: requestCount };
};

// AFTER (request-isolated)
const { AsyncLocalStorage } = require('node:async_hooks');
const als = new AsyncLocalStorage();
exports.handler = async (event) => {
  return als.run({ id: event.requestContext?.requestId }, async () => {
    return await processEvent(event);
  });
};

File I/O

// BEFORE (shared path)
fs.writeFileSync('/tmp/output.json', JSON.stringify(data));

// AFTER (request-unique path)
const path = `/tmp/output-${event.requestContext?.requestId}.json`;
try { fs.writeFileSync(path, JSON.stringify(data)); }
finally { fs.unlinkSync(path); }

Database

// BEFORE (per-invocation connection)
exports.handler = async (event) => {
  const conn = await mysql.createConnection({/*...*/});
  const [rows] = await conn.execute('SELECT ...');
  await conn.end();
};

// AFTER (shared pool)
const pool = mysql.createPool({ connectionLimit: 10, /*...*/ });
exports.handler = async (event) => {
  const [rows] = await pool.execute('SELECT ...');
  return rows;
};

Python

Python on LMI uses process-based isolation. Each concurrent invocation runs in its own process with independent memory. Global state is NOT shared, so no locking is needed. The main migration concerns are /tmp conflicts, memory sizing, and connection pooling.

Global State (No Changes Needed)

# This is SAFE on LMI — each process has its own copy of cache
cache = {}
def handler(event, context):
    cache[event['key']] = compute(event)
    return cache[event['key']]

# Module-level clients are also safe (isolated per process)
s3_client = boto3.client('s3')
dynamodb = boto3.resource('dynamodb')

File I/O (Change Required — /tmp is shared across processes)

# BEFORE (conflict — all processes share /tmp)
with open('/tmp/data.json', 'w') as f: json.dump(event, f)

# AFTER (request-unique path)
path = f'/tmp/data-{context.aws_request_id}.json'
try:
    with open(path, 'w') as f: json.dump(event, f)
finally:
    os.unlink(path)

Database (Change Required — each process needs pooled connections)

# BEFORE (per-invocation connection — exhausts limits at concurrency)
def handler(event, context):
    conn = psycopg2.connect(host='...')

# AFTER (pool per process — initialized at module level)
from psycopg2 import pool
db_pool = pool.SimpleConnectionPool(1, 3, host=os.environ['DB_HOST'])
def handler(event, context):
    conn = db_pool.getconn()
    try: return query(conn, event)
    finally: db_pool.putconn(conn)
# Note: total connections = pool_size × concurrency (e.g., 3 × 16 = 48)

Memory Sizing

# A function using 200 MB per process with default concurrency of 16:
# Total memory ≈ 200 MB × 16 = 3.2 GB
# Use 4:1 or 8:1 memory-to-vCPU ratio to accommodate
# Monitor MemoryUtilization metric and adjust as needed

Java

Global State

// BEFORE (race condition)
private static Map<String, String> cache = new HashMap<>();

// AFTER (thread-safe)
private static final ConcurrentHashMap<String, String> cache = new ConcurrentHashMap<>();
// Use cache.computeIfAbsent(key, k -> compute(k));

Database

// BEFORE (per-invocation)
Connection conn = DriverManager.getConnection("jdbc:...");

// AFTER (HikariCP pool, static init)
private static final HikariDataSource ds;
static {
    HikariConfig c = new HikariConfig();
    c.setJdbcUrl(System.getenv("DB_URL"));
    c.setMaximumPoolSize(10);
    ds = new HikariDataSource(c);
}
// Use: try (Connection conn = ds.getConnection()) { ... }

Concurrency Safety for LMI

LMI runs multiple invocations concurrently in the same execution environment. The concurrency model differs by runtime — some require thread safety, others provide process isolation.

Code Review Checklist

When reviewing a function for LMI readiness, check each item:

• [ ] No shared /tmp paths (use request ID in filenames, clean up after — shared across ALL runtimes)
• [ ] Estimate total /tmp usage under max concurrency (concurrent requests × per-request file size)
• [ ] Database connections use pools (initialized outside handler, not per-invocation)
• [ ] SDK clients outside handler (module-level singletons are fine — they are thread-safe)
• [ ] Logging includes request ID (for tracing concurrent requests)
• [ ] Node.js/Java/.NET only: No global/static mutable variables (use immutable or request-local state)
• [ ] Node.js/Java/.NET only: Thread-safe libraries only (check DB drivers, HTTP clients, caching libs)
• [ ] Node.js/Java/.NET only: No request state in global scope (use AsyncLocalStorage for Node.js, ThreadLocal for Java, AsyncLocal for .NET)
• [ ] Node.js/Java/.NET only: No environment variable mutation during requests
• [ ] Python only: Memory budget accounts for per-process multiplication (memory × concurrency)

Runtime-Specific Guidance

Python (Process-Based Isolation)

Python uses multiple independent processes, each with its own interpreter and memory space. Global variables, module-level caches, and singleton objects are duplicated per process, not shared. If a function works on standard Lambda today, it works on LMI without code changes related to shared state.

Key concerns:

• Memory consumption: total footprint ≈ per-process memory × concurrency. A 200 MB function with 16 concurrent processes can consume 3+ GB.
• /tmp filesystem is shared across all processes — use context.aws_request_id in filenames
• Each process needs its own connection pool — size pools per-process, not globally
• Prefer 4:1 or 8:1 memory-to-vCPU ratio to accommodate memory multiplication
• Monitor MemoryUtilization metric and adjust ratio if needed

Safe patterns (no locking needed):

• Module-level mutable globals (isolated per process)
• Module-level SDK clients and caches
• os.environ reads

Node.js (Worker Threads + Async/Await)

Uses worker threads (configurable via AWS_LAMBDA_NODEJS_WORKER_COUNT) combined with async/await event loops. The handler and global state are shared across concurrent invocations within a worker thread.

The await keyword yields control to the event loop, which may execute another invocation that overwrites shared state before the first resumes.

Key concerns:

• Use AsyncLocalStorage from node:async_hooks for request context
• Keep mutable state within handler local scope
• Initialize SDK clients and DB pools at module level (they are thread-safe)
• Avoid module-level mutable state (let count = 0 is a race condition)
• Callback-based handlers are NOT supported on Node.js 22 — use async handlers

Java (OS Threads)

Uses OS-level threads. Lambda loads the handler class once and invokes handleRequest from multiple threads simultaneously (identical to a Java app server).

Key concerns:

• Use immutable objects and thread-safe collections (ConcurrentHashMap, Collections.synchronizedList)
• Initialize SDK clients and connection pools in constructor or static block
• Avoid mutable static fields
• Use ThreadLocal<T> for request-specific state
• Use HikariCP or similar for connection pooling (AWS SDK for Java 2.x clients are thread-safe)

.NET (Task-Based Concurrency)

Uses a single process with .NET Tasks (same model as ASP.NET Core). The handler object is shared across all Tasks.

Key concerns:

• Use AsyncLocal<T> for request-scoped data
• Inject scoped services via DI container
• Initialize HttpClient and SDK clients as singletons
• Use ConcurrentDictionary<TKey, TValue> and SemaphoreSlim for thread-safe access
• Invocation timeouts are NOT enforced by the runtime — use ILambdaContext.RemainingTime to detect approaching timeouts

Common Anti-Patterns

Powertools for AWS Lambda Compatibility

Powertools handles multi-concurrency transparently (structured logging, tracing, metrics). No code changes needed.

AWS SDK and X-Ray minimum versions:

LMI Troubleshooting

Common Issues

Debugging Steps

Function Not Starting

1. Check capacity provider status: aws lambda get-capacity-provider --capacity-provider-name <name> 2. Verify subnets span 3+ AZs with available IPs 3. Confirm security group allows necessary egress 4. Check operator role has required permissions (see infrastructure-setup.md for least-privilege policy) 5. Look for Operator field in EC2 DescribeInstances or aws:lambda:capacity-provider tag

Performance Issues

1. Check CloudWatch metrics (5-min intervals): CPU utilization, memory, concurrency/env 2. If CPU > 80%: reduce concurrency or add vCPUs (increase memory with appropriate ratio) 3. If throttles > 1%: increase MinExecutionEnvironments 4. If CPU < 20%: increase concurrency — resources are underutilized 5. For Python: verify 4:1 or 8:1 ratio (GIL limits CPU parallelism)

Cost Issues

1. Verify instance count matches actual need (not over-provisioned) 2. Check if Savings Plans or RIs are applied to these instances 3. Compare actual costs against the 4-column estimate from cost-comparison.md 4. If traffic is lower than expected, consider reducing MaxVCpuCount 5. For dev/test: use ExcludedInstanceTypes to avoid expensive instance families