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

Placement & capacityWhere workloads run: VPC wiring, instance requirements, provider-level controls, and what remains fully managed.

Elasticity & CPUHow fleet size tracks CPU load; separating managed instances from execution environments.

Tenancy & isolationShared Lambda infrastructure versus dedicated Nitro capacity; trust boundaries and isolation models.

IAM rolesFunction execution trust versus the managed-EC2 operator trust Lambda uses to run your fleet.

Concurrency & runtimesSingle-invoke versus multi-invoke sandboxes, runtime constraints, and IO-bound workload fit.

Publishing & activationWhat “publish” triggers: managed instances, execution environments, ACTIVE versions, and capacity reuse.

NetworkingVPC outbound paths: public subnet and IGW, VPC endpoints, or private subnets with NAT.

MonitoringCloudWatch metrics at capacity-provider and execution-environment levels.

QuotasAPI rates, per-account and per-provider limits, and event source mapping throughput.

Decision guide & referenceTrade-offs versus default Lambda, economics, integrations, guardrails, pattern cards, and neutral Terraform sketches.

IntroductionWhat LMI is, why EC2 underpins it, the three-step flow, and how this site is organised.