Amazon VPC Lattice: modernize and simplify your enterprise network architectures

In this post, we explore how you can leverage Amazon VPC Lattice to build modern, secure and resilient enterprise networks on AWS. We dive deeper into how you can modernize network connectivity using the VPC Lattice integrations with all AWS compute services, and the support for a broad set of application and transport protocols. We also review how you can extend VPC Lattice connectivity to your on-premises environments, to meet your requirements for cross-Region and hybrid access.

Amazon VPC Lattice is a fully managed application networking service that helps you simplify network connectivity, security and monitoring for service-to-service communication needs. VPC Lattice now has built-in support for Amazon Elastic Container Service (Amazon ECS) and AWS Fargate, in addition to Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Lambda. It also has broad support for the most common types of services and protocols, such as HTTP and HTTPS, gRPC, TLS, and TCP. With support for VPC Resources, and service network VPC endpoints, VPC Lattice allows you to configure consistent and secure network connectivity for services on AWS and on-premises.

In addition to network connectivity, VPC Lattice facilitates an improved security posture with reliable authentication and context-specific authorization. It integrates with AWS Identity and Access Management (AWS IAM) for service-to-service authentication and authorization, providing the same familiar authentication and authorization capabilities you use today with AWS services. This allows you to implement a defense in depth security strategy, with rich traffic controls and end-to-end observability. You can choose to leverage VPC Lattice auth policies to granularly control access between your workloads, and accelerate zero trust security implementation efforts.

Prerequisites

We assume that you are familiar with networking constructs on AWS, including Amazon Virtual Private Cloud (Amazon VPC), AWS Direct Connect, AWS Site-to-site VPN, Amazon Route 53, AWS PrivateLink, and AWS Cloud WAN. We do not focus on defining these services, but we do outline their capabilities and how you can use them to complement VPC Lattice in the highlighted network connectivity scenarios. We also assume you are familiar with Amazon VPC Lattice concepts. For additional background on Amazon VPC Lattice, we recommend to review the previous post Build secure multi-account multi-VPC connectivity for your applications with Amazon VPC Lattice, and the collection of resources in the Amazon VPC Lattice Getting started guide.

Network connectivity scenarios

Enterprise networks provide the connectivity foundations for multiple traffic patterns, including cross-VPC connectivity within and across multiple AWS accounts and Regions, hybrid connectivity with on-premises environments, and connectivity to AWS managed services such as Amazon Relational Database Service (RDS).

We consider a multi-account and multi-VPC architecture pattern a best practice application deployment option, aligned with the AWS Well-Architected framework. Thus, we do not show account boundaries in the architecture diagrams, and assume all resources are deployed across multiple accounts. In the following sections, we dive into how you can use Amazon VPC Lattice to modernize and simplify enterprise network connectivity and security, while addressing the following application communication use cases:

Use case 1: Connectivity between applications within a single AWS Region

Use case 2: Connectivity between applications deployed in a hybrid environment, on AWS and on-premises. We distinguish two common flows for this use case:

• Clients on AWS need to access applications deployed on-premises
• Clients on-premises need to access applications on AWS

Use case 3: Connectivity from applications on the internet to applications deployed on AWS. We do not focus on user access to applications. For details on securing user access to applications, we recommend to review AWS Verified Access.

Use case 4: Connectivity between applications across multiple AWS Regions. This requirement stems from two common use cases for cross-Region connectivity:

• Clients across multiple Regions need to access applications deployed in a single Region
• Clients need cross-Region failover capabilities for accessing applications deployed across multiple Regions. Failover can be controlled by the service owner, or by the clients.

We consider clients, services and resources to be a combination of applications deployed on various AWS Compute options, with various supported protocols, such as HTTP, HTTPs, gRPC, TLS and TCP.

VPC Lattice features and new capabilities

VPC Lattice launched new features and capabilities that allow you to simplify connectivity and network security on AWS. You can now associate VPC Resources with your VPC Lattice service network, allowing you to provide access to TCP services and resources deployed on AWS or on-premises. You can also configure on-premises or cross-Region access to your service networks using service network VPC endpoints.

While you can find more details about each new feature in the previously mentioned posts, here is an overview of the constructs we use to design network connectivity for the scenarios outlined in the following sections:

1. Bring together applications that have common connectivity and security requirements using a VPC Lattice service network: The service network is a logical grouping mechanism that simplifies how you can enable connectivity across VPCs or accounts, and apply common security policies for application communication patterns. You can create a service network in an account and share it with other accounts within or outside of your AWS Organization using AWS Resource Access Manager (AWS RAM). You can have multiple service networks for various use cases, business units, or environments (e.g., production, development, staging, etc.).
2. Clients can access services and resources in a service network using service network VPC associations and service network VPC endpoints:
   • Service network VPC association (SN-A): Allows clients deployed in a VPC to access the service network. The service network association cannot be accessed from outside of the associated VPC. A VPC can have only one service network association.
   • Service network VPC endpoint (SN-E): Allows clients deployed in a VPC to access the service network. It also allows clients outside of the VPC to access the respective service network endpoint, if they have network connectivity to the VPC. For example, clients can access a service network VPC endpoint from a peered VPC, through AWS Cloud WAN or AWS Transit Gateway, or from on-premises through AWS Direct Connect or Site-to-Site VPN. A service network VPC endpoint uses IP addresses from the VPC CIDR blocks. You can configure connectivity to multiple service networks in a VPC by creating an SN-E for each service network. For details on the service network endpoints, we recommend to review the documentation.
3. In a service network, you can associate VPC Lattice services and VPC Resources:
   • VPC Lattice services: A VPC Lattice service consists of listeners (protocol and port number), routing rules that allow you to control application flows (for example, path, method, header-based, or weighted routing), and one or more target groups, which define your application infrastructure. A service can have multiple listeners to meet various client capabilities. Supported protocols include HTTP, HTTPs, gRPC and TLS. Once you create a VPC Lattice service, you can choose to share it with accounts within or outside of your AWS Organization, using AWS RAM. You can associate multiple services to a service network, and a service can be associated with multiple service networks.
   • VPC resources: A resource can be an IP address, a domain name (DNS) target, or Amazon managed resources, such as an Amazon RDS database. To make resources available to other VPCs and accounts, you can define a resource gateway and resource configurations:
     • A resource gateway is a new VPC construct that provides a point of traffic ingress into the resource owner VPC for accessing resources. You can have one or more resource gateways in a VPC.
     • A resource configuration represents a resource or a group of resources you want to share. You can associate multiple resource configurations with a single resource gateway in a VPC. Once you create a resource configuration, you can associate it with your service network. You can also share resource configurations with accounts within or outside of your AWS Organization using AWS RAM.

With VPC Lattice, clients, services and resources can have overlapping IP addresses, or support different IP versions (IPv4 and IPv6). This facilitates connectivity in environments where private IPv4 addresses are overlapping or scarce, and helps you accelerate your IPv6 adoption journey.

Use-case 1: Connectivity between applications in an AWS Region

The first use case we address is how to use VPC Lattice to provide secure connectivity between applications deployed across multiple VPCs and accounts in an AWS Region. Applications can be deployed across various compute platforms, including Amazon EC2 instances, AWS Lambda functions, Amazon ECS, Amazon EKS and AWS Fargate clusters, and can support a broad range of communication protocols. Figure 1 shows a high-level architecture diagram of application networking within an AWS Region:

Figure 1: High level architecture of application networking in an AWS Region

To simplify and modernize your enterprise network connectivity architecture within an AWS Region, you can:

• Create one or more VPC Lattice service networks, depending on your segmentation model.
• Create VPC Lattice services and VPC Resources, based on your application requirements
• Associate VPCs, services and resources to their respective service networks.
• Optionally, configure authentication and authorization policies on your service networks and services, to granularly control application communication.

You can create client-specific service networks or service-specific service networks. For example, you can group clients by business unit (BU), and configure a service network per BU. Alternatively, you can group services by their function, such as shared services, and associate them with a dedicated service network. Application teams can create VPC Lattice services and resources, and share them with the accounts that own service networks. You can associate services and resources with multiple service networks, to meet specific access requirements. Regardless of your segmentation and operational model, you can automate the association of VPCs, services and resources to your service networks using tags. For details on automation best practices, we recommend reviewing Automating large scale deployments with tags for Amazon VPC Lattice.

To facilitate service discovery, VPC Lattice supports custom domain names for your services and resources, and maintains a Fully Qualified Domain Name (FQDN) for each VPC Lattice service and resource you define. You can leverage these FQDNs in your Route 53 private hosted zone configurations, and allow clients to discover and access services and resources. We recommend reviewing how you can Unify DNS management using Amazon Route 53 Profiles with multiple VPCs and AWS accounts.

Figure 2 shows a common enterprise architecture example. We created three service networks specific to production, development and shared services environments, named Prod, Dev, and Shared services. We associated:

• Production VPCs, services and resources to the Prod service network.
• Development VPCs, services, and VPC Resources to the Dev service network.
• Shared services and shared VPC resources, together with their VPCs to the Shared Services service network.
• Shared services and shared VPC resources to both Prod and Dev service networks, as they need to be accessed by both production and development applications

Figure 2: A common enterprise architecture with Production, Development and Shared services application networking in an AWS Region

Use-case 2: Connectivity between services deployed in a hybrid environment, deployed on AWS and on-premises

For hybrid connectivity use-cases, clients and applications can be deployed on AWS as well as on-premises. We address two common access patterns:

1. Clients deployed on AWS requiring access to applications deployed on-premises
2. Clients deployed on-premises requiring access to applications deployed on AWS

Let’s review how you can leverage VPC Lattice service network VPC endpoints (powered by AWS PrivateLink) and VPC Resources to meet the requirements for both use cases.

1. Access from on-premises to applications deployed on AWS: For clients deployed on-premises (or outside of AWS), you can create an entry point VPC that can be accessed from on-premises, using AWS Direct Connect or Site-to-site VPN. In this VPC, you can create service network VPC endpoints for your service networks, and allow clients on-premises to access the associated VPC Lattice services and resources. You can also filter traffic from on-premises using security groups on the service network endpoints. For hybrid connectivity, you can use AWS Direct Connect or AWS Site-to-Site VPN. Figure 3 shows a high-level architecture diagram of an Amazon VPC Lattice service network VPC endpoint.

Figure 3: Amazon VPC Lattice service network VPC endpoint access from on-premises

Figure 4 shows a common enterprise architecture example. We use the VPC “Hybrid ingress VPC” to allow access from on-premises to all service networks in a Region. We configured a service network endpoint for each of the service networks (Prod, Dev and Shared Services). We used AWS Direct Connect for on-premises connectivity for the Hybrid ingress VPC.

Figure 4: Hybrid ingress VPC with service network endpoints for access from on-premises to Prod, Dev and Shared Services service networks

2. Access from AWS to applications deployed on-premises: For applications deployed on-premises (or outside of AWS), you can create an exit point VPC that has connectivity to on-premises, using AWS Direct Connect or Site-to-site VPN. In this VPC you can create a resource gateway, and define resource configurations for on-premises applications. You can identify resources using DNS or IP addresses, and associate the resource configurations with your service network.

For on-premises applications that require load balancing, you can use Network Load Balancers (NLBs) on AWS, in the egress VPC. To configure access to the NLBs representing your on-premises services from your service networks, you can define resource configurations containing the DNS FQDN of each NLB. You can associate each resource configuration with one or more service networks, and provide access to on-premises load balanced services. Figure 5 shows a high level architecture diagram for resource configurations to on-premises applications.

Figure 5: Hybrid ingress VPC with service network endpoints for access from on-premises to Prod, Dev and Shared Services service networks

Figure 6 shows a common enterprise architecture example. We use the VPC “Hybrid egress VPC” with access to on-premises services and resources through AWS Direct Connect. We configured a resource gateway, and defined IP or DNS-based resource configurations representing the on-premises resources that do not require load balancing. For on-premises applications that require load balancing, we configured Network Load Balancers (NLBs), and added each of their FQDNs to a resource configuration. We chose to associate all resource configurations with all three service networks (Prod, Dev and Shared Services). However, you can choose to associate resource configurations with a subset of service networks, or create a service network dedicated for applications deployed on-premises.

Figure 6: Hybrid egress VPC with resource gateway and resource configurations for on-premises applications

Use-case 3: Connectivity from internet-based applications to services deployed on AWS

For internet-inbound communication needs, applications on the internet are required to access applications deployed on AWS. This use case is commonly addressed by configuring public-facing load balancers to frontend the applications deployed on AWS. In this scenario, we explore how you can use VPC Lattice to provide secure connectivity from the public load balancer to the backend targets. To achieve this, we can create an ingress point VPC, where we deploy the public-facing load balancers, and use service network VPC endpoints as the load balancer targets. If you use Application Load Balancers, targets must be HTTP. Figure 7 shows a high-level architecture diagram for internet ingress into VPC Lattice.

Figure 7: Internet ingress access through VPC Lattice

Figure 8 shows a common enterprise example architecture. We configured an internet ingress VPC and a dedicated VPC Lattice service network for VPC Lattice services and resources that require access from internet clients. We use both Application and Network Load Balancers with targets the service network IP addresses. You can also choose to provide internet connectivity directly to your service networks, based on your security and operational model.

Figure 8: Internet-facing application access through VPC Lattice using Application or Network Load Balancers and service network endpoint for Prod, Dev and Shared Services applications

Use-case 4: Connectivity between applications across multiple AWS Regions

Regardless of your use cases for running multi-region applications, a foundational requirement is to ensure that clients can securely access services and resources, without affecting resiliency and availability. We address two common cross-Region access patterns for applications:

1. Clients across multiple Regions need to access services deployed in an AWS Region.
2. Clients require cross-Region failover capabilities when accessing critical services deployed across multiple AWS Regions.

Let’s review how you can use VPC Lattice to meet the requirements of both access patterns:

1. Clients across multiple Regions need to access services deployed in an AWS Region: For this use case, you can leverage service network VPC endpoint, and cross-Region IP connectivity using VPC peering, or AWS Cloud WAN. Alternatively, you can use VPC Lattice together with interface VPC endpoints (powered by AWS PrivateLink) that allow cross-Region connectivity, to abstract service location, IP addressing, and failover decisions from clients. Here we focus on the second option. To achieve this:

• Create cross-Region PrivateLink interface VPC endpoints for the services that require cross-Region client access. This allows you to better track and manage cross-Region communication dependencies, and ensure they do not affect resiliency and availability.
• Bring the cross-Region PrivateLink interface VPC endpoints into your VPC Lattice service network as VPC resources. Each cross-Region endpoint represents a service. You can define a VPC Resource for each endpoint using its PrivateLink managed FQDN, and manage custom DNS using Route 53 private hosted zones and Profiles.

Figure 9 shows a high-level architecture example.

Figure-9: Cross-Region service access using VPC Lattice service network VPC endpoint and AWS PrivateLink

To access a service network in a remote Region, you can configure a service network VPC endpoint and frontend it with a Network Load Balancer. Then, you can create a PrivateLink endpoint service, and PrivateLink endpoints in the remote Regions. To bring the cross-Region VPC endpoints into the service network, you can define resource configurations or VPC Lattice services. AWS PrivateLink and Amazon VPC Lattice both abstract client and service IP addresses and IP versions, thus all our VPCs can have overlapping IP space.

2. Clients require cross-Region failover capabilities when accessing critical services: For services deployed across multiple Regions, a common use case for cross-Region connectivity is the ability to receive client traffic in a remote Region during failover conditions. With VPC Lattice, service owners can:

• Configure VPC Lattice service with two target groups. One target group represents the application in the local Region, and the second target group contains the AWS PrivateLink IP addresses for cross-Region connectivity to the remote Region service network.
• When a service is required to failover to a different Region, the service owner can modify the weights on the target groups. This allows client traffic to flow from clients through VPC Lattice, to the cross-Region PrivateLink endpoint.

Figure 10 shows high-level architecture example. In this scenario, failover is controlled by the service owner.

Figure 10: Cross-Region active-passive service access configuration

This option removes the need to configure direct IPv4 and IPv6 connectivity between multiple Regions, and allows you to granularly control cross-Region dependencies. VPC Lattice provides you with full visibility into service access patterns, helping you simplify monitoring, service dependency mapping efforts, and failover controls.

Conclusion

In this post, we explored how you can leverage Amazon VPC Lattice to build modern, secure and resilient enterprise networks on AWS. We reviewed how you can modernize network connectivity using the VPC Lattice integrations with all AWS Compute services, and the support for a broad set of application and transport protocols. We also reviewed how you can extend VPC Lattice connectivity to your on-premises environments, to meet your requirements for cross-Region and hybrid service access. For more information about Amazon VPC Lattice, you can refer to the documentation and the Amazon VPC Lattice Getting started guide.

About the authors