Yesterday, the team at Amazon announced improved VPC (Virtual Private Cloud) networking for AWS Lambda functions. It is a major improvement on how AWS Lambda function will work with Amazon VPC networks.
In case a Lambda function is not configured to connect to your VPCs then the function can access anything available on the public internet including other AWS services, HTTPS endpoints for APIs, or endpoints and services outside AWS. So, the function has no way to connect to your private resources that are inside your VPC.
When the Lambda function is configured to connect to your own VPC, it creates an elastic network interface within the VPC and does a cross-account attachment.
Image Source: Amazon
These Lambda functions run inside the Lambda service’s VPC but they can only access resources over the network with the help of your VPC. But in this case, the user still won’t have direct network access to the execution environment where the functions run.
What has changed in the new model?
AWS Hyperplane for providing NAT (Network Address Translation) capabilities
The team is using AWS Hyperplane, the Network Function Virtualization platform that is used for Network Load Balancer and NAT Gateway. It also has supported inter-VPC connectivity for AWS PrivateLink. With the help of Hyperplane the team will provide NAT capabilities from the Lambda VPC to customer VPCs.
Network interfaces within VPC are mapped to the Hyperplane ENI
The Hyperplane ENI (Elastic Network Interfaces), a network resource controlled by the Lambda service, allows multiple execution environments to securely access resources within the VPCs in your account. So, in the previous model, the network interfaces in your VPC were directly mapped to Lambda execution environments. But in this case, the network interfaces within your VPC are mapped to the Hyperplane ENI.
Image Source: Amazon
How is Hyperplane useful?
To reduce latency
When a function is invoked, the execution environment now uses the pre-created network interface and establishes a network tunnel to it which reduces the latency.
To reuse network interface cross functions
Each of the unique security group:subnet combination across functions in your account needs a distinct network interface. If such a combination is shared across multiple functions in your account, it is now possible to reuse the same network interface across functions.
What remains unchanged?
- AWS Lambda functions will still need the IAM permissions for creating and deleting network interfaces in your VPC.
- Users can still control the subnet and security group configurations of the network interfaces.
- Users still need to use a NAT device(for example VPC NAT Gateway) for giving a function internet access or for using VPC endpoints to connect to services outside of their VPC.
- The types of resources that your functions can access within the VPCs still remain the same.
The official post reads, “These changes in how we connect with your VPCs improve the performance and scale for your Lambda functions. They enable you to harness the full power of serverless architectures.”
To know more about this news, check out the official post.
What’s new in cloud & networking this week?