AWS VPC Lattice: Service-to-Service Networking Without a Mesh

Connecting services across VPCs and AWS accounts has traditionally meant VPC peering or Transit Gateway — both L3/L4 network-level plumbing that gets you IP reachability and nothing else. Authentication, retries, traffic shifting, and observability are still the calling service's problem. VPC Lattice, previewed at re:Invent 2022 and generally available since March 2023, moves that connectivity up to L7: it's application-aware, handles auth per request, and doesn't care whether the services it connects are on EC2, Lambda, ECS, or EKS.

It is explicitly not a service mesh — no sidecars, no per-pod proxy. It's closer to a managed, cross-account API gateway for internal service traffic.

Core Concepts

Service Network — the logical boundary. VPCs and accounts associate with a Service Network to participate; once associated, any Service registered in that network is reachable from anywhere else in it, regardless of the underlying VPC's route tables or peering state.

Service — a registered, addressable endpoint backed by one or more target groups. Targets can be EC2 instances, Lambda functions, IP addresses, or (via the Kubernetes integration below) Pods behind a Kubernetes Service.

Auth policies — Lattice can enforce IAM/SigV4 request signing on traffic between services, so "can Service A call Service B" becomes an IAM policy statement instead of a network-layer allow rule. This is optional per Service — you can run a Service network-open (any associated VPC can reach it) or IAM-authenticated (caller identity is checked on every request).

Weighted target groups — a Service can split traffic across multiple target groups by percentage, which is the primitive canary and blue-green deployments are built on: point 95% of traffic at the stable target group and 5% at the new one, then shift the weights as confidence builds.

Service Network (spans VPCs + accounts)
    │
    ├── Service: payments-api
    │     ├── Target Group: payments-api-v1  (weight: 90)
    │     └── Target Group: payments-api-v2  (weight: 10)
    │
    └── Service: orders-api
          └── Target Group: orders-api-stable (weight: 100)

How It Differs From What You Already Have

vs. VPC Peering / Transit Gateway — both are network-layer (L3) constructs: they make IP ranges reachable across VPC boundaries and stop there. Lattice operates at L7, is service-aware (you register a named Service, not a CIDR block), and layers auth and traffic management on top. You can run Lattice over VPCs that also have peering or Transit Gateway in place — they're not mutually exclusive, but for pure service-to-service traffic, Lattice replaces the need for peering just to reach the target.

vs. PrivateLink — PrivateLink is one-directional: a provider publishes a single service via an endpoint, consumers connect to it, and that's the whole relationship. Lattice is many-to-many within a Service Network, at L7, with the auth and traffic-shifting features PrivateLink doesn't have.

vs. a self-run service mesh (Istio, Linkerd) — a mesh gets you the same category of feature (L7 routing, mTLS, traffic shifting) but requires sidecar injection into every pod, is Kubernetes-native only, and you operate the control plane yourself. Lattice is AWS-managed, works across compute types Kubernetes doesn't touch (Lambda, plain EC2), and needs no sidecar — the tradeoff is it's AWS-specific and its policy/routing model is less expressive than what Istio's VirtualService/AuthorizationPolicy can do. Teams already deep in Istio or Linkerd for in-cluster traffic don't need Lattice to replace that; Lattice earns its place specifically for the cross-VPC, cross-account, and non-Kubernetes-compute cases a cluster-scoped mesh doesn't reach.

vs. AWS App Mesh — App Mesh solved a similar L7 problem earlier, using Envoy sidecars, and AWS has stopped onboarding new customers to it since September 24, 2024. AWS has published an official end-of-support date of September 30, 2026, after which the App Mesh console and its resources stop being accessible — existing customers get critical security and availability updates until then, but not new features. AWS's own migration guidance points existing App Mesh users toward VPC Lattice (for EKS/ECS/EC2 workloads generally) or Amazon ECS Service Connect (for ECS-only setups). If you're on App Mesh today, this isn't a someday problem — plan the migration now rather than after the console goes away.

Kubernetes Integration: the Gateway API Controller

The AWS Gateway API Controller implements the standard Kubernetes Gateway API using VPC Lattice as the data plane — instead of HTTPRoute resources programming an in-cluster Ingress controller or mesh, they program Lattice Services and target groups directly:

1apiVersion: gateway.networking.k8s.io/v1
2kind: Gateway
3metadata:
4  name: internal-services
5spec:
6  gatewayClassName: amazon-vpc-lattice
7  listeners:
8    - name: http
9      protocol: HTTP
10      port: 80
11---
12apiVersion: gateway.networking.k8s.io/v1
13kind: HTTPRoute
14metadata:
15  name: payments-route
16spec:
17  parentRefs:
18    - name: internal-services
19  rules:
20    - backendRefs:
21        - name: payments-api
22          port: 8080

Applying this creates the corresponding Lattice Service Network, Service, and target group automatically — a pod behind the payments-api Kubernetes Service becomes reachable from any other VPC or account associated with the Service Network, without a VPC peering connection or a load balancer per environment. AWS has continued shipping updates to the underlying Lattice APIs the controller depends on (configurable IP addresses for resource gateways landed in October 2025, for reaching non-Kubernetes TCP resources like databases), so check the controller's own release notes for the minimum Lattice API version it expects before upgrading either independently.

Frequently Asked Questions

Does VPC Lattice replace my Application Load Balancer?

Not directly — an ALB is still the right tool for internet-facing or single-VPC traffic where you don't need cross-account service discovery. Lattice earns its place specifically for service-to-service traffic that needs to cross VPC or account boundaries, where the alternative would otherwise be a peering connection plus a load balancer per side.

Is Lattice traffic encrypted?

Not automatically — it depends on the listener protocol you pick. A Service's listener can be HTTP (plaintext), HTTPS, or TLS; only the latter two encrypt data-plane traffic. The upside is you don't have to bring your own certificate the way you would for an ALB listener: choose HTTPS and VPC Lattice provisions and manages a TLS certificate for the service's auto-generated domain name automatically (you only need ACM yourself if you're attaching a custom domain). Separately, the VPC Lattice control plane — the CRUDL API calls that create and manage Services — is always TLS-protected regardless of what you pick for the data plane. IAM auth policies are a distinct, optional layer on top of whatever encryption you've configured, controlling who can call a Service rather than whether the bytes in transit are encrypted.

Can Lambda functions both call and be called through VPC Lattice?

Yes — Lambda can be registered as a target behind a Lattice Service (other services call it through Lattice), and a Lambda function's outbound calls to other Lattice Services work the same as any other compute type's, as long as the function runs in a VPC associated with the same Service Network (or the target Service is configured for network-open access).

What happens to existing traffic if I shift target group weights?

Weight changes apply to new connections going forward — Lattice doesn't drop or migrate already-established connections when you reweight a Service's target groups. This is what makes gradual canary rollouts safe: existing sessions ride out on their original target group while new traffic gradually shifts, rather than everything cutting over at once.

For the Kubernetes-native alternative when your traffic never leaves a single cluster, see Istio vs Linkerd: Choosing a Service Mesh. For the Gateway API standard this integration implements, see Kubernetes Gateway API: HTTPRoute, GRPCRoute, and the End of Ingress Annotations.

Untangling cross-account service connectivity that's currently held together with VPC peering and hope? Talk to us at Coding Protocols — we help platform teams design networking that scales past the first two accounts.

Official References

• Amazon VPC Lattice documentation — Service Networks, Services, target groups, auth policies
• AWS Gateway API Controller for VPC Lattice — Kubernetes Gateway API implementation, concepts, FAQ