---
title: Lambda Managed Instances (2026): Scheduled Scaling, 32 GB / 16 vCPU, and Ops Playbook
description: After Mar–May 2026 LMI updates (32 GB / 16 vCPU, 4,096 FDs, EventBridge scheduled scaling), a B2B analytics API (~40k peak RPM, 9–6 UTC) cut idle capacity cost ~62% by scheduling MinExecutionEnvironments 20→3 off-peak.
url: https://www.factualminds.com/blog/aws-lambda-managed-instances-2026-operations-guide/
datePublished: 2026-07-08T00:00:00.000Z
dateModified: 2026-07-08T00:00:00.000Z
author: palaniappan-p
category: Serverless & Containers
tags: aws, aws-lambda, lambda-managed-instances, eventbridge, serverless, cost-optimization
---

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

> After Mar–May 2026 LMI updates (32 GB / 16 vCPU, 4,096 FDs, EventBridge scheduled scaling), a B2B analytics API (~40k peak RPM, 9–6 UTC) cut idle capacity cost ~62% by scheduling MinExecutionEnvironments 20→3 off-peak.

**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](https://aws.amazon.com/about-aws/whats-new/2026/03/lambda-32-gb-memory-16-vcpus/), [FD limit](https://aws.amazon.com/about-aws/whats-new/2026/03/aws-Lambda-file-descriptors-increase-4096/), [scheduled scaling](https://aws.amazon.com/about-aws/whats-new/2026/05/aws-lambda-managed-instances/), [scaling guide](https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-scaling.html)).

This is the **ops playbook** for those controls — not a recap of the March service-announcements post and not a substitute for [event-throughput tier selection](/blog/aws-high-throughput-event-processing-tier-selection-2026/).

Artifacts: [scaling decision matrix](https://www.factualminds.com/examples/architecture-blog-2026/lambda-managed-instances-ops/lmi-scaling-decision-matrix.md), [scheduler script](https://www.factualminds.com/examples/architecture-blog-2026/lambda-managed-instances-ops/put-function-scaling-scheduler.sh), [architecture diagram (draw.io)](https://www.factualminds.com/examples/architecture-blog-2026/lambda-managed-instances-ops/lambda-managed-instances-ops-architecture.drawio).

> **First-party benchmark silhouette** — **B2B analytics API**, **~40k peak RPM**, **9–6 UTC weekday traffic**, Node 22 on LMI **4:1** ratio. Before schedule: floor left at **min=20 EE** overnight. After EventBridge cron (**min=20** at 08:00 UTC, **min=3** at 18:00 UTC): measured **~62% drop** in idle capacity hours on that function version over a two-week sample (Cost Explorer filtered by function tag). Numbers are account-level and will vary with instance type mix.

## How LMI scaling differs from classic Lambda

Per AWS docs:

| Mode           | Scales when                                                       | Cold starts                                      |
| -------------- | ----------------------------------------------------------------- | ------------------------------------------------ |
| Classic Lambda | No free EE for an invocation                                      | Yes (unless Provisioned Concurrency / SnapStart) |
| LMI            | Async on **CPU utilization** and **multi-concurrency saturation** | No cold-start model of classic Lambda            |

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

![Lambda Managed Instances with EventBridge scheduled capacity envelopes](../../assets/images/blog/aws-lambda-managed-instances-2026-operations-guide.webp)

_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](https://www.factualminds.com/examples/architecture-blog-2026/lambda-managed-instances-ops/lambda-managed-instances-ops-architecture.drawio)_

## 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.

```bash
# 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–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 — the May 2026 unlock

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.

> **Reproduce this** — Clone the repo path [`examples/architecture-blog-2026/lambda-managed-instances-ops/put-function-scaling-scheduler.sh`](https://www.factualminds.com/examples/architecture-blog-2026/lambda-managed-instances-ops/put-function-scaling-scheduler.sh). Replace role ARN and peak numbers, then `bash put-function-scaling-scheduler.sh my-lmi-fn ACCOUNT us-east-1`. Validate with `aws scheduler list-schedules --name-prefix lmi-scale`.

> **What broke** — Week two after LMI move. Ops raised **PerExecutionEnvironmentMaxConcurrency** to discard `ConcurrencyThrottles` while **CPUThrottles** spiked and p95 rose ~**400 ms → 1.9 s**. **Fix:** roll concurrency back, move ratio **4:1 → 2:1**, keep Scheduler min warm at 08:00. **Lesson:** concurrency is not a substitute for vCPU.

## 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 spouse of the bill is idle time you want at true zero without Scheduler discipline. **Prefer ECS/EKS when** you need custom runtimes, sidecars, or >15-minute tasks.

## What to Do This Week

1. Score the workload with [lmi-scaling-decision-matrix.md](https://www.factualminds.com/examples/architecture-blog-2026/lambda-managed-instances-ops/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–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)
- **Gravition 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](/blog/aws-high-throughput-event-processing-tier-selection-2026/) 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](/services/aws-serverless/) · [Architecture review](/services/aws-architecture-review/) · [Cost optimization](/services/aws-cloud-cost-optimization-services/)

## FAQ

### When should we NOT use Lambda Managed Instances?
Skip LMI for bursty event handlers where classic Lambda scale-to-zero + Provisioned Concurrency is cheaper, for single-concurrency scripts that never need multi-request EEs, and when you need multi-minute GPU or custom AMI control that already lives on ECS/EKS.

### What goes wrong if traffic more than doubles in five minutes?
LMI scales asynchronously on CPU and multi-concurrency saturation — not on cold-start demand. AWS docs warn that doubling traffic inside five minutes can throttle while instances and execution environments catch up. Pre-raise MinExecutionEnvironments with EventBridge Scheduler before known peaks.

### Do scheduled scaling and classic auto scaling conflict?
No. Schedules call PutFunctionScalingConfig to move the min/max envelope; the Scaler still adjusts within that envelope based on CPU and concurrency. Setting both min and max to 0 deactivates the qualified version without deleting the function.

### How do memory:vCPU ratios map to instance families?
Supported ratios are 2:1 (compute), 4:1 (general), and 8:1 (memory). Minimum function size is 2 GB / 1 vCPU. Cap is 32 GB / 16 vCPUs (March 2026). Python workloads often need 4:1 or 8:1 because of multi-concurrency memory pressure.

### Does the 4,096 file descriptor limit apply to classic Lambda?
No — the increase from 1,024 to 4,096 is documented for functions running on Managed Instances. Classic Lambda still uses its platform FD limits; do not assume LMI limits apply to default Lambda.

### How is this different from the event-throughput tier post?
The event-throughput guide picks SQS vs Kinesis vs Express Mode. This post assumes you already chose LMI for compute-heavy multi-concurrent APIs and covers capacity envelopes, FD pools, and scheduled scaling ops.

---

*Source: https://www.factualminds.com/blog/aws-lambda-managed-instances-2026-operations-guide/*