Notifications
Clear all
Topic starter
18/08/2026 2:43 pm
TL;DR: AWS Lambda Managed Instances run Lambda functions on EC2-backed infrastructure with explicit restrictions on role attachment, instance access, and runtime modification, according to OFFENSAI’s security overview. The design reduces obvious attack paths but also shifts practitioner attention toward isolation, credential handling, and runtime trust boundaries in hybrid serverless environments.
NHIMG editorial — based on content published by OFFENSAI: AWS Lambda Managed Instances: A Security Overview
Questions worth separating out
Q: How should teams govern Lambda workloads that run on managed instances?
A: Treat the Lambda execution role as the primary identity boundary and verify that host access cannot be used to widen it.
Q: Why do serverless workloads still need strict NHI governance?
A: Serverless does not remove identity risk because functions still depend on roles, keys, tokens, and permissions to operate.
Q: What breaks when instance-level access is assumed to equal workload access?
A: That assumption breaks the security model by turning infrastructure controls into a shortcut for workload impersonation.
Practitioner guidance
- Review Lambda role boundaries Map every Lambda function role to the exact permissions it needs and confirm that no host-level action can widen that scope inside managed instances.
- Test for control-plane separation Validate that instance-profile operations, SSM-style access, and console-based escalation paths remain blocked in your own managed compute assumptions.
- Document temporary credential flows Identify how short-lived credentials are issued and revoked for Lambda workloads so the function identity cannot outlive its intended session boundary.
What's in the full article
OFFENSAI's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step AMI inspection workflow used to infer how Lambda Managed Instances is built
- File-level observations from the Bottlerocket image, including Elevator services and binaries
- The author's direct testing notes on EC2 Instance Profile denial and direct access limitations
- Tooling references such as investigator.cloud, CloudShovel, and coldsnap for deeper runtime analysis
👉 Read OFFENSAI's security overview of AWS Lambda Managed Instances →
AWS Lambda Managed Instances: what changes for security teams?
Explore further
18/08/2026 3:26 pm
Serverless abstractions do not remove identity governance. They relocate it. Lambda Managed Instances is a reminder that the control problem shifts from host administration to workload identity, runtime isolation, and control-plane trust. The function role remains the object that matters, even when the underlying compute is managed by the cloud provider. Practitioners should evaluate Lambda-like services as identity-bearing execution environments, not as identity-free utilities.
A question worth separating out:
Q: What should security teams do when cloud providers hide the worker layer?
A: Verify the trust model through identity boundaries, telemetry, and change control rather than expecting direct shell access. If you cannot inspect the worker, you need stronger evidence that the provider can isolate tenants, bind credentials correctly, and revoke access cleanly. The burden shifts from admin access to assurance.
👉 Read our full editorial: AWS Lambda Managed Instances change the serverless security model
