Amazon VPC Lattice FAQs

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

VPC Lattice helps address the following use cases:

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

Apply granular access permissions – Improve service-to-service and service-to-resource 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 and service-to-resource interactions – Monitor and troubleshoot service-to-service and service-to-resource 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 networks, called service networks, that enable service-to-service and service-to-resource communication across virtual private clouds (VPCs) and account boundaries, abstracting network complexity. It offers connectivity over HTTP/HTTPS, gRPC, and TCP protocols through a dedicated data plane within VPC Lattice. This data plane is exposed through both link-local endpoints that can be accessed only from within your VPC, and VPC endpoints of type service network that can be accessed from within your VPC and also from outside 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, clients within the VPC can automatically discover and connect to the collection of services and resources 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), Amazon Elastic Container Service (Amazon ECS), AWS Fargate, 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. Resource owners can share resources such as RDS databases between accounts and add these resources to service networks. In addition to traffic management, service and resource 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 and resources. 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 and resources progressively over time.

VPC Lattice introduces six 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.

Resource configuration - A resource configuration represents a TCP-based resource that resides in a VPC or on premises, such as an RDS database, domain-name target, or an IP address. A resource configuration can be shared between accounts. When the resource configuration is shared with another account, that account can access the resource privately.

Resource gateway - A resource gateway is a point of ingress in a VPC for traffic destined to TCP resources that are shared in a resource configuration.

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

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 and resources 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 and resource 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 the service, resource, and service network levels. To have full observability for your environment, you can also view metrics for your services and VPC Lattice target groups. Service network, service, and resource level logs can be exported to Amazon CloudWatch logs, Amazon Simple Storage Service (S3), or Amazon Data Firehose. Additionally, other AWS observability features, such as VPC flow logs and AWS X-Ray, can be used 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, resources, resource configurations, and service networks are Regional components. If you have a multi-Region environment, you can have services, resources, resource configurations, 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 for VPC Lattice services and resources across VPCs and accounts. Amazon VPC Lattice helps you connect both IPv4 and IPv6 services and resources securely, and monitor communication flows, in a simple and consistent way across various compute types. It provides native interoperability between IP services and resources, regardless of the underlying IP addressing, which can help facilitate IPv6 adoption across services and resources 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.

Yes, services and resources can be accessed from on premises using VPC endpoints (powered by AWS PrivateLink). You can put your services and resources into a service network and create a VPC endpoint (type “service network”) to enable connectivity between those services and resources from on premises.

You can register multiple service networks to a VPC using VPC endpoints. You can create multiple VPC endpoints of type “service network,” each of which connects to a different service network.