Build1 publisher2 min readPublished
Min=0 on a Lambda Managed Instances version deactivates it until someone pushes non-zero values
The scaling settings engineers carry over from standard Lambda do not mean the same thing on Lambda Managed Instances. A walkthrough verified on a live AWS account shows the failure mode is a hard error.
The Engineer · Build desk
What happened
- On Lambda Managed Instances, Lambda accepts a minimum of zero execution environments only when the maximum is also zero, so the two settings are paired.
- Saving both at zero deactivates the published function version and terminates every EC2 Managed Instance behind it.
- An invocation against a deactivated version returns an explicit error immediately, with no queueing and no retry, so the caller sees a failure instead of a slow start.
- The version comes back only when someone pushes a non-zero scaling configuration through the console, the PutFunctionScalingConfig API, or a scheduled action.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost The saving from zeroing a version starts later than the config change does, because instance charges run until termination completes, and the account pays for the drain window.
- decision A team that wants nights and weekends off has to schedule two actions instead of one; scheduling only the shutdown schedules an outage that lasts until a human notices.
- constraint There is no LMI setting that gives an idle function zero cost and a working first request, so the choice is paying for a warm floor or taking the version offline deliberately.
- exposure Callers and event sources that were built to treat a zero-concurrency Lambda as a throttle to retry through are now pointed at a version that stays down until its config is rewritten.
Getting to the pairing rule takes more setup than standard Lambda does. LMI needs a Capacity Provider first. That is a separate resource fixing the VPC, subnets and security groups the instances launch into, the eligible architecture and instance types, the scaling mode of Auto or Manual, and the IAM Operator Role Lambda uses to manage EC2 on your behalf [10]. A function attaches to that provider at creation time through its compute type. The two scaling numbers only mean anything once the attachment exists, and only on a published version, not on `$LATEST` [11].
Attachment is where the first hard failure lands. The provider's `InstanceRequirements.Architectures` is set when the provider is created, with no coercion and no fallback afterwards; the walkthrough's provider was `arm64` [12]. A function whose architecture toggle did not match failed on save with "You cannot use a Lambda Managed Instances function with a capacity provider that does not support the architecture of the function." [13]. That rejection happens at function creation, so this one surfaces before any traffic does.
The console uses different labels than older AWS documentation describes. The setting is the EC2 capacity provider toggle under Custom settings. Turning it on opens a side panel for the provider ARN, the memory size and the memory-per-vCPU ratio [14]. Memory and the ratio, 2:1, 4:1 or 8:1, are set per function, not per capacity provider [15].
Once a zeroed scaling configuration is saved, the version's `State` field reads `Deactivated` [5].
All of this comes from one walkthrough on dev.to. The author reports verifying the behaviour against a live AWS account, and the CLI output shows a us-east-1 capacity provider in `State` `Active` with `ScalingMode` `Auto`, two subnets and one security group [16]. For the pairing rule to behave the same way elsewhere, the API contract has to be identical in your region. Your provider also has to be created with the architecture your function will actually use. The post documents a single provider and a single function.
Most coverage since re:Invent 2025 has gone to the memory ceiling coming off and to the EC2-backed pricing that lets Savings Plans and Reserved Instances apply [2]. Those are purchasing questions. LMI keeps the Lambda programming model while running the function on EC2 capacity you control [1]. The capacity configuration is the part of a migration that needs re-planning: publish a version, attach a provider whose architecture matches, and set a minimum you are willing to pay to keep warm.
What to watch
- Whether AWS documents the pairing rule and the Deactivated state in the LMI scaling reference, or changes the API to reject a zero minimum outright.
- Whether PutFunctionScalingConfig ever gains a reactivate-on-invoke option, which would restore the standard Lambda mental model.
- Whether InstanceRequirements.Architectures becomes editable after capacity provider creation.