---
title: Lambda Managed Instances (2026): Scheduled Scaling, 32 GB / 16 vCPU, and Ops Playbook
description: After the March to May 2026 LMI updates (32 GB / 16 vCPU, 4,096 FDs, EventBridge scheduled scaling), a B2B analytics API (~40k peak RPM, 9 to 6 UTC) cut idle capacity hours ~62% by scheduling MinExecutionEnvironments from 20 to 3 off-peak.
url: https://www.joinhorizon.co/blog/aws-lambda-managed-instances-2026-operations-guide/
datePublished: 2026-07-08T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: manojkumar-varatharajan
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 the March to May 2026 LMI updates (32 GB / 16 vCPU, 4,096 FDs, EventBridge scheduled scaling), a B2B analytics API (~40k peak RPM, 9 to 6 UTC) cut idle capacity hours ~62% by scheduling MinExecutionEnvironments from 20 to 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. It does not recap the March service-announcements post or replace [event-throughput tier selection](https://www.joinhorizon.co/blog/aws-high-throughput-event-processing-tier-selection-2026/).

Artifacts: [scaling decision matrix](https://www.joinhorizon.co/examples/architecture-blog-2026/lambda-managed-instances-ops/lmi-scaling-decision-matrix.md), [scheduler script](https://www.joinhorizon.co/examples/architecture-blog-2026/lambda-managed-instances-ops/put-function-scaling-scheduler.sh), [architecture diagram (draw.io)](https://www.joinhorizon.co/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 to 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.joinhorizon.co/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 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.

> **Reproduce this:** Clone the repo path [`examples/architecture-blog-2026/lambda-managed-instances-ops/put-function-scaling-scheduler.sh`](https://www.joinhorizon.co/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 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](https://www.joinhorizon.co/blog/aws-lambda-managed-instances-90-minute-timeout-2026/). 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](https://www.joinhorizon.co/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 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](https://www.joinhorizon.co/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](https://www.joinhorizon.co/services/aws-serverless/) · [Architecture review](https://www.joinhorizon.co/services/aws-architecture-review/) · [Cost optimization](https://www.joinhorizon.co/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.joinhorizon.co/blog/aws-lambda-managed-instances-2026-operations-guide/*