Streamline and secure access to shared services and resources with Amazon VPC Lattice

In this post, we explore how you can use Amazon VPC Lattice to expose shared services and resources across an organization while maintaining security and governance. We cover key architecture concepts, security best practices, and considerations for deploying VPC Lattice in production environments.

As organizations grow, managing access to shared services across multiple environments—such as production, development, and staging—becomes increasingly complex. Traditionally, service-to-service communication relies on IP-based networking, often constrained by overlapping IP addresses, routing complexities, and security enforcement at the network layer.

VPC Lattice streamlines service connectivity by abstracting IP address dependencies, allowing applications to communicate securely without needing direct network routing. Furthermore, it provides fine-grained access control through Auth policies, enabling security teams to enforce consistent access controls across multiple environments. Auth policies are applicable to both authenticated and unauthenticated traffic to VPC Lattice services.

Prerequisites

To follow along with this post, you should have the following:

• A basic understanding of Amazon Virtual Private Network (Amazon VPC) networking concepts.
• Familiarity with VPC Lattice and its key features such as differences between exposing services and resources.
• The right AWS Identity and Access Management (IAM) permissions to create and manage VPC Lattice services, resources and policies.
• A setup with at least two VPCs (for example production, development, or staging) to demonstrate cross-VPC service access.

Architecture overview

The following architecture depicts a high-level design showing VPC Lattice used for exposing different types of applications: HTTP-based, generic TCP, and an Amazon Web Service (AWS) service exposed through an AWS PrivateLink interface endpoint. You can extend this setup to other AWS PrivateLink endpoints for shared services and custom services in your organization, including Software as a Service (SaaS) endpoints.

Figure 1: VPC Lattice for shared services—high level architecture

Key components

1. Shared services: A set of centralized applications either self-managed (for example authentication, logging, or monitoring) or AWS services (for example AWS Secrets Manager, Amazon CloudWatch, etc.). User-owned HTTP-based applications are mapped to VPC Lattice services, while TCP applications, or AWS PrivateLink endpoints for AWS managed and custom services are mapped to resources.
2. Client VPCs: Multiple VPCs representing different routing domains (for example production, development, and staging) that need access to the shared services. Client VPCs can access shared services by connecting to the service network through a service network association or service network endpoint.
3. VPC Lattice: VPC Lattice abstracts IP addresses and allows seamless service connectivity while enforcing least privilege access security policies. For services, VPC Lattice supports Auth policies to add an extra layer of access control.

How it works

• You register the shared services and resources with VPC Lattice, making them accessible through VPC Lattice service and resource names.
• Clients from different VPCs use VPC Lattice to connect to shared services, without needing direct peering, AWS Transit Gateway or AWS Cloud WAN configurations.
• Traffic is routed through VPC Lattice, ensuring isolation and compliance with security policies.

Traffic flows

This section shows the traffic flows for accessing these shared services and resources using a service network VPC association and a service network endpoint. The service network VPC association allows clients within the directly associated VPC to access the shared services and resources. However, a single VPC can have only one service network association (SNA). Conversely, service network endpoints (SNEs) allow for more flexibility. Clients can access shared services through a service network endpoint, which allows the same VPC to connect to multiple service networks. This also allows service network access from remote VPCs, across AWS Regions, or from on-premises networks.

Clients accessing a shared HTTP/HTTPS service

Option 1: Using a service network VPC association (SNA)

The following diagram shows the request flow when a client connects to an HTTP/S application exposed through a service network VPC association. The application can run on any compute platform—such as Amazon Elastic Compute Cloud (Amazon EC2) (such as Auto Scaling groups), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Container Service (Amazon ECS), and AWS Lambda.

Figure 2: Accessing shared service using service network VPC associations

The following steps show how traffic flows from the client to the service:

• (1) The client performs a DNS lookup for a custom domain (for example app1.example.com) representing VPC Lattice Service 1.
• (2) The VPC Amazon Route 53 Resolver checks the associated Private Hosted Zone, which maps the VPC Lattice service FQDN (Fully Qualified Domain Name) managed by VPC Lattice to the custom name (app1.example.com). The resolver returns IP addresses managed by VPC Lattice (not part of the VPC CIDRs).
• (3) The client connects to the service on the correct (for example port 443 for HTTPS). Within the service network, VPC Lattice performs host header-based routing, TLS can be terminated, IAM credentials validated, and application-layer logic applied (for example path-based routing). For end-to-end encryption you can configure HTTPS target groups.
• (4) Requests are load balanced to the appropriate destination target (for example EC2 instances in an Auto Scaling group).

Option 2: Using a service network endpoint (SNE)

The following diagram shows the request flow when a client connects to an HTTP/S application exposed through a service network endpoint.

Figure 3: Accessing shared service using service network endpoints

The following steps show how traffic flows from the client to the service:

• (1) The client performs a DNS lookup for a custom domain (for example app1.example.com) representing VPC Lattice Service 1.
• (2) The VPC Route 53 Resolver resolver checks the associated Private Hosted Zone, which maps the VPC Lattice managed FQDN name derived from the service network endpoint (SNE) ID and service network service association (SNSA) ID to the custom name (app1.example.com). The resolver returns the IP address of the service network endpoint.
• (3) The client connects to the service on the correct port (for example port 443 for HTTPS) through the SNE.
• (4) Traffic is transported privately over PrivateLink to the service network, where VPC Lattice performs host header-based routing, TLS can be terminated, IAM credentials validated, and application-layer logic applied (for example path-based routing).
• (5) Requests are load balanced to the appropriate destination target (for example EC2 instances in an Auto Scaling group).

Clients accessing a shared TCP service

The following diagram illustrates the traffic flow when clients connect to a user-owned TCP application exposed through a service network resource association, using either a service network VPC association or endpoint. The application can be exposed using different resource configurations, such as IP addresses, publicly resolvable DNS names (e.g., AWS-managed FQDNs), or Amazon Resource Names (ARNs). Resources can represent for example Amazon Relational Database Service (RDS) databases (including Amazon Aurora), Amazon Managed Streaming for Apache Kafka (Amazon MSK) clusters, Elastic Load Balancer (ELB) FQDNs, or workloads on-premises reachable from the Resource Gateway VPC. For the overall view, we show both flows on the diagram.

Figure 4: Accessing shared service using resource associations and endpoint

The following steps show how traffic flows from clients to the TCP application:

• (1) Clients perform DNS lookups for a custom domain (for example app2.example.com) representing Resource Configuration 1.
• (2) The VPC DNS resolver checks the associated Private Hosted Zone, which maps the autogenerated resource DNS name. For clients connecting through a VPC association, the return IP addresses are managed by VPC Lattice (not part of the VPC CIDRs). For clients connecting through a service network endpoint, the returned IP address is that of the service network endpoint, and each registered resource receives a unique service network endpoint IP.
• (3) Using SNA: The client connects to the Resource through the service network VPC association on the TCP port 80 used by Resource 1. The service network doesn’t terminate TLS. Instead, it forwards the raw TCP flow to the resource gateway of the associated resource.
• (3a), (3b) Using SNE: The client connects to the Resource through the service network endpoint on the
• TCP port used by Resource 1. Traffic is transported privately over PrivateLink to the service network. The service network doesn’t terminate TLS. Instead, it forwards the raw TCP flow to the resource gateway of the associated resource.
• (4) The resource gateway forwards the traffic to the destination resource. The source IP seen by the resource is the IP address of the resource gateway. If the destination resource configuration is DNS based, then the resource gateway performs DNS lookup on to identify target IPs.

Clients accessing shared AWS PrivateLink endpoints for AWS managed services or custom services

Customers often centralize AWS PrivateLink endpoints for AWS managed services and custom services to streamline management, enhance security by controlling access centrally, reduce endpoint sprawl, and optimize costs by avoiding redundant endpoints across multiple VPCs. Usually, this setup would rely on Transit Gateway or AWS Cloud WAN connectivity to the centralized VPC.

The following diagram shows the traffic flow when a client connects to an AWS service (for example AWS Secrets Manager) exposed centrally through a VPC Interface Endpoint using VPC Lattice. We use Secrets Manager here as an example. However, this model applies to any AWS service that supports VPC Endpoints, and to any custom services you expose through PrivateLink. The AWS service is exposed through a service network resource association to the service network clients, using a DNS-based resource configuration that points to the VPC endpoint FQDN.

Figure 5: Accessing AWS PrivateLink endpoint shared service using resource associations

The following steps show how traffic flows from the client to the AWS service:

• (1) Clients perform DNS lookups for the AWS service domain (for example secretsmanager.us-east-2.amazonaws.com) representing Resource Configuration 2.
• (2) The VPC Route 53 resolver checks the associated Private Hosted Zone, which maps the autogenerated resource DNS name. For clients connecting through a VPC association, the returned IP addresses are managed by VPC Lattice (not part of the VPC CIDRs). For clients connecting through a service network endpoint, the returned IP addresses are those of the service network endpoint. Each registered resource configuration receives a unique IP.
• (3) Using SNA: The client connects to the Resource through the service network VPC association on the TCP port 443 used by resource configuration 2. The service network doesn’t terminate TLS. Instead, it forwards the raw TCP flow to the resource gateway of the associated Resource Configuration.
• (3a), (3b) Using SNE: The client connects to the Resource through the service network endpoint on the TCP port 443 used by resource configuration 2. Traffic is transported privately over PrivateLink to the service network. The service network doesn’t terminate TLS. Instead, it forwards the raw TCP flow to the resource gateway of the associated resource configuration.
• (4) The resource gateway performs a DNS lookup on the configured VPC Endpoint domain (for example vpce-<id>.<service>.<region>.vpce.amazonaws.com). After resolving the IP addresses of the AWS service’s interface endpoints, the resource gateway forwards the traffic accordingly. The source IP seen by the VPC endpoint is the IP of the resource gateway.
• (5) The PrivateLink VPC interface endpoint then forwards the traffic privately to the AWS service (for example secretsmanager.us-east-2.amazonaws.com).

Considerations

Security and access control

• You can use IAM policies to enforce least privilege access to shared services.
• You can use AWS Resource Access Manager (AWS RAM) to share VPC Lattice services and resources securely across accounts.

Network monitoring and observability

• You can use VPC Lattice CloudWatch metrics to monitor service access patterns and optimize performance.
• You can use VPC Lattice access logs for services and resources to gain deep visibility into access patterns and service dependencies.

Cost optimization

• VPC Lattice can offer significant cost savings when accessing shared services over HTTPS or TCP, when compared to a centralized setup using Transit Gateway and AWS Network Firewall setup.

Conclusion

Amazon VPC Lattice provides a powerful abstraction layer for enabling secure, scalable, and policy-driven access to shared services. Eliminating IP address dependencies and integrating with IAM-based access control allows organizations to streamline service-to-service connectivity across multiple environments. Furthermore, implementing the best practices outlined in this post allows organizations to enhance security, reduce network complexity, and enable seamless access to shared services across their AWS infrastructure. To get started with VPC Lattice, check out the VPC Lattice documentation. If you have questions about this post, start a new thread on AWS re:Post or contact AWS Support.

About the authors