kirodotdev · sbbhimji · May 11, 2026
diff --git a/aws-lambda-managed-instances/POWER.md b/aws-lambda-managed-instances/POWER.md
@@ -0,0 +1,161 @@
+---
+name: "aws-lambda-managed-instances"
+displayName: "AWS Lambda Managed Instances"
+description: "Evaluate, configure, and migrate workloads to AWS Lambda Managed Instances (LMI). Run Lambda functions on EC2 instances in your account while AWS manages provisioning, patching, scaling, routing, and load balancing."
+keywords: ["lambda", "lmi", "managed-instances", "ec2", "capacity-provider", "multi-concurrency", "cold-start", "graviton", "cost-optimization", "serverless", "lambda-pricing", "reserved-instances", "savings-plans"]
+author: "AWS"
+---
+
+# 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.
+
+## Onboarding
+
+### Step 1: Validate AWS CLI access
+
+Before using this power, ensure AWS credentials are configured:
+
+```bash
+aws sts get-caller-identity
+```
+
+If this fails, configure credentials via `aws configure` or set `AWS_PROFILE`.
+
+### Step 2: Check regional availability
+
+Lambda Managed Instances is available in select regions. Verify availability:
+
+- [Lambda Managed Instances documentation](https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html)
+
+## When to Load Steering Files
+
+- **Cost comparison**, **pricing analysis**, **Lambda vs LMI cost**, **Savings Plans**, or **Reserved Instances** → `cost-comparison.md`
+- **Instance types**, **memory sizing**, **vCPU ratios**, **scaling tuning**, or **capacity provider config** → `configuration-guide.md`
+- **Thread safety**, **concurrency model**, **code review checklist**, **Powertools compatibility**, or **multi-concurrency readiness** → `thread-safety.md`
+- **Before/after code examples**, **runtime-specific migration** (Node.js, Python, Java, .NET), or **connection pooling** → `migration-patterns.md`
+- **IAM roles**, **VPC setup**, **CLI commands**, **SAM template**, or **CDK example** → `infrastructure-setup.md`
+- **Errors**, **throttling**, **debugging**, or **stuck deployments** → `troubleshooting.md`
+
+## Quick Decision: Is LMI Right for This Workload?
+
+| Signal | LMI is a strong fit | Standard Lambda is better |
+|--------|---------------------|---------------------------|
+| Traffic | Steady, predictable, 50M+ req/mo | Bursty, unpredictable, long idle |
+| Cost | Duration-heavy spend at scale | Low or sporadic invocations |
+| Cold starts | Unacceptable (LMI eliminates for provisioned capacity) | Tolerable or mitigated by SnapStart |
+| Compute | Latest CPUs, specific families, high network bandwidth | Standard Lambda memory/CPU sufficient |
+| Isolation | Dedicated EC2 instances in your account, full VPC control | Shared Firecracker micro-VMs acceptable |
+| Scale-to-zero | Not needed (min 3 instances always run) | Required (pay nothing when idle) |
+| Code readiness | Thread-safe (Node.js/Java/.NET) or any Python code | Non-thread-safe code, expensive to change |
+
+## Workflow
+
+### 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:
+
+| Scenario | When it wins |
+|----------|-------------|
+| Lambda on-demand | Low volume, bursty traffic |
+| LMI on-demand | High volume, steady traffic |
+
+Rule of thumb: LMI becomes cost-competitive at 50-100M+ req/month with steady traffic.
+
+Use the [LMI Pricing Calculator](https://aws-samples.github.io/sample-aws-lambda-managed-instances/) for accurate comparisons.
+
+### 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.
+- **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 (required), TargetResourceUtilization.
+
+See `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:
+
+- **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.
+
+See `thread-safety.md` for the review checklist and `migration-patterns.md` for 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 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)
+
+See `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
+
+- 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
+
+| Resource | Limit |
+|----------|-------|
+| Memory | 2 GB min, 32 GB max |
+| Instances | 3 minimum (AZ resiliency) |
+| Instance lifespan | 14 days (auto-replaced) |
+| Concurrency/vCPU | 64 (Node.js), 32 (Java/.NET), 16 (Python) |
+| Runtimes | Node.js, Java, .NET, Python |
+| Instance families | C, M, R (.large and up) |
+| Scaling | Absorbs 50% spike; doubles within 5 min |
+
+## Resources
+
+- [Lambda Managed Instances Docs](https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html)
+- [Introducing LMI (AWS Blog)](https://aws.amazon.com/blogs/aws/introducing-aws-lambda-managed-instances-serverless-simplicity-with-ec2-flexibility/)
+- [Build High-Performance Apps with LMI](https://aws.amazon.com/blogs/compute/build-high-performance-apps-with-aws-lambda-managed-instances/)
+- [Migrating Functions to LMI](https://aws.amazon.com/blogs/compute/migrating-your-functions-to-aws-lambda-managed-instances/)
+- [LMI Pricing Calculator](https://aws-samples.github.io/sample-aws-lambda-managed-instances/)
+- [LMI Samples Repository](https://github.com/aws-samples/sample-aws-lambda-managed-instances)
+- [AWS Lambda Pricing](https://aws.amazon.com/lambda/pricing/)
diff --git a/aws-lambda-managed-instances/steering/configuration-guide.md b/aws-lambda-managed-instances/steering/configuration-guide.md
@@ -0,0 +1,69 @@
+# 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
+
+| Ratio | Profile | When to use | Memory examples |
+|-------|---------|-------------|-----------------|
+| 2:1 | Compute | CPU-bound work | 2GB/1vCPU, 4GB/2vCPU |
+| 4:1 | General | Most workloads (default) | 4GB/1vCPU, 8GB/2vCPU |
+| 8:1 | Memory | Caching, data, Python apps | 8GB/1vCPU, 16GB/2vCPU |
+
+Min: 2 GB / 1 vCPU. Max: 32 GB. Memory must align with ratio multiples.
+
+## Memory Sizing from Existing Lambda
+
+| Current Lambda | LMI memory | Ratio | Rationale |
+|---------------|------------|-------|-----------|
+| 128-512 MB | 2048 MB | 4:1 | LMI minimum; multi-concurrency shares memory |
+| 512 MB-1 GB | 2048 MB | 4:1 | Room for concurrent requests |
+| 1-2 GB | 4096 MB | 4:1 | Standard upgrade path |
+| 2-4 GB | 4096-8192 MB | 4:1 or 8:1 | Depends on memory vs CPU bottleneck |
+| 4-10 GB | 8192-16384 MB | 8:1 | Likely memory-heavy workload |
+
+## Concurrency Tuning
+
+| Runtime | Default/vCPU | I/O-bound | CPU-bound |
+|---------|-------------|-----------|-----------|
+| Node.js | 64 | Keep or increase | 1 per vCPU |
+| Java | 32 | Keep | 1 per vCPU |
+| .NET | 32 | Keep | 1 per vCPU |
+| Python | 16 | Keep | 1 per vCPU |
+
+Total capacity = MinExecutionEnvironments × PerExecutionEnvironmentMaxConcurrency
+
+## Capacity Provider Scaling Controls
+
+| Control | Default | Guidance |
+|---------|---------|----------|
+| MinExecutionEnvironments | 3 | Increase for baseline capacity; never below 3 |
+| MaxExecutionEnvironments | — | Set based on cost budget |
+| MaxVCpuCount | Required | Start at 30, adjust by load |
+| TargetResourceUtilization | ~50% headroom | Raise for cost savings (less burst tolerance) |
+| AllowedInstanceTypes | All | Restrict only for specific hardware needs |
+| ExcludedInstanceTypes | None | Exclude expensive types in dev/test |
+
+## 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 limit**: 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.
diff --git a/aws-lambda-managed-instances/steering/cost-comparison.md b/aws-lambda-managed-instances/steering/cost-comparison.md
@@ -0,0 +1,17 @@
+# Lambda vs LMI Cost Comparison
+
+Use the [LMI Pricing Calculator](https://aws-samples.github.io/sample-aws-lambda-managed-instances/) 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
+
+- < 50M req/month (fixed 3-instance cost exceeds Lambda)
+- Very short functions (< 100ms duration)
+- Highly bursty, unpredictable traffic
+- Workloads needing scale-to-zero
+
+## Tools
+
+- [LMI Pricing Calculator](https://aws-samples.github.io/sample-aws-lambda-managed-instances/) — interactive comparison tool
+- [AWS Pricing Calculator](https://calculator.aws/) — general AWS cost estimation