Lambda Managed Instances (2026): Scheduled Scaling, 32 GB / 16 vCPU, and Ops Playbook

Between March and May 2026, AWS raised Lambda Managed Instances (LMI) ceilings to 32 GB memory / 16 vCPUs, raised the Managed Instances file-descriptor limit to 4,096, and GA’d scheduled scaling through Amazon EventBridge Scheduler calling PutFunctionScalingConfig (32 GB / 16 vCPU, FD limit, scheduled scaling, scaling guide).

This is the ops playbook for those controls. It does not recap the March service-announcements post or replace event-throughput tier selection.

Artifacts: scaling decision matrix, scheduler script, architecture diagram (draw.io).

How LMI scaling differs from classic Lambda

Per AWS docs:

If traffic more than doubles within five minutes, expect possible throttles while Scaler launches instances and execution environments. That is the core ops constraint this playbook designs around.

API clients ──► API Gateway / ALB ──► LMI function (Capacity Provider)
                                         │
                     EventBridge Scheduler ──► PutFunctionScalingConfig (min/max EE)
                                         │
                              Lambda Scaler ← CPU + concurrency signals

Reference architecture

Figure: clients hit API Gateway; LMI Capacity Provider hosts multi-concurrent EEs; EventBridge Scheduler lifts and lowers Min/MaxExecutionEnvironments around business hours. Open draw.io

The five controls (set in this order)

1. Memory and vCPU

Minimum 2 GB / 1 vCPU. Ratios: 2:1, 4:1, 8:1. Ceiling (Mar 2026): 32 GB / 16 vCPUs. Python often needs 4:1 or 8:1 under multi-concurrency.

2. Maximum concurrency per execution environment

Default Lambda values aim for balance. Raise only when CPU is low (up to 64 concurrent requests per vCPU). Lower when memory dominates. Monitor ConcurrencyThrottles, CPUThrottles, MemoryThrottles, DiskThrottles before guessing.

3. Min / Max execution environments

Defaults: min=3 (AZ spread), no hard max unless you set one. Pair both on PutFunctionScalingConfig. 0/0 deactivates the qualified version without deleting the function.

# AWS CLI example — PutFunctionScalingConfig (docs-aligned)
aws lambda put-function-scaling-config \
  --function-name my-lmi-function \
  --qualifier '$LATEST.PUBLISHED' \
  --function-scaling-config MinExecutionEnvironments=5,MaxExecutionEnvironments=80 \
  --region us-east-1

4 and 5. Capacity Provider resource utilization and instance types

Tune target utilization and allowed instance families at the Capacity Provider when the function already has a healthy memory/concurrency profile. Do not start here.

Scheduled scaling (May 2026)

Create EventBridge schedules that target the universal SDK ARN arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig with MinExecutionEnvironments / MaxExecutionEnvironments in the input. IAM role needs lambda:PutFunctionScalingConfig on the function ARN.

Opinionated recommendation

Use LMI when you have multi-concurrent, compute- or I/O-pool heavy APIs with known diurnal peaks and want Lambda packaging without owning ECS services. Stay on classic Lambda when the main cost is idle time you want at true zero without Scheduler discipline. Prefer ECS/EKS when you need custom runtimes, sidecars, GPU, or jobs longer than 90 minutes. Async and ESM invokes on LMI can run 90 minutes as of 9 Sep 2026. See the timeout decision guide. Classic on-demand and synchronous invokes stay at 15 minutes.

What to do this week

1. Score the workload with lmi-scaling-decision-matrix.md.
2. Confirm Capacity Provider + published qualifier ($LATEST.PUBLISHED semantics).
3. Graph the four throttle metrics for seven days.
4. Ship Monday to Friday scale-up / scale-down schedules.
5. Tag the function and verify idle hours drop in Cost Explorer.

What this post doesn’t cover

• Lambda Durable Functions (Dec 2025 / separate orchestration model)
• Graviton vs x86 capacity provider SKUs: region-specific; verify Current Generation types in your account
• VPC ENI density math for dense EE packing: network engineering follow-up
• Full TCO vs Fargate: use high-throughput event tier for queue/stream choice

We have not published a multi-region active-active LMI failover drill. Treat single-region EE floors as the current safe operating envelope unless your team has already run one.

Related: AWS serverless services · Architecture review · Cost optimization

Frequently asked questions