Networking & Content Delivery

Enabling end-to-end encryption with Amazon VPC Lattice TLS Passthrough

Introduction

In this post, we discuss VPC Lattice Transport Layer Security (TLS) Passthrough feature. We walk through how users designed workloads prior to this feature, what this feature provides, and best practices for implementing TLS passthrough communication using VPC Lattice.

AWS announced the general availability of TLS Passthrough for VPC Lattice, which allows users to enable end-to-end authentication and encryption using their existing TLS and/or mutual TLS (mTLS) implementations. With this launch, you can configure a TLS listener, which routes traffic based on the server name indicator (SNI) field of a TLS and/or mTLS connection. This allows you to perform end-to-end authentication and encryption between your services without terminating TLS in VPC Lattice.

Amazon VPC Lattice streamlines service-to-service connectivity, providing users with a consistent method for connecting, securing and observing traffic between services, and making it easier to implement microservice architectures. Many users need end-to-end encryption at the application layer. With VPC Lattice, a common pattern is to use HTTPS listeners for VPC Lattice services. These use TLS to terminate HTTPS connections directly on VPC Lattice. This approach simplifies credential management, handling certificate distribution, rotation, and revocation, while enabling a complete and fully managed authorization engine, making it an effective solution for most use cases. However, for users who prefer to manage end-to-end encryption themselves, VPC Lattice offers TLS listeners, allowing TLS termination only on the destination service.

Prerequisites

For this post, we assume you are familiar with AWS Networking and infrastructure concepts, including Amazon Virtual Private Clouds (VPCs), subnets and Availability Zones (AZs), and as well as fundamental concepts with VPC Lattice, including services, service networks, and auth policies. We also assume you are familiar with deploying services and applications using Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing and Amazon Elastic Container Service (Amazon ECS)

Before VPC Lattice TLS Listeners

For HTTP and HTTPS listeners, VPC Lattice terminates TLS sessions, and performs request-level routing and load balancing based on information in HTTP headers. Therefore, client to services communication that require end-to-end encryption needed the use of alternative connectivity solutions like AWS Transit Gateway and self-managed solutions such as Envoy or NGINX.

With VPC Lattice TLS Listeners

With support for TLS listeners for VPC Lattice services, this type of end-to-end encrypted communication flows are possible using VPC Lattice. VPC Lattice TLS Passthrough provides automatic connectivity and SNI header-based routing to TLS and/or mTLS enabled services, without needing to decrypt traffic as it passes through VPC Lattice. This allows you to enable TLS-enabled communication between clients and services without terminating TLS in VPC Lattice.

When you configure a TLS listener for a VPC Lattice service, VPC Lattice does not terminate TLS. Instead, it routes requests directly to service targets to terminate TLS. VPC Lattice TLS listeners route requests based on the SNI field located in the TLS client-hello message. This allows you to enable connectivity for resources that are using TLS for encryption and/or authentication.

Baseline architecture

In this post, we consider an initial application architecture as shown in Figure 1. We consider two VPCs: one for the consumer (Consumer VPC) and another one for the provider resources (Provider VPC). HTTPS services are exposed at the Provider VPC by a Network Load Balancer and will, eventually, be consumed by resources at the Consumer VPC. Additionally, we implement mTLS between the clients and the service. We use Transit Gateway to achieve Internet Protocol (IP) reachability between the two VPCs. The following figure shows the described architecture:

Figure 1: End-to-end encrypted service with Transit Gateway

Figure 1: End-to-end encrypted service with Transit Gateway

  1. Transit Gateway setup: A Transit Gateway is provisioned to enable secure connectivity between the Consumer VPC and the Service VPC.
  2. Amazon VPC attachments: The Consumer VPC needs access to the backend HTTPS endpoint and the Service VPC is attached to the Transit Gateway.
  3. Routing: Appropriate routing tables are configured to route traffic from the Consumer VPC to the backend HTTPS endpoint through the Transit Gateway.
  4. Services: The backend services, such as the backend HTTPS endpoint, reside in the Service VPC and operates in an Amazon Elastic Container Service (Amazon ECS) cluster behind an AWS Network Load Balancer (NLB). Within this cluster, there is an ECS task with a sidecar proxy (such as Envoy or NGINX) running with the application container. This proxy is the front proxy that terminates TLS and sends traffic, unencrypted, to the application container over localhost.
  5. End-to-End Encryption: In this setup, the TLS session initiated by the consumer VPCs will pass through the Transit Gateway, untouched, and be terminated at the backend HTTPS endpoint, ensuring end-to-end encryption.

In the following section, we show how we can use VPC Lattice to simplify this architecture.

Solution overview: VPC Lattice TLS Listeners

We implement VPC Lattice TLS listeners, then migrate client to service traffic from Transit Gateway to VPC Lattice, as shown in Figure 2.

Figure 2: End-to-end encrypted service with VPC Lattice

Figure 2: End-to-end encrypted service with VPC Lattice

Process flow:

  1. The consumer application queries the Amazon Route 53 VPC resolver for DNS resolution of the service it wants to reach out.
  2. The DNS record points to a Lattice IP address (link-local address), so the TLS traffic is forwarded to the Lattice service.
  3. VPC Lattice service has a TLS listener configured and passes encrypted traffic to the target without decrypting it.

To configure VPC Lattice for TLS Passthrough, the following steps are required:

VPC Lattice Target group configuration

For simplicity, we include a shortened version of the VPC Lattice configuration steps. The full detail can be found at the VPC Lattice documentation.

  1. At the VPC console, go to the PrivateLink and Lattice section, Target Groups, and click on Create target group button.
  2. At the Specify group details screen, select the target type, choose a Target group name, and at the Protocol selection drop-down, select TCP and port (443, for instance).
  3. If the selected Target type is Instances, IP Addresses or Application Load Balancer, select the VPC containing the resources.
  4. Select the Protocol version between HTTP1, HTTP2 or gRPC
  5. Register Targets as indicated and click on Create target group button.

VPC Lattice Service configuration

  1. At the VPC console, go to the PrivateLink and Lattice section, Lattice Services, and click on Create service button.
  2. Specify a service name, and select the custom domain option, as TLS passthrough requires this feature.
  3. Optionally, select an SSL/TLS certificate
  4. In Service access, select an Auth type, between None and AWS IAM.
  5. Optionally, complete the “Auth policy”, “enable access logs” and “Share service” sections.
  6. At the Define routing screen, click on Add listener button.
  7. At the protocol selection screen, select TLS (TLS passthrough) and the port, for example, 443.
  8. At the Listener default action screen, select the previously created Target group and, optionally, select additional target groups and their respective weights.
  9. At the Service network associations screen, select the VPC Lattice service network
  10. Click Next, review all the information and click Create VPC Lattice service button.

Use cases of VPC Lattice TLS listeners

Let’s detail some of the common use cases for VPC Lattice TLS Listeners:

Use case 1: End-to-End Encryption for Client/Server Web Applications

Consider a web application hosted on an Amazon Elastic Compute Cloud (Amazon EC2) instance, as shown in Figure 3. With VPC Lattice TLS Passthrough, you can allow end-to-end encryption between the client and the server.

Note that the Consumer and the Service VPCs are not reachable between them, as no Transit Gateway or VPC peering configurations are in place. They could even have overlapping IP ranges.

With this setup, the TLS session is terminated directly at the server side, in this case, the Amazon EC2 instance, ensuring end-to-end encryption:

  1. We create a VPC Lattice service with a target group containing the EC2 instance.
  2. We enable TLS passthrough, allowing the TLS session to be terminated directly on the EC2 instance.
  1. The client at the Consumer VPC establishes a connection to the Service VPC, while maintaining end-to-end encryption between them.

Figure 3: End-to-end encryption for client/server web applications

Figure 3: End-to-end encryption for client/server web applications

To deploy this use case, follow this GitHub link for the steps in AWS samples.

Use case 2: mTLS

mTLS authentication is an optional component of TLS that offers two-way peer authentication. mTLS authentication adds a layer of security over TLS and allows your services to verify the client that’s making the connection. The client in the client-server relationship also provides an X.509 certificate during the session negotiation process. The server uses this certificate to identify and authenticate the client. This process helps to verify if the certificate is issued by a trusted certificate authority (CA) and if the certificate is a valid certificate. It also uses the Subject Alternative Name (SAN) on the certificate to identify the client. Note: In this process, it’s important to remember that customers need to manage the certificates themselves, not Lattice.

VPC Lattice TLS passthrough allows you to implement mTLS between clients and services in your network. With TLS Passthrough, the mTLS session is terminated on the backend compute resources, which allows for secure communication between heterogeneous environments, as shown in Figure 4.

  1. We create VPC Lattice services with target groups containing the EC2 instances and Amazon ECS containers. You can find details on the built-in Amazon ECS integration with VPC Lattice in the blog post Build secure application networks with VPC Lattice, Amazon ECS, and AWS Lambda.
  2. We configure TLS listeners for the two services, allowing mTLS sessions to be terminated on the respective compute resources.
  3. VPC Lattice facilitates secure communication between the client instances and services.

Figure 4: mTLS

Figure 4: mTLS

Considerations

TLS sessions are transparently forwarded with Lattice TLS Passthrough, and no certificates are handled or verified by the service. To manage certificates, users should use their existing certificate management implementation, such as AWS Certificate Manager (ACM) Private Certificate Authority (PCA) to manage their certificate distribution and lifecycle.

Refer to the VPC Lattice pricing page for detailed information on pricing and pricing-related examples.

Considerations apply also to TLS listeners, such as the need for custom domain names. For more details, refer to this VPC Lattice considerations page.

Conclusion

In this post, we showed how you can use Amazon VPC Lattice TLS Passthrough to simplify service connectivity and allow for end-to-end TLS encryption. We walked through how TLS works in VPC Lattice, and two use cases of this new feature. To learn more about VPC Lattice and the TLS passthrough feature, visit the VPC Lattice documentation page and TLS Passthrough documentation.

About the authors 

Daniel Neri

Daniel is a Telecommunications Engineer and currently serves as a Senior Solutions Architect at AWS. He specializes in helping customers design secure, scalable, and cost-efficient cloud architectures using AWS technologies. When he’s not architecting solutions, you can find him enjoying his favorite sports or exploring new ways to stay active and energized.

 

  

Victor Solaz

Victor is a Senior Solutions Architect at AWS. Prior to joining AWS, Victor worked at different roles at Cisco; becoming a Networking expert and double-CCIE certified. In his free time, he loves traveling, hiking and staying with family.