AWS VPC Lattice – Application-Layer Service Networking

Amazon VPC Lattice is a fully managed application networking service that connects, secures, and monitors service-to-service and service-to-resource communication across multiple VPCs and AWS accounts — without requiring VPC peering, Transit Gateway, or complex networking configurations. VPC Lattice operates at the application layer (Layer 7), providing built-in service discovery, traffic management, access controls, and observability for modern distributed architectures.

VPC Lattice is the AWS-recommended replacement for AWS App Mesh (which reaches End of Life on September 30, 2026) and eliminates the need for sidecar proxies, simplifying service mesh patterns significantly.

Key Benefits

• No network complexity — Connect services across VPCs and accounts without VPC peering, Transit Gateway, or CIDR coordination.
• Application-layer routing — Route based on HTTP path, headers, methods, and query parameters.
• Built-in security — IAM-based auth policies for service-to-service authorization without code changes.
• Compute agnostic — Works with EC2, ECS, EKS, Fargate, and Lambda targets in a single service.
• No sidecars required — Unlike App Mesh or Istio, VPC Lattice operates as infrastructure — no Envoy proxy injection needed.
• Overlapping CIDR support — Services in VPCs with identical IP ranges can communicate seamlessly.

VPC Lattice Architecture

VPC Lattice introduces a layered architecture with distinct components that separate concerns between network administrators and service owners.

Service Network

• A service network is a logical boundary — a collection of services and resource configurations that can communicate with each other.
• VPCs are associated with a service network to enable client connectivity.
• Clients in an associated VPC can automatically discover and connect to all services/resources in the service network.
• Service networks can be shared across accounts using AWS Resource Access Manager (RAM).
• Auth policies can be attached at the service network level for coarse-grained access control.
• Multiple service networks can be associated with a single VPC using VPC endpoints of type “service network.”
• Service networks are Regional resources.

Services

• A service represents an independently deployable application unit (microservice).
• Similar to an Application Load Balancer — consists of listeners, rules, and target groups.
• Each service gets a unique DNS name (FQDN) automatically registered in Route 53.
• Custom domain names are supported with SSL/TLS certificates via ACM.
• Services can be associated with one or more service networks.
• Fine-grained auth policies can be attached at the individual service level.

Target Groups

• A target group is a collection of compute resources that run your application.
• Supported target types:
  • EC2 instances — Instance IDs
  • IP addresses — For any IP-addressable resource
  • Lambda functions — Serverless targets
  • Application Load Balancers — Existing ALB targets
  • Amazon ECS tasks — Direct ECS integration
  • Kubernetes Pods — Via AWS Gateway API Controller
• Health checks are supported to route traffic only to healthy targets.
• Targets can span multiple Availability Zones for high availability.

Listeners

• A listener checks for incoming connection requests using a specified protocol and port.
• Supported protocols: HTTP, HTTPS, TLS Passthrough (for end-to-end encryption).
• gRPC is supported over HTTP/2.
• Each listener has a default action and can have multiple rules.

Rules

• Rules define how the listener routes requests to target groups.
• Conditions can match on: HTTP method, path pattern, headers, and query parameters.
• Actions include: forward to target group(s), with optional weighted routing for traffic splitting.
• Rules have priorities — evaluated in order from lowest to highest number.
• A default rule handles requests that don’t match any other rule.

Resource Configurations and Resource Gateways (GA at re:Invent 2024)

• A resource configuration represents a TCP-based resource (e.g., RDS database, IP address, domain name) that can be shared across VPCs/accounts.
• A resource gateway is a point of ingress into the VPC where the resource resides, spanning multiple Availability Zones.
• Enables private cross-account access to databases and other TCP resources without NLB or PrivateLink Endpoint Services.
• Resource configurations can be shared via AWS RAM and associated with service networks.

Key Features

Cross-VPC and Cross-Account Communication Without Peering

• VPC Lattice enables service-to-service connectivity across VPCs and accounts without VPC peering, Transit Gateway, or PrivateLink endpoint services.
• No CIDR coordination required — supports overlapping IP address ranges between VPCs.
• Network address translation is handled transparently between IPv4 and IPv6 address spaces.
• Services are shared across accounts using AWS Resource Access Manager (RAM).
• VPC association with a service network is the only requirement for connectivity.

Weighted Routing (Traffic Splitting)

• Forward rules support weighted target groups for traffic distribution.
• Assign weights (0-999) to multiple target groups within a single rule to split traffic proportionally.
• Use cases:
  • Blue/green deployments — Shift traffic gradually from old to new version.
  • Canary releases — Send a small percentage (e.g., 5%) to the new version for validation.
  • A/B testing — Split traffic between different service implementations.
• Instant rollback by adjusting weights back to 100% on the stable target group.

Auth Policies with IAM (Authorization)

• VPC Lattice uses IAM resource policies (auth policies) for service-to-service authorization.
• Supports the standard IAM Principal-Action-Resource-Condition (PARC) model.
• Auth policies can be applied at two levels:
  • Service network level — Coarse-grained (e.g., “only authenticated requests from my AWS Organization”).
  • Service level — Fine-grained (e.g., “only service A in account X can invoke POST /orders”).
• Callers authenticate using AWS SigV4 (Signature Version 4) — the same signing protocol used for AWS API calls.
• Supports conditions on: source VPC, source account, organization ID, request method, path.
• Both layers (service network + service) must independently allow the request — defense in depth.

Mutual TLS (mTLS) and Encryption

• VPC Lattice automatically generates and manages TLS certificates for each service via AWS Certificate Manager (ACM).
• HTTPS listeners terminate TLS at the VPC Lattice data plane — callers do not need to manage certificates.
• TLS Passthrough listeners (launched January 2025) enable end-to-end encryption — TLS is not terminated by VPC Lattice.
• TLS Passthrough routes traffic based on the Server Name Indicator (SNI) field.
• Supports mutual TLS (mTLS) for bidirectional authentication between client and service.
• Client-side authentication uses SigV4 by default; mTLS adds certificate-based identity.

Observability (CloudWatch, Access Logs, X-Ray)

• Access Logs — Detailed per-request logs including source/destination, latency, status codes, and error reasons.
  • Can be sent to: Amazon CloudWatch Logs, Amazon S3, or Amazon Data Firehose.
  • Available at service level, resource level, and service network level.
• CloudWatch Metrics — Automatically published metrics for services and target groups (request count, latency, HTTP status codes, healthy/unhealthy targets).
• AWS X-Ray — Distributed tracing integration for end-to-end request tracking across services.
• VPC Flow Logs — Can capture network-level traffic to/from VPC Lattice endpoints.
• No additional inter-AZ data transfer charges — all cross-AZ traffic is included in data processing charges.

Service Discovery (DNS-Based)

• Each VPC Lattice service gets an auto-generated FQDN in an AWS-managed Route 53 public hosted zone.
• When a VPC is associated with a service network, DNS resolution routes traffic to VPC Lattice data plane endpoints.
• Custom domain names are supported — configure CNAME/Alias records in your own hosted zones.
• No service mesh sidecar or agent required for discovery.

Availability Zone Affinity

• VPC Lattice preferentially routes traffic to targets in the same Availability Zone as the client.
• If the local AZ is unhealthy, traffic is automatically distributed to other AZs.
• Reduces latency and avoids cross-AZ data transfer costs.

On-Premises Access

• VPC endpoints of type “service network” (powered by AWS PrivateLink) enable on-premises clients to access VPC Lattice services.
• Traffic can flow over AWS Direct Connect or Site-to-Site VPN → VPC endpoint → VPC Lattice service network.
• Also supports access via VPC Peering or Transit Gateway through the VPC endpoint.

Integration with Compute Services

Amazon ECS

• ECS tasks can be registered directly as VPC Lattice target group targets.
• Supports both Fargate and EC2 launch types.
• VPC Lattice replaces the need for internal ALBs or service discovery with Cloud Map.
• AWS provides a migration guide from App Mesh to VPC Lattice for ECS workloads.
• Works alongside ECS Service Connect — choose VPC Lattice for cross-account/cross-VPC scenarios.

Amazon EKS (Kubernetes)

• Native integration via the AWS Gateway API Controller — an implementation of the Kubernetes Gateway API.
• Define VPC Lattice services using Kubernetes-native Gateway, HTTPRoute, and GRPCRoute resources.
• The controller automatically maps Kubernetes resources to VPC Lattice services, target groups, and listeners.
• Supports EKS Pod Identity for simplified IAM authentication — pods can sign requests with SigV4.
• Works with self-managed Kubernetes clusters (not just EKS).
• No sidecar injection required — unlike Istio or App Mesh.

AWS Lambda

• Lambda functions can be registered as targets in VPC Lattice target groups.
• Enables serverless backends to participate in the same service network as container/instance workloads.
• VPC Lattice invokes Lambda synchronously when requests are routed to Lambda targets.
• Lambda functions can also act as clients — calling other VPC Lattice services using their DNS names.

Amazon EC2

• EC2 instances can be registered by instance ID or IP address in target groups.
• Supports Auto Scaling Group integration for dynamic target registration.
• Applications on EC2 access VPC Lattice services via DNS — no SDK or agent installation required.
• Health checks validate target availability before routing traffic.

Mixed Compute Environments

• A single VPC Lattice service can have multiple target groups with different compute types.
• Example: Route 80% of traffic to EKS pods, 20% to Lambda for canary testing.
• Enables gradual migration between compute platforms without client-side changes.

VPC Lattice vs App Mesh vs API Gateway vs PrivateLink vs ALB

Feature	VPC Lattice	App Mesh (EOL Sept 2026)	API Gateway	PrivateLink	ALB
Primary Use Case	Service-to-service networking across VPCs/accounts	Service mesh with Envoy sidecars	External/internal API management	Private service exposure to consumers	Load balancing within a VPC
Layer	Layer 7 (HTTP/HTTPS/gRPC/TCP)	Layer 7 (HTTP/gRPC/TCP)	Layer 7 (REST/HTTP/WebSocket)	Layer 4 (TCP/UDP)	Layer 7 (HTTP/HTTPS/gRPC)
Cross-VPC	Yes (native, no peering needed)	Requires VPC connectivity (peering/TGW)	Yes (via public/private endpoints)	Yes (endpoint service model)	No (single VPC only)
Cross-Account	Yes (via AWS RAM)	Limited (shared mesh)	Yes (resource policies)	Yes (allow-listed accounts)	No
Sidecar Required	No	Yes (Envoy proxy)	No	No	No
IAM Auth Policies	Yes (SigV4, PARC model)	No (mTLS only)	Yes (IAM, Cognito, Lambda authorizers)	No (network-level only)	No (security groups only)
Weighted Routing	Yes	Yes	Yes (canary deployments)	No	Yes (target group weights)
Service Discovery	Built-in DNS (auto-generated FQDN)	Cloud Map integration	Custom domain + API endpoint	DNS name of VPC endpoint	DNS name of load balancer
Overlapping CIDRs	Supported	Not supported	N/A	Supported	N/A (single VPC)
Provider Requirement	None (service registration only)	Envoy sidecar per service	None	NLB or GWLB required	None
Pricing Model	Per service/hour + data + requests	Free (pay for Envoy compute)	Per request + data transfer	Per endpoint/hour + data	Per hour + LCU
Status	GA (active development)	EOL September 30, 2026	GA (active development)	GA (active)	GA (active)

When to Choose Which

• VPC Lattice — Service-to-service communication across VPCs/accounts with IAM-based authorization. Best for internal microservice architectures.
• API Gateway — External-facing APIs, rate limiting, API keys, request/response transformation, developer portal. Not designed for east-west traffic.
• PrivateLink — Exposing a specific service to consumers (SaaS model) or accessing AWS services privately. Requires NLB on provider side.
• ALB — Load balancing within a single VPC. Use with VPC Lattice when ALB is a target group target.
• App Mesh — Legacy only. Migrate to VPC Lattice or ECS Service Connect before September 2026.

Use Cases

Microservices Communication

• Connect hundreds of microservices running on mixed compute (EC2, ECS, EKS, Lambda) without managing load balancers per service.
• Apply consistent security policies across all service-to-service traffic.
• Use weighted routing for safe deployments (blue/green, canary).
• Centralized observability for all inter-service communication.

Multi-Account Architectures

• Share services and resources across organizational units using AWS RAM.
• Central platform team manages service networks; application teams own their services.
• Enforce organization-wide auth policies at the service network level.
• No need to manage VPC peering connections or Transit Gateway attachments between accounts.

Service Mesh Replacement (App Mesh Migration)

• Replace AWS App Mesh (EOL September 30, 2026) without application code changes.
• Eliminate Envoy sidecar proxies — reduces compute costs and operational complexity.
• Migration pattern: Create VPC Lattice services → register targets → shift traffic → remove App Mesh resources.
• For ECS workloads, AWS also offers ECS Service Connect as an alternative for intra-cluster communication.

Zero Trust Networking

• Implement defense-in-depth with multiple security layers:
  1. VPC/service network association (network boundary)
  2. Security groups on VPC-to-service-network associations
  3. Service network auth policies (coarse-grained)
  4. Service-level auth policies (fine-grained)
• Every request must be authenticated (SigV4) and authorized (IAM policy evaluation) — no implicit trust based on network position.

Multi-Tenant SaaS Applications

• Isolate tenant resources in separate VPCs while maintaining inter-service connectivity through VPC Lattice.
• Use auth policies to enforce tenant-specific access controls.
• Resource configurations enable secure, private access to shared databases across tenant accounts.

Hybrid and On-Premises Connectivity

• On-premises applications access VPC Lattice services via VPC endpoints (type: service network) over Direct Connect or VPN.
• Consolidate hybrid connectivity through a single VPC endpoint rather than multiple PrivateLink endpoints.

Pricing

VPC Lattice pricing has three dimensions for services and separate pricing for resource access:

Service Pricing (US East – N. Virginia)

Dimension	Price	Notes
Service hourly charge	$0.025/hour (~$18.25/month)	Per provisioned service
Data processing	$0.025/GB	Request + response data combined; includes cross-AZ
HTTP requests	$0.10 per 1M requests/hour (after first 300K free)	First 300,000 requests/hour are free per service
TCP connections (TLS listeners)	$0.10 per 1M connections/hour (after first 300K free)	For TLS Passthrough listeners only

Resource Access Pricing

Dimension	Price
Resource configuration hourly	$0.10/resource/hour (consumer pays)
Data processed (consumer)	$0.01/GB (first 1 PB), $0.006/GB (next 4 PB), $0.004/GB (5+ PB)
Data processed (provider)	$0.006/GB

Key Pricing Notes

• No inter-AZ charges — Cross-AZ data transfer is included in the data processing charge.
• VPC associations are free — No charge for associating VPCs with service networks.
• VPC endpoints (type: service network) are free — No additional charge for service network endpoints.
• Free tier for requests — First 300,000 HTTP requests (or TCP connections) per hour per service are free.
• Prices vary by Region — check the VPC Lattice pricing page for current rates.

AWS Certification Exam Practice Questions

Question 1: A company has microservices running in multiple AWS accounts across different VPCs with overlapping CIDR ranges. They need service-to-service communication with IAM-based authorization and no infrastructure changes to existing VPCs. Which solution meets these requirements with the LEAST operational overhead?

1. Set up VPC peering between all VPCs and use security groups for authorization
2. Deploy AWS Transit Gateway and configure route tables for inter-VPC communication
3. Use Amazon VPC Lattice with a service network shared via AWS RAM and auth policies
4. Create PrivateLink endpoint services with NLBs in each provider VPC

Show Answer

Answer: C –

VPC Lattice supports overlapping CIDRs, provides native cross-VPC/cross-account connectivity without peering or Transit Gateway, and offers IAM-based auth policies. VPC peering (A) doesn’t support overlapping CIDRs. Transit Gateway (B) requires CIDR coordination and doesn’t provide application-layer authorization. PrivateLink (D) requires NLBs and doesn’t offer IAM-based service-to-service auth policies.

Question 2: A development team wants to perform a canary deployment where 5% of traffic goes to a new version of their service running on Lambda, while 95% continues to the existing version on ECS Fargate. The services are in the same VPC. Which VPC Lattice feature enables this?

1. Create separate services for each version with different DNS names
2. Configure a listener rule with weighted target groups — 95% to ECS target group, 5% to Lambda target group
3. Use auth policies to restrict 95% of callers to the old version
4. Deploy two service networks and associate the VPC with both

Show Answer

Answer: B –

VPC Lattice supports weighted routing across target groups within a single listener rule. You can assign weights to multiple target groups containing different compute types (ECS and Lambda), enabling canary deployments without changing client code or DNS configuration.

Question 3: A service network owner wants to enforce that only authenticated requests from their AWS Organization can access any service in the service network, while individual service owners can apply more specific access controls. How should this be configured?

1. Apply an auth policy at the service network level requiring aws:PrincipalOrgID condition, and let service owners apply service-level auth policies
2. Configure security groups on each service to allow only organization IP ranges
3. Use AWS WAF rules attached to the service network
4. Create IAM roles in each account with cross-account trust policies

Show Answer

Answer: A –

VPC Lattice supports auth policies at both the service network level (coarse-grained) and the service level (fine-grained). Both policies must independently allow the request — this implements defense in depth. The service network policy can enforce organization-wide requirements while service owners add specific conditions for their services.

Question 4: A company is migrating from AWS App Mesh (reaching EOL September 2026) to VPC Lattice for their ECS microservices. Which statements about this migration are TRUE? (Select TWO)

1. VPC Lattice requires Envoy sidecar proxies like App Mesh
2. VPC Lattice eliminates the need for sidecar proxies, reducing compute overhead
3. VPC Lattice provides IAM-based authorization that App Mesh did not offer
4. VPC Lattice requires VPC peering for cross-VPC communication
5. VPC Lattice only supports EKS workloads, not ECS

Show Answer

Answer: B, C

VPC Lattice operates as infrastructure without sidecar proxies (B is correct) — this reduces compute costs and eliminates proxy management. VPC Lattice provides IAM auth policies using SigV4 for service-to-service authorization (C is correct), which App Mesh did not offer (App Mesh relied on mTLS only). VPC Lattice does NOT require sidecars (A wrong), does NOT require VPC peering (D wrong), and supports ECS, EKS, Lambda, and EC2 (E wrong).

Question 5: An organization needs to provide private access to an Amazon RDS database from application VPCs in multiple AWS accounts without using VPC peering or Transit Gateway. Which VPC Lattice components are required? (Select THREE)

1. VPC Lattice service with listeners and target groups
2. Resource gateway in the VPC where the RDS database resides
3. Resource configuration defining the RDS database endpoint
4. Service network with VPC associations in consumer accounts
5. Network Load Balancer in front of the RDS database
6. AWS App Mesh virtual nodes for the database

Show Answer

Answer: B, C, D

For TCP resource access (like RDS), VPC Lattice uses resource gateways (B) as ingress points in the resource VPC, resource configurations (C) to define the resource, and service networks (D) for consumer VPC associations. This does NOT require a VPC Lattice service with listeners (A — that’s for HTTP services), an NLB (E — VPC Lattice removes this PrivateLink requirement), or App Mesh (F — which is deprecated).

Important Points for Certification Exams

• VPC Lattice is a fully managed, Regional service — no infrastructure to deploy or manage.
• It operates at Layer 7 (application layer) — not Layer 4 like PrivateLink.
• Supports overlapping CIDRs — a key differentiator from VPC peering and Transit Gateway.
• Auth policies use IAM and SigV4 — not API keys or Cognito tokens.
• No sidecar proxies required — unlike App Mesh or Istio.
• VPC Lattice is the recommended replacement for App Mesh (EOL September 30, 2026).
• Resource configurations (GA 2024) extend VPC Lattice to TCP resources like databases.
• Free tier includes 300,000 requests/hour per service.
• No additional cross-AZ data transfer charges.
• On-premises access is enabled via VPC endpoints of type “service network” over Direct Connect/VPN.

Frequently Asked Questions

What is AWS VPC Lattice?

VPC Lattice is an application-layer networking service that connects services across VPCs and accounts without VPC peering or transit gateways. It handles service discovery, routing, access control, and observability at Layer 7.

How is VPC Lattice different from PrivateLink?

PrivateLink provides one-way private connectivity to a specific endpoint. VPC Lattice enables bidirectional service-to-service communication with built-in routing rules, IAM auth policies, weighted targets, and cross-account service mesh capabilities.

Does VPC Lattice replace App Mesh?

Yes, AWS recommends VPC Lattice as the successor to App Mesh. VPC Lattice is simpler (no sidecar proxies needed), supports cross-VPC/account natively, and integrates with IAM for access control.

Related Posts

• AWS VPC
• AWS VPC Endpoints – Gateway & Interface

References

• AWS VPC Lattice Documentation
• Amazon VPC Lattice Product Page
• Amazon VPC Lattice Pricing
• Amazon VPC Lattice FAQs
• Migrate ECS Workloads from App Mesh to VPC Lattice
• End-to-End Encryption with VPC Lattice TLS Passthrough
• Modern Authentication and Authorization with VPC Lattice