Amazon VPC Lattice FAQs

Amazon VPC Lattice is an application layer networking service that gives you a consistent way to connect, secure, and monitor service-to-service communication without any prior networking expertise. With VPC Lattice, you can configure network access, traffic management, and network monitoring to enable service-to-service communication consistently across VPCs and accounts, regardless of the underlying compute type.

VPC Lattice helps address the following use cases:

Connect services at scale – Connect thousands of services across VPCs and accounts without increasing network complexity.

Apply granular access permissions – Improve service-to-service security and support Zero Trust architectures with centralized access controls, authentication, and context-specific authorization.

Implement advanced traffic controls – Apply granular traffic controls, such as request-level routing and weighted targets, for blue/green and canary deployments.

Observe service-to-service interactions – Monitor and troubleshoot service-to-service communication for request type, traffic volume, errors, response time, and more.

VPC Lattice helps bridge the gap between developers and cloud administrators by providing role-specific features and capabilities. VPC Lattice will appeal to developers who do not want to learn and perform the common infrastructure and networking tasks required to get modern applications running quickly. Developers should be able to focus on building applications, not networks. VPC Lattice will also appeal to cloud and network administrators who are looking to increase their organization’s security posture by enabling authentication, authorization, and encryption in a consistent way across mixed compute environments (instances, containers, serverless), and across VPCs and accounts.

You can use VPC Lattice to create logical application layer networks, called service networks, that enable service-to-service communication across virtual private clouds (VPCs) and account boundaries, abstracting network complexity. It offers connectivity over HTTP/HTTPS and gRPC protocols through a dedicated data plane within VPC. This data plane is exposed through a link-local endpoint that can be accessed only from within your VPC.

Administrators can use AWS Resource Access Manager (AWS RAM) to control which accounts and VPCs can establish communication through a service network. When a VPC is associated with a service network, resources within the VPC can automatically discover and connect to the collection of services in the service network. Service owners can use VPC Lattice compute integrations to onboard their services from Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Lambda, and choose one or more service networks to join. Service owners can also configure advanced traffic-management rules to define how a request should be processed to support common patterns such as blue/green and canary-style deployments. In addition to traffic management, service owners and administrators can implement additional access controls by enforcing authentication and authorization through the VPC Lattice Auth policy. Administrators can enforce guardrails at the service network level and apply fine-grained access controls on individual services. VPC Lattice is designed to be non-invasive and work alongside existing architecture patterns, allowing development teams across your organization to incrementally onboard their services progressively over time.

VPC Lattice introduces four key components:

Service – An independently deployable unit of software that delivers a specific task or function. A service can live in any VPC or account and can run on instances, containers, or serverless compute. A service consists of listeners, rules, and targets groups, similar to an AWS Application Load Balancer.

Service directory – A centralized registry of all services that have been registered with VPC Lattice that you have created or have been shared with your account through AWS RAM.

Service network – A logical grouping mechanism to simplify how users enable connectivity and apply common policies to a collection of services. Service networks can be shared across accounts with AWS RAM and associated with VPCs to enable connectivity to a group of services.

Auth policy – Auth policy is an AWS Identity and Access Management (IAM) resource policy that you can associate with a service network and individual services to define access controls. Auth policy uses IAM, and you can specify rich principal-action-resource-condition (PARC)-style questions to enforce context-specific authorization on VPC Lattice services. Typically, an organization would apply coarse-grained Auth policies at the service network, such as “only authenticated requests within my org-id are allowed,” and more granular policies at the service level.

VPC Lattice is currently available in the following AWS Regions: US East (Ohio), US East (N. Virginia), US West (Oregon), US West (Northern California), Africa (Cape Town), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Seoul), Asia Pacific (Tokyo), Canada (Central), Europe (Ireland), Europe (Frankfurt), Europe (London), Europe (Milan), Europe (Paris), Europe (Stockholm), and South America (Sao Paulo).

Lattice is a feature of VPC and it doesn’t require a separate assessment/call-out. Features of in-scope services are considered as “assessed/covered” and it is also stated on the AWS Services in Scope by Compliance Program. Unless specifically excluded, generally available features of each of the services are considered in scope of the assurance programs.

There are no additional cross-AZ data transfer charges for Amazon VPC Lattice. Data transfer across availability zones is covered by the data processing dimension of the VPC Lattice service pricing.

To monitor traffic flows and reachability, you can make use of Access Logs at both the Service Network and Service level. To have full observability for your environment, you can also view metrics for your Services and Lattice target groups. Service Network and Service level logs can be exported to CloudWatch Logs, S3, or Kinesis Data Firehose. Additionally, other AWS observability features, such as VPC Flow Logs and AWS X-Ray can be utilized to track network flows, service interactions, and API calls.

When a VPC Lattice service is created, a fully qualified domain name (FQDN) is created in a Route 53 public hosted zone that is managed by AWS. You can use these DNS names in CNAME Alias records in your own Private Hosted Zone(s), associated with the VPC(s) that are associated with the Service Network. You can specify a custom domain name to resolve custom service names. If you specify a custom domain name, you must configure DNS routing after your service is created. This is to map DNS queries for the custom domain name to the VPC Lattice endpoint. If you’re using Route 53 as your DNS service, you can configure a CNAME Alias record within your Amazon Route 53 public or private hosted zones. For HTTPS, you must also specify an SSL/TLS certificate that matches the custom domain name.

Yes, Amazon VPC Lattice supports HTTPs and also generates a certificate for each Service, managed through Amazon Certificate Manager (ACM). For client-side authentication, Lattice uses AWS SIGv4.

Yes, Amazon VPC Lattice is a highly available, distributed, Regional service. When you register a Service in VPC Lattice, it's a best practice for targets to be spread across multiple Availability Zones. The VPC Lattice Service will ensure traffic is routed to healthy targets, based on the configured rules and conditions.

Amazon VPC Lattice natively integrates with your Amazon Elastic Kubernets Service (EKS) and self-managed Kubernetes workloads through the AWS Gateway API Controller that is an implementation of the Kubernetes Gateway API. This facilitates registration of existing or new Services to Lattice, and dynamic mapping of HTTP Routes to Kubernetes resources.

Amazon VPC Lattice services and service networks are Regional components. If you have a multi-Region environment, you can have Services and Service Networks in every Region. For cross-Region and on-premises communication patterns, you can currently rely on AWS global connectivity services like cross-Region VPC Peering, AWS Transit Gateway, AWS Direct Connect, or AWS Cloud WAN. Please see this blog that details the cross-Region connectivity patterns.

Yes, Amazon VPC Lattice supports IPv6 and can perform network address translation between overlapping IPv4 and IPv6 address space across VPC Lattice services and VPCs. Amazon VPC Lattice helps you connect both IPv4 and IPv6 services securely, and monitor communication flows, in a simple and consistent way across various compute types. It provides native interoperability between IP services regardless of the underlying IP addressing, which can help facilitate IPv6 adoption across services on AWS. Please review this blog for more details.

Yes, tags can be used to automate the addition and removal of Amazon VPC Lattice resource associations, and cross account resource shares using Amazon EventBridge, AWS Lambda, AWS CloudTrail, and AWS Resource Access Manager (AWS RAM). These methods can be used within a single AWS Organization or across multiple AWS Accounts, supporting multiple use cases such as vendor/client applications. Please see this blog for more details and implementation examples.

The design of your Service Network distribution should map to your organization structure and operational model. You can choose to have an organization-wide domain-specific Service Network, and configure the Access Policies accordingly. Or you can have a more segmented approach to Service Networks, associating them with each of your routing domains and across independent Business Units in your organization. One VPC can be associated with one Service Network at a time, while a Service can be registered to multiple Service Networks.