Dive Deep to AWS App Runner VPC Networking

This article is a translation of Deep Dive on AWS App Runner VPC Networking.

Introduced in 2021, his AWS App Runner is a fully managed service for running web applications and API servers. App Runner greatly simplifies the steps to build and run a secure web server application with little (or no) use of your AWS account infrastructure. It builds and deploys application containers on the AWS cloud using your source code and container images, and automatically scales and load balances requests between containers in the background. Customers are only aware of the URL of the service that receives the HTTPS request.

AWS recently announced his VPC support for the App Runner service. Previously, applications hosted on App Runner could only connect to public endpoints on the Internet. With this new feature, your application can now connect to private resources in your VPC, such as Amazon RDS databases, Amazon ElastiCache clusters, or other private services hosted in your VPC. This article introduces the background of App Runner and is expected to run over network connections between apps hosted in App Runner and his VPC, especially network interfaces created in his VPC and above. Learn more about traffic flows.

Before we dive into the details of VPC access, let's first review the internal behavior of App Runner in the default public network mode that existed before this new feature was launched.

Public networking mode

When you create a service in App Runner, the following things happen in the background: Deploy your application container to an App Runner-owned VPC as an AWS Fargate task orchestrated by Amazon Elastic Container Service. Within the App Runner-owned VPC, you have a Network Load Balancer (NLB) for the Internet that receives requests and a Layer 7 request router that forwards the request to the appropriate Fargate task. The Fargate task itself is hosted in Firecracker microVMs running in a Fargate-owned VPC. The Fargate task is launched in awsvpc network mode and interconnects with the App Runner VPC. That is, each Fargate task is attached to the Elastic Network Interface (ENI) of the App Runner VPC. This is called the Fargate task's Primary ENI. The request router has private access to each Fargate task through its Primary ENI's private IP address. In fact, the ENI is bidirectional, so all network traffic with the Fargate task goes through the Primary ENI. This traffic flow is divided into four categories.

As you can see, in public networking mode, all traffic flows are fully background supported through the App Runner VPC. You don't need to provision his VPC or networking resources in your AWS account to deploy an application that doesn't require VPC access and only requires outbound internet access.

Figure 1: Public networking mode architecture

However, many applications operate in an ecosystem of private resources and require your access to her VPC. The following sections describe how to achieve this functionality with your existing architecture.

Introducing VPC networking mode

To deploy an application with outbound access to your VPC on App Runner, you must first create a VPC Connector with one or more subnets and security groups to associate with your application. You can reference the VPC Connector in Create / UpdateService using the CLI as follows:

 cat > vpc-connector.json << EOF{"VpcConnectorName": "my-vpc-connector","Subnets": [ "subnet-a", "subnet-b", "subnet-c"],"SecurityGroups": [ "sg-1", "sg-2"]}EOFaws apprunner create-vpc-connector \--cli-input-json file:///vpc-connector.jsoncat > service.json

The Availability Zones mapped to the VPC Connector subnet are evenly distributed with background-launched Fargate tasks. To ensure high availability, we recommend that you choose a subnet that spans at least three Availability Zones (all supported Availability Zones if your region offers three or less Availability Zones).

When it comes to security groups, it's important to note that the VPC Connector is only used for outbound communication from your application (I'll explain why in more detail later). Therefore, security group inbound rules are not used and are effectively ignored. The important thing is the outbound rule, which needs to allow communication to the destination endpoint. You also need to make sure that the security group associated with the destination resource has the appropriate inbound rules to allow traffic from the VPC Connector security group, as shown in Figure 2.

Figure 2: VPC Connector Settings

Detailed explanation of VPC networking mode

Now let's Dive Deep how the connection between your VPC and the application container running inside her Fargate-owned VPC is established. The technology used in VPC networking mode is AWS Hyperplane. AWS Hyperplane is an internal service that has supported many of the network services provided by AWS. In particular, it supports his VPC-to-VPC connections for AWS Private Link and AWS Lambda VPC networking, and is perfectly suited for the use case of establishing a connection between a VPC hosting an application task and a Fargate VPC. We'll talk more about why we chose Hyperplane in the next section, but let's start by understanding the architecture of VPC networking mode.

When you create a VPC Connector and associate it with a service, a special type of ENI called Hyperplane ENI is created in your subnet. Similarly, his Hyperplane ENI is present in the Fargate subnet that hosts the Fargate task's microVM. When the Fargate task is launched, a tunnel is established between the two Hyperplane ENIs and a connection is created between the VPCs.

A Hyperplane ENI created within a VPC is very similar to his regular ENI in that it is assigned a private IP address from his CIDR range of subnets. However, there are some important differences to note. Hyperplane ENI is a managed network resource whose life cycle is controlled by App Runner. You can view the ENI and access its flow logs, but you cannot detach or delete the ENI. Another feature of Hyperplane ENI is that communication is unidirectional. Only supports outbound traffic originating from the application. Therefore, you cannot send inbound requests to the Hyperplane ENI's IP address. Incoming requests to the application are sent via the service URL, as in public networking mode. Let's also check the traffic flow in VPC networking mode.

Figure 3: VPC Networking Mode Architecture

Benefits of AWS Hyperplane for VPC Networking Mode

Now that we've talked about Hyperplane ENI, why did you decide to use Hyperplane instead of regular ENI to establish a connection to your VPC? Hyperplane provides high throughput and low latency network virtualization capabilities. Hyperplane ENI provides a higher degree of sharing compared to a regular ENI created for each Fargate task. Hyperplane ENI is associated with a subnet and one or more combinations of security groups. Fargate tasks that share the same combination can send traffic through the same Hyperplane ENI. In this example, the security group specified in the VPC Connector applies to all Fargate tasks that belong to the App Runner service. Since there can be multiple subnets in a VPC Connector, a Hyperplane ENI is created for each subnet. Fargate tasks are evenly distributed across these subnets, and all Fargate tasks within a given subnet can send traffic through the shared Hyperplane ENI.

The previous figure (Figure 3) is a simplified representation of only one Fargate task per subnet and the Hyperplane ENI. However, the benefits of Hyperplane are best seen when the service scales, as shown in Figure 4. In App Runner VPC, there is a one-to-one relationship between the Fargate task and its Primary ENI (which is a regular ENI, not Hyperplane ENI), but in Customer VPC there is only one Hyperplane ENI per subnet. All Fargate tasks in that Availability Zone send traffic through the same shared ENI in your VPC.

Figure 4: Scale of service in VPC networking mode

This architecture has several advantages for our customers.

summary

We are pleased to leverage the power and scalability of AWS Hyperplane to deliver this ability for App Runner applications to connect to private resources in your VPC. This feature is one of the most requested App Runner. We look forward to your feedback. Comment on the App Runner roadmap on GitHub. Be sure to check out the blog that describes setting up a web application that uses this feature to connect to a private RDS database.

The author of this article, Archana Srikanta, is a serverless / container principal engineer and primary architect for AWS Fargate and App Runner. Please follow her on her Twitter. @ArchanaSrikanta

The translation was done by Solutions Architect Kaji. The original text is here.