Setting Min=0/Max=0 on Lambda Managed Instances deactivates the function version

What a zero scaling configuration actually does

AWS Lambda Managed Instances (LMI), the deployment mode that runs Lambda functions on EC2 capacity in your account while preserving the Lambda programming model, behaves very differently from standard Lambda when its scaling settings are set to zero. According to a hands-on writeup on dev.to, coverage since re:Invent 2025 has mostly focused on the lifted memory ceiling and on EC2-backed pricing that accepts Savings Plans and Reserved Instances. The scaling configuration, by contrast, has gone largely unexamined — and the author's central finding contradicts what most engineers would assume.

A hard failure, not a slow cold start

AWS enforces a pairing rule: a minimum of zero is accepted only when the maximum is also zero. And when both sit at zero, Lambda does not idle the function and wait for traffic. It deactivates the version. Per the post, every EC2 Managed Instance backing the version is terminated, and charges continue until termination actually finishes rather than stopping the moment the configuration is saved. The version's state changes to Deactivated, and any invocation against it returns an explicit error — there is no cold start, no queueing and no retry.

Reactivation never happens on its own. You have to push a fresh scaling configuration with non-zero values through the console, the PutFunctionScalingConfig API, or a scheduled action. The author notes this is the opposite of how ReservedConcurrentExecutions=0 or standard Lambda concurrency throttling behaves, and describes it as the most important operational difference between LMI and ordinary Lambda for anyone running non-continuous workloads.

Setup friction not covered in the docs

LMI requires a Capacity Provider, a separate resource defining the VPC, subnets and security groups that instances launch into, the eligible architecture (x86_64 or arm64) and instance types, the scaling mode (Auto or Manual), and the IAM "Operator Role" Lambda uses to manage EC2 on your behalf. Functions attach to a provider at creation time, and only published versions — never $LATEST — receive EC2 capacity.

The writeup, verified against a live AWS account, documents several dead ends:

• The console attachment point has moved. Older documentation describes a "Compute type" setting, but the current console exposes an EC2 capacity provider toggle under Custom settings. Memory size and the memory-per-vCPU ratio (2:1, 4:1 or 8:1) are configured per function in that panel, not on the provider.
• Architectures must match exactly. A function whose architecture differs from the provider's — which is fixed when the provider is created — is rejected at save time with the error "You cannot use a Lambda Managed Instances function with a capacity provider that does not support the architecture of the function." There is no coercion, no fallback and no cross-architecture provider.
• Publishing never asks for scaling values. They live separately under Configuration → Function scaling configuration. Until explicitly edited, AWS's default behaviour provisions three Managed Instances spread across availability zones before a version is marked Active — and that default is invisible in the panel until you open it for editing.

Versioning behaves in reverse

$LATEST on LMI reports the state ActiveNonInvocable, a documented value meaning it cannot run instances. LMI introduces $LATEST.PUBLISHED, a republishable pseudo-version that does get capacity and that the console generates automatically. Invoking the function through its unqualified ARN implicitly targets $LATEST.PUBLISHED — the reverse of standard Lambda, where unqualified invokes resolve to $LATEST.

Running, billing, invisible

Even with a version Active, its backing instances will not appear in the EC2 console, and describe-instances filtered by capacity-provider tags returns nothing. The cause, per the post, is an account-wide EC2 setting called managed resource visibility, introduced in April 2026, which hides EC2 resources provisioned by services such as LMI, EKS Auto Mode and ECS Managed Instances from the console and Describe* APIs for accounts that had no managed resources before the setting existed. The instances are running and billing regardless; the setting is purely a display filter, and the post includes the CLI command to change it.

Why it matters

The instinct to set a minimum of zero to save money — reasonable on standard Lambda — produces outright invoke failures on LMI, which makes the scaling configuration load-bearing infrastructure rather than a tuning knob. Costs also start accruing by default, three instances per version, before anyone touches the settings, and the EC2 visibility filter can conceal exactly the resources driving those costs. Teams adopting LMI for its pricing benefits should treat scaling values as code, verify version states before relying on them, and adjust the visibility setting so EC2 spend can actually be audited.