LMI fundamentals
These articles split Lambda Managed Instances (LMI) into single-topic pages: where workloads run, how fleets scale, isolation and roles, sandbox behaviour, what publishing activates, and how you connect, observe, and respect limits. Use them to reason about design before you touch procedural sections.
Suggested reading order (matches the sidebar): Placement & capacity → Elasticity & CPU → Tenancy & isolation → IAM roles → Concurrency & runtimes → Publishing & activation → Networking → Monitoring → Quotas. For procedures, continue to Walkthrough after fundamentals.
For quotas, API fields, and region-specific behaviour, use Lambda Managed Instances as the product reference.
Articles
Section titled “Articles” Placement & capacity Where workloads run: VPC wiring, instance requirements, provider-level controls, and what remains fully managed.
Elasticity & CPU How fleet size tracks CPU load; separating managed instances from execution environments.
Tenancy & isolation Shared Lambda infrastructure versus dedicated Nitro capacity; trust boundaries and isolation models.
IAM roles Function execution trust versus the managed-EC2 operator trust Lambda uses to run your fleet.
Concurrency & runtimes Single-invoke versus multi-invoke sandboxes, runtime constraints, and IO-bound workload fit.
Publishing & activation What “publish” triggers: managed instances, execution environments, ACTIVE versions, and capacity reuse.
Networking VPC outbound paths: public subnet and IGW, VPC endpoints, or private subnets with NAT.
Monitoring CloudWatch metrics at capacity-provider and execution-environment levels.
Quotas API rates, per-account and per-provider limits, and event source mapping throughput.
Decision guide & reference Trade-offs versus default Lambda, economics, integrations, guardrails, pattern cards, and neutral Terraform sketches.
Introduction What LMI is, why EC2 underpins it, the three-step flow, and how this site is organised.