AWS Lambda Managed Instances: A Security Overview

Part of our AWS re:Invent 2025 Security Analysis Series

Introduction

During the AWS re:Invent 2025 season, Amazon announced Lambda Managed Instances, a new capability that allows Lambda functions to run on EC2 instances (not so serverless now, am I right?). This feature offers access to specialized hardware and EC2 pricing models (Compute Savings Plans, Reserved Instances) while AWS manages the underlying infrastructure.

This post provides an initial security overview of Lambda Managed Instances based on early exploration of the feature.

Initial Setup and Access Restrictions

When setting up Lambda Managed Instances, AWS creates EC2 instances in your account to run your Lambda functions. Trying to specify the allowed instance types didn't really work out, as I received the same error for multiple cheaper types. In the end I allowed any instance type and AWS spawned 3 m7l.xlarge instances for a single "Hello, World!" function.

IAM Role Attachment Blocked

My initial thought was to test for EC2 IMDS access from inside the Lambda Function. However, attempting to attach or modify IAM roles on Lambda Managed Instances results in an explicit deny:

Failed to attach instance profile
You are not authorized to perform this operation.
User: arn:aws:sts::XXXX:assumed-role/AWSReservedSSO_Administrator/
is not authorized to perform: ec2:AssociateIamInstanceProfile on resource:
arn:aws:ec2:us-east-1:XXXX:instance/i-061b3cb56f4eaa3d5
with an explicit deny in a resource-based policy.

This makes sense. Since the Lambda Function has its own role, there is no need to allow people grant overprivileged permissions to the instance and increase the attack surface of this feature. However, this raises another question: With access inside the instance, can we impersonate the Lambda Function and retrieve the function's role?

No Direct Instance Access

To answer the last question: I'm not sure. Standard instance connection methods (SSM, SSH, EC2 Instance Connect) are unavailable. Even launching a new EC2 instance from the same AMI doesn't provide access, suggesting AWS uses additional runtime controls beyond just the base image.

This limits our capability to analyze and try to abuse how Lambda Functions retrieve their role during runtime.

More Locked Down Than Other Managed Instances

Lambda Managed Instances isn't the only AWS service that spawns EC2 instances in your account. ECS Container Instances, EKS Managed Node Groups, EMR clusters, and SageMaker endpoints follow a similar pattern. However, Lambda Managed Instances appears to be more restrictive. With ECS or EKS managed nodes, you can typically access instances via SSM and modify IAM roles. Lambda Managed Instances explicitly denies these operations, likely because multiple Lambda invocations (and the new multiconcurrency feature) share the same underlying instance, requiring stronger isolation guarantees.

Under the Hood: Bottlerocket and "Elevator"

Using investigator.cloud, a web platform built by Seth Art using a modified version of CloudShovel (a security tool I developed together with Matei Josephs), we can examine the AMI used by Lambda Managed Instances without direct instance access.

The technique follows the pattern we used for our research AWS CloudQuarry: Digging for secrets in public AMIs presented at DEF CON 32:

• Start an EC2 instance based on the AMI aws-lambda-managed-instances-prod-1-x86_64-v1.0.5256-0
• Stop the instance and detach the volume(s)
• Reattach and mount the volumes on a separate EC2 (coined by us as Secret Searching instance)
• Analyze the data within the volumes

Downloading all the file names from the AMI, we can see some interesting things. First, Lambda Managed Instances run on Bottlerocket OS, AWS's container-optimized Linux distribution.

Second, throughout the system, AWS uses the codename "Elevator" for Lambda Managed Instances components. Key services and binaries include:

Core Services:

aws-lambda-elevator-agent.service
aws-lambda-elevator-cgroup-setup.service
aws-lambda-elevator-network-presetup.service
aws-lambda-elevator-sensor-service.service
aws-lambda-elevator-worker-environment-setup.service

Key Binaries:

/usr/sbin/elevator-network-presetup
/usr/sbin/elevator-worker-environment-setup
/usr/sbin/aws-lambda-elevator-worker-ephemeral-storage
/usr/sbin/raptor

Execution Architecture Insights

Based on the file system structure, Lambda functions appear to execute as containerd containers, managed by the "Raptor" component. The execution flow seems to follow:

1. Network Setup (elevator-network-presetup.service) - Configures network isolation
2. CGroup Configuration (elevator-cgroup-setup.service) - Sets resource limits
3. Worker Environment (elevator-worker-environment-setup.service) - Prepares execution context
4. Lambda Agent (elevator-agent.service) - Manages function lifecycle
5. Sensor Service (elevator-sensor-service.service) - Monitoring/telemetry (purpose unclear)

The presence of an elevator.slice systemd slice suggests resource isolation at the systemd level, likely containing all Lambda execution environments.

Telemetry and Monitoring

AWS includes the "Fluxpump" monitoring system:

/usr/sbin/fluxpump
/usr/sbin/fluxpump_elevator_client
/usr/sbin/fluxpump-customer.yaml
/usr/sbin/fluxpump-host.yaml

This appears to be AWS's internal telemetry system for Lambda Managed Instances, with separate configurations for customer-visible metrics and host-level monitoring.

Network Configuration

The system includes several network-related components:

• wait-for-eth1.service - Suggests multi-NIC configuration
• netdog - Network configuration management
• Separate network configuration templates in /usr/share/bottlerocket/net.toml

The multi-interface design is interesting from a security perspective—it likely enables network isolation between Lambda execution environments and AWS control plane communication.

Security Observations

The overall immutable infrastructure approach limits both the attack surface and persistence opportunities for potential attackers.

One of the questions that might be worth answering is how AWS grants temporary access credentials to Lambda Functions with different roles. It might be an opportunity for the community to get insights into how AWS manages Lambda Functions in general and look for ways to evade the context of the function.

For those interested in deeper analysis, coldsnap allows you to download EBS volumes locally. By converting the AMI's volumes into snapshots, you can download, mount, and analyze the binaries on your own machine.

Conclusion

AWS Lambda Managed Instances represents an interesting convergence of serverless and traditional compute models. From a security perspective, AWS appears to have built this on a solid foundation using Bottlerocket OS, containerd, and multiple layers of isolation.

More than anything, this might be a peek behind the curtains on how Lambda Functions work, allowing researchers to possibly use this research opportunity to find cross-tenant attacks that will work with the classic serverless functions.

This is part of OFFENSAI's re:Invent 2025 security analysis series, where we provide quick security overviews of newly announced AWS features. For more in-depth research and offensive security insights, visit offensai.com.

Disclosure: This analysis was conducted using publicly available information and documented AWS features. No vulnerabilities were identified during this initial exploration. If you discover security issues with AWS Lambda Managed Instances, please report them through AWS's Vulnerability Disclosure Program.

About the Tools:

• CloudShovel: An open-source security tool for AWS AMI analysis developed by Eduard Agavriloae and Matei Josephs
• investigator.cloud: A web platform by Seth Art that extends CloudShovel's capabilities for collaborative security research
• coldsnap: An official command line interface for downloading Amazon EBS snapshots