Skip to content

VPC Lattice Deep Dive Overview ​

Scope: VPC Lattice service/resource APIs and AWS Gateway API Controller; verify the selected release and installed CRDs. Last Updated: October 12, 2026

What This Section Covers ​

  • What actually changes when you move from a sidecar-proxy service mesh (App Mesh, Istio) to a managed data plane (VPC Lattice)
  • How documented Lattice addressing, SigV4 signing and applicable auth policies change the request path
  • The structural differences you hit when moving workload identity from SPIFFE/SPIRE to IAM, and why those become review board issues

Why This Section Exists Separately ​

This section is about understanding concepts. How to create Lattice resources and install the AWS Gateway API Controller is already covered in VPC Lattice, and the feature-by-feature comparison with Istio lives in Istio vs VPC Lattice. What those two documents do not cover is what this section addresses: "why was it designed this way" and "what follows from that design."

There is urgency behind it. AWS App Mesh support ended on September 30, 2026, and the App Mesh console and App Mesh resources are no longer accessible. New customer onboarding had been closed since September 24, 2024. For any organization that ran App Mesh, this migration is no longer optional; the deadline has passed.

But App Mesh and Lattice are not two implementations of the same thing. The data plane sits in a different place (inside the Pod vs. AWS infrastructure), identity is proven at a different granularity (connection vs. request), and the root of trust is owned by a different party (customer CA vs. AWS IAM/STS). If you approach it by swapping resource names one at a time, you will discover functional gaps and failed security reviews late in the migration. The purpose of this section is to surface those gaps first.

Audience and Assumptions ​

  • AWS architects and customer infrastructure engineers
  • We assume you already know EKS and Kubernetes
  • We assume VPC Lattice and service mesh internals are new to you
  • Code and manifest examples are kept to a minimum. This is not a hands-on lab guide

Document Structure ​

#DocumentQuestion it answers
1App Mesh vs VPC Lattice ArchitectureWhen the data plane moves from the Pod into the infrastructure, what survives and what disappears?
2Latency Impact AnalysisBoth degrading and improving factors exist. Which one wins in our environment?
3IAM Authentication Flow in DetailWhat happens across the four stages from signing a request to authorizing it?
4Foundations: Link-Local and SNIHow is traffic intercepted without a sidecar? What do you lose by not terminating TLS?
5Workload Identity Migration: SPIFFE to IAMCan IAM do what SPIRE was doing? What is not replaced?
6Constraints and Decision PointsWhich capability, trust, cost and recovery choices must be settled?
7Kernel DatapathHow do Pod routing, proxy rules and connection tracking affect the path?

Reading in order from 1 is recommended. Document 4 (link-local, SNI) is prerequisite knowledge for the constraints in 3 and 6. It is placed later, but if network fundamentals are unfamiliar, read 4 first.

A Note on Accuracy ​

The factual claims in this section are based on AWS official documentation, the AWS Gateway API Controller documentation, the aws-samples/migrating-from-aws-app-mesh-to-amazon-vpc-lattice reference implementation, and the SPIFFE/SPIRE documentation.

Anything not confirmed against official documentation is not stated as fact; it is marked with a Needs verification block. Lattice is a service that keeps gaining features, and in particular quotas and pricing vary by region and over time. Before finalizing a design, check current values directly in the Service Quotas console and on the VPC Lattice pricing page.

Ask the docs