AWS Lambda VPC Upgrades with HyperPlane
Walkthrough: Configuring a Lambda Function to Access RDS in a VPC
Chris Munns, AWS Principal Developer Advocate — Serverless, announced this week major changes to how AWS Lambda functions work with Amazon VPC networks.
Like, really big. As in, I’m predicting this will be an inflection point for serverless adoption amongst enterprises who are VPC-heavy.
The traditional thinking with AWS Lambda and Virtual Private Clouds (VPC) has been to avoid mixing the two.
Oil and water.
Amazon VPC lets you provision a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define.
For companies or organizations migrating from private data centers or still running hybrid infrastructure, VPC seems like a no-brainer. It looks, smells, and tastes like the isolated traditional server environment with barbed wire on top that IT is accustomed to. After all, it authorizes traffic inbound and outbound from your instances, prevents major bummers like brute force login attacks, and provides a safe space to launch your instances.
Since 2013, it’s been the default configuration for nearly everyone launching an EC2 instance, and for good reason.
That is, until Lambda entered the picture.
At re:Invent in 2014, AWS CTO Werner Vogels introduced Lambda as a way to focus on building event-driven applications while managing and scaling infrastructure is handled by the cloud provider. While initially popular with developers due to its low cost and deployment speed, it’s gaining traction with other roles within enterprises. According to F5’s State of Application Services Report, 29 percent of cloud architects, 24 percent of DevOps, and even 24 percent of executives view serverless as a strategic focus in 2019.
However, running a Lambda function inside of a VPC previously required creating an Elastic Network Interface (ENI) and attaching it to the Lambda. This process added considerable latency to functions and increased cold starts. In addition, it limited Lambda scalability by counting against your network interface account limit per region.
The current model looks like this:
With the recent announcement, AWS is rolling out AWS HyperPlane, the Network Function Virtualization platform used for Network Load Balancer and NAT Gateway, to provide NAT capabilities from the Lambda VPC to customer VPCs.
From the announcement:
The Hyperplane ENI is a managed network resource that the Lambda service controls, allowing multiple execution environments to securely access resources inside of VPCs in your account. Instead of the previous solution of mapping network interfaces in your VPC directly to Lambda execution environments, network interfaces in your VPC are mapped to the Hyperplane ENI and the functions connect using it.
While Hyperplane still uses a cross account network interface, it provides the following benefits for Lambda within a VPC:
- Reduced latency when a function is invoked by using pre-created network interfaces. The network interface is created when the Lambda function is initially created.
- Network interfaces are shared across functions with the same security group:subnet combination
- Function scaling is no longer bound to the number of network interfaces
Developers don’t need to enable this new capability and AWS is gradually rolling this out across all AWS regions over the next couple of months.
While the new changes make it more conducive for developers to connect Lambda functions to VPCs, the basic architecture doesn’t change in terms of your VPC.
From Chris Munns:
- Your Lambda functions still need the IAM permissions required to create and delete network interfaces in your VPC.
- You still control the subnet and security group configurations of these network interfaces. You can continue to apply normal network security controls and follow best practices on VPC configuration.
- You still have to use a NAT device(for example VPC NAT Gateway) to give a function internet access or use VPC endpoints to connect to services outside of your VPC.
- Nothing changes about the types of resources that your functions can access inside of your VPCs.
With this in mind, if you’re looking to configure a Lambda function to access RDS, we’ve compiled a simple walk-through.
Configuring a Lambda function to access RDS
If you have a database tucked away in a private VPC it can be tricky setting up a Lambda function to connect to it. In this example, we’ll walk through the steps required to get your function talking to RDS without tearing your hair out. Note that this setup is in a private VPC and is not requiring any outside internet connectivity. If you require this, you’ll need to go through further steps, including adding a NAT gateway on a public subnet.
- To start, we’ll need to first attach the
AWSLambdaVPCAccessExecutionRole policy to your functions IAM role. I’ve created a role and have attached this policy to it
2. Next up is adding your function to the VPC and configuring the rest of the network setup.
3. You’ll attach the subnets within the VPC to the function and then select a security group. We already created this security group to only allow outbound connections to my serverless Postgres database.
4. The “Destination” here is the security group that is on the database.
Then, within the security group assigned to the database, we’ll enable access for the security group assigned to our lambda function.
That should be all we need to allow connections to the database so we can start coding our function. We’re going to use a simple example in Node to get the current time back from the database to make sure our connection is working.
5. If we check the output, we can see that the query did indeed return from the database with the current timestamp.
2019–07–29T16:39:40.132Z b4560641–0dd3–4072-b4ab-14cd97d9feae INFO The current time is: Mon Jul 29 2019 16:39:39 GMT+0000 (Coordinated Universal Time)
That’s it.
If you’re currently utilizing Lambda functions with your VPC, sign up for IOpipe’s real-time monitoring to observe application performance changes with Hyperplane.
With no-code install options, function profiling, alerts, tracing, and custom metrics are available on our free-forever tier.
About IOpipe
As the leader in serverless dev tooling for monitoring and observability, IOpipe offers real-time visibility into the most granular behaviors of today’s serverless applications on AWS Lambda.
Founded in 2016 by Erica Windisch and Adam Johnson, IOpipe reduces debugging time from hours to seconds, delivers transparent insights into the behaviors and performance of your serverless functions, and reduces risk for enterprises shifting to serverless.
Working with global brands like Matson, Rackspace, and APM Music, IOpipe empowers engineering teams to deliver with confidence, debug intelligently, and get busy building the impossible.
In other words, IOpipe makes it a lot more fun to be a developer. Visit www.iopipe.com to learn more and try it for free.
