For a long time, my understanding of the AWS architecture presumed a hierarchical structure, like AWS Cloud ⊃ Region ⊃ VPC ⊃ Subnet, where all resources resided within a customer-defined VPC, which in turn exists within an AWS Region. Connectivity to external Regional Services (such as S3) required mechanisms like NAT Gateways or VPC Endpoints.

However, subsequent study for DOP-C02 certification revealed that AWS Lambda’s network configuration deviates from this conventional model, particularly when connecting to private resources within a customer’s VPC. Contrary to the assumption that Lambda execution environments are instantiated inside the account’s VPC Subnet, a deeper inspection confirmed otherwise.

While this mechanism may be known to many, this post aims to provide a detailed explanation of the underlying architecture.

Basic regional and VPC network architecture

We first review the standard network architecture of AWS Regions and VPCs, and their inherent network relationships.

• AWS Region: The geographical location hosting the AWS Cloud infrastructure and Availability Zones (AZs).
• VPC: A logically isolated, private virtual network space defined by the account. This space is created within the Region. Resources are isolated from external networks by default.
• Regional Services (S3, DynamoDB, …): Services that are regional in scope but exist outside the scope of the account’s VPC. These are external to the VPC boundary. Any connectivity requires specific routing mechanisms, e.g., Internet Gateway, NAT Gateway, or VPC Endpoints.
• Instance Resources (EC2, RDS): These resources provisioned by the account within a VPC Subnet and directly deployed within the VPC’s Subnet and adhere to its network rules.

So, how about Lambda?

The core question then becomes: How does an AWS Lambda function establish access to private resources such as RDS located within a private subnet in VPC?

Lambda’s Real Network Architecture

When a Lambda function is configured for VPC access, the following process is executed:

1. The Lambda service executes the function within the AWS-Managed Lambda Service VPC.
2. The Lambda service provisions an Elastic Network Interface (ENI) within the designated private subnet of the customer’s VPC.
3. This ENI is assigned a private IP address from the customer’s VPC range and respects the customer’s Security Group and Route Table configurations.
4. The Lambda function’s execution environment, which remains in the AWS-Managed VPC, utilizes this provisioned ENI to proxy secure, private network traffic to the resources within the customer’s VPC.

Thus, Lambda functions do not reside within the customer’s VPC; rather, they establish a managed, cross-VPC network tunnel to facilitate communication.

The Hyperplane ENI

The practical principle behind this architecture is the Hyperplane ENI technology.

Hyperplane ENI Network Architecture: https://aws.amazon.com/ko/blogs/korea/announcing-improved-vpc-networking-for-aws-lambda-functions/

From the year 2019, the method by which Lambda functions connect to a VPC has been changed. AWS Hyperplane is the Network Function Virtualization platform used for NLB and NAT Gateway, which has supported cross-VPC connectivity for products like AWS PrivateLink.

The key takeaways from the announcement about the Hyperplane ENI are:

• The prior model required the creation of a dedicated ENI for each Lambda execution environment within the customer VPC, leading to increased cold start latency and rapid exhaustion of account VPC IP addresses upon scaling.
• So, the Hyperplane ENI has been applied. It acts as a managed network proxy connecting the Lambda Service VPC to the account’s VPC. This ENI is a managed resource controlled by the Lambda service, allowing multiple Lambda execution environments to securely share a single network interface to access VPC resources.
• The pre-created Hyperplane ENIs significantly reduces cold-start delays associated with network interface creation and prevent IP address consumption in the account’s VPC.

Please refer to this official AWS blog for comprehensive details on this technology.

Then, other services?

This specialized network architecture suggests a broader pattern for how AWS managed services operate.

I guess that other AWS managed services, such as DynamoDB or Aurora Serverless, may also execute their core functionality outside the boundary of the account’s VPC. When these services require connectivity to VPC-internal resources, perhaps, they leverage a network mechanism same or similar to the Hyperplane ENI — a dedicated, cross-VPC network interface. I need to check the official documents to make sure.

Despite of ignoring these things, we can deploy services, but knowing them becomes invaluable during complex troubleshootings involving network connectivity. And then understanding the physical network topology is a significant asset in diagnosing difficult network-related problems. This post was written to assist your in that endeavor. Hope it proves beneficial.