The AWS Certified Solutions Architect - Professional (SAP-C02) exam is, more than anything, a test of connectivity judgment. A scenario hands you a fleet of microservices spread across dozens of accounts and VPCs, sometimes with overlapping CIDR ranges, and asks you to let them talk to each other securely, with the least operational overhead. For years the only tools were Layer 3 and Layer 4: VPC peering, Transit Gateway, and PrivateLink. Amazon VPC Lattice adds a Layer 7 option, and knowing where it fits — and where it doesn’t — is exactly the kind of distinction SAP-C02 rewards.
This guide explains VPC Lattice from an architect’s perspective: what it actually is, how its objects assemble, how it authenticates and authorizes traffic, and — the part the exam really cares about — how to choose it against the connectivity options you already know. For the traditional Layer 3/4 toolkit (Transit Gateway, PrivateLink, VPC endpoints, hybrid connectivity), the SAP-C02 networking deep dive is the companion piece; this article focuses entirely on the application-networking layer.
What Amazon VPC Lattice Actually Is
VPC Lattice is an application networking service for connecting, securing, and monitoring communication between services, regardless of which VPC or account those services live in. Instead of stitching networks together at the IP layer and then bolting on security groups and load balancers, Lattice operates at the application layer (HTTP, HTTPS, and gRPC) and treats the service — not the subnet — as the unit of connectivity.
That framing changes several things at once:
- Connectivity follows the service, not the network. You associate a VPC with a logical group of services; anything in that VPC can then reach those services, without route tables, peering connections, or transit attachments between the networks.
- It handles overlapping CIDRs. Because Lattice works at Layer 7 (it terminates connections and forwards requests), two VPCs with the same
10.0.0.0/16range can still communicate through it — something VPC peering and Transit Gateway cannot do. - Security is identity-aware. Authorization is expressed with IAM-based auth policies using SigV4 request signing, so “which service may call which” is a policy, not just a security-group rule.
- Observability is built in. Access logs and metrics for service-to-service traffic come out of the box.
Think of it as managed, AWS-native application networking that sits closer to a service mesh’s concerns than to a router’s.
The Building Blocks
Four objects make up a VPC Lattice deployment. Getting these straight is most of the battle on the exam.
| Object | What it is |
|---|---|
| Service | A unit of application functionality (a microservice). It has one or more listeners and routing rules that send requests to target groups. |
| Target group | The compute behind a service: EC2 instances, IP addresses, a Lambda function, an Application Load Balancer, or a Kubernetes service. |
| Service network | A logical boundary that groups services and associates client VPCs. It’s the membership and policy layer. |
| Service directory | A central registry of all the Lattice services in an account/Region, for discovery. |
The way they connect:
- A service exposes functionality. Its listener (say, HTTPS on 443) has rules that route by path, header, or method to one or more target groups — including weighted routing for blue/green and canary shifts.
- A service network is where access happens. You associate services into the network (making them reachable) and associate VPCs with the network (letting clients in those VPCs reach the services). A client in an associated VPC simply calls the service’s DNS name; Lattice does the rest.
- Lattice gives each service an auto-generated domain name, and you can attach a custom domain name with an ACM certificate for HTTPS.
Client in VPC-A ──associated──► Service Network ◄──associated── Service "orders"
│ │ listener :443
auth policy │ rules → target group
▼
EC2 / IP / Lambda / ALB / EKSThe key insight: a client doesn’t need a route to the service’s VPC. Membership in the same service network, plus an auth policy that allows the call, is what grants access.
Auth Policies: Identity-Aware Authorization
This is where VPC Lattice earns its place in security-heavy SAP-C02 scenarios. Traffic through Lattice can be authorized with auth policies — IAM resource policies attached to a service network and/or an individual service. Requests are signed with SigV4 (Signature Version 4), so the caller’s IAM principal is known and can be authorized.
- A service network auth policy sets coarse-grained rules for the whole network — for example, “only principals in this Organization / these accounts may use this network.”
- A service auth policy sets fine-grained rules for one service — for example, “only the
checkoutrole mayPOST /payments.” - Both are evaluated; the effective decision is the intersection, the same way IAM and resource policies combine elsewhere.
An example service auth policy allowing a specific role to reach a service:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::111122223333:role/checkout-svc"},
"Action": "vpc-lattice-svcs:Invoke",
"Resource": "*",
"Condition": {
"StringEquals": {"vpc-lattice-svcs:RequestMethod": "POST"}
}
}]
}For the exam, the takeaway is that Lattice authorization is identity-based and layered on top of (not instead of) network controls. You still have security groups on the targets and on the VPC associations; auth policies add the “who is allowed to call this API” dimension that security groups alone can’t express.
Sharing Across Accounts with AWS RAM
Real SAP-C02 scenarios are multi-account. VPC Lattice integrates with AWS Resource Access Manager (RAM) so a service network — or an individual service — can be shared across accounts, typically within an AWS Organization. A platform team owns the service network and shares it; application teams in other accounts associate their services (as producers) or their VPCs (as consumers).
That means the same Lattice construct that connects services within an account extends cleanly to cross-account connectivity without peering meshes or transit attachments between every pair of VPCs. When a question describes a central networking/platform account exposing shared services to many workload accounts at the application layer, RAM-shared Lattice service networks are the pattern being tested.
Observability
Lattice emits service-to-service telemetry without extra instrumentation:
- Access logs can be sent to Amazon CloudWatch Logs, Amazon S3, or Amazon Data Firehose.
- CloudWatch metrics cover request counts, response codes, and latency per service.
For an exam that repeatedly asks “how do you get visibility into traffic between microservices with the least effort,” native access logs and metrics are a strong signal for Lattice over building your own tracing plumbing.
The Decision That Matters: Lattice vs Peering vs Transit Gateway vs PrivateLink
This comparison is the reason to learn Lattice for SAP-C02. Each option solves connectivity at a different layer and scale.
| | Layer | Topology | Overlapping CIDR? | Identity-aware auth | Best for | | --- | --- | --- | --- | --- | | VPC peering | L3 | 1:1, non-transitive | No | No | A small number of VPCs needing full IP connectivity | | Transit Gateway | L3 | Hub-and-spoke, transitive | No | No | Many VPCs/on-prem needing routed IP connectivity at scale | | PrivateLink | L4 | Consumer → one provider service (via NLB/GWLB) | Yes | No (network-level) | Exposing a single service one-directionally, private and unidirectional | | VPC Lattice | L7 | Many-to-many services in a service network | Yes | Yes (IAM/SigV4) | Service-to-service (HTTP/HTTPS/gRPC) across VPCs/accounts with per-request auth |
How to read the exam cues:
- “Full network/IP connectivity between many VPCs and on-prem, at scale” → Transit Gateway. Lattice is not a replacement for routed L3 connectivity.
- “Expose one service privately and one-directionally to consumers” → PrivateLink (interface endpoints to a provider’s NLB). Lattice can also expose services, but PrivateLink remains the classic single-service, unidirectional pattern.
- “Microservices across accounts need to call each other over HTTP/gRPC with authentication and observability, minimal networking overhead, possibly overlapping CIDRs” → VPC Lattice.
- “Two VPCs, simple, need everything routable” → peering.
A useful one-liner: Transit Gateway connects networks; VPC Lattice connects services. They frequently coexist — TGW for the L3 backbone, Lattice for application-layer service connectivity and authorization on top.
Where Lattice Fits in a Modern SAP-C02 Architecture
VPC Lattice increasingly appears in the kind of “modernize this estate” scenarios SAP-C02 favors: an organization with many accounts, a platform team, and a sprawl of microservices that currently talk over a brittle mesh of peering connections and per-workload load balancers. The Lattice pattern replaces that with:
- A service network owned by the platform account and shared via RAM across the Organization.
- Each microservice registered as a Lattice service with listeners, routing rules, and target groups pointing at EC2, Lambda, ALBs, or EKS.
- Auth policies enforcing which principals can call which services, with SigV4 signing.
- Client VPCs associated with the service network so their workloads can reach services by DNS name — no route tables, no peering, overlapping CIDRs tolerated.
- Access logs and metrics feeding the observability stack.
If the surrounding architecture also involves hybrid or edge components, the SAP-C02 hybrid and edge services guide and the multi-account architecture guide round out the picture, since Lattice is usually one layer of a larger multi-account design.
Common Exam Traps
- Lattice does not replace Transit Gateway. If a scenario needs routed IP connectivity for many networks (including on-prem), that’s still TGW. Lattice is application-layer service connectivity, not a network backbone.
- Overlapping CIDRs are a strong Lattice/PrivateLink signal. Because both operate above Layer 3, they work where peering and TGW fail. If a scenario stresses overlapping ranges and service-to-service HTTP with auth, lean Lattice.
- Auth policies are IAM, not security groups. The “which principal may invoke which service/API” control is the auth policy with SigV4. Security groups still exist but don’t express identity.
- RAM is how it goes cross-account. Sharing a service network or service across accounts is a RAM operation, typically within an Organization.
- Protocols are L7. Lattice speaks HTTP, HTTPS, and gRPC. A scenario about raw TCP/UDP or non-HTTP protocols is not a Lattice scenario.
Practice the Connectivity Decisions Under Exam Pressure
The hard part of VPC Lattice on the SAP-C02 isn’t the mechanics — it’s choosing it correctly when peering, Transit Gateway, and PrivateLink are all sitting in the answer options looking reasonable. That judgment only becomes reliable when you’ve worked through enough scenarios to recognize the cues instantly: overlapping CIDRs, service-to-service HTTP, per-request identity, cross-account sharing, minimal networking overhead.
Sailor.sh’s AWS Certified Solutions Architect - Professional (SAP-C02) mock exam bundle is built around exactly these multi-service, multi-account connectivity trade-offs, with explanations that walk through why the right networking primitive wins and why the plausible distractors lose. Combine it with the SAP-C02 networking deep dive for the L3/L4 foundation and the guide to passing SAP-C02 on the first attempt to structure your final weeks.
Frequently Asked Questions
What is Amazon VPC Lattice in one sentence? It’s an application networking service that connects, secures (with IAM-based auth), and monitors service-to-service communication over HTTP, HTTPS, and gRPC across VPCs and accounts, without requiring Layer 3 connectivity between those networks.
How is VPC Lattice different from Transit Gateway? Transit Gateway connects networks at Layer 3 — it routes IP traffic between many VPCs and on-prem in a transitive hub-and-spoke, but it can’t handle overlapping CIDRs and has no identity-aware authorization. VPC Lattice connects services at Layer 7, tolerates overlapping CIDRs, and authorizes traffic per request with IAM auth policies. They often coexist.
When would I still use PrivateLink instead of Lattice? PrivateLink remains the classic pattern for exposing a single service one-directionally and privately to consumers via an interface endpoint to a provider’s Network/Gateway Load Balancer. Lattice shines for many-to-many service-to-service connectivity with per-request identity and built-in observability.
Can VPC Lattice connect services across different AWS accounts? Yes. You share a service network (or an individual service) across accounts with AWS Resource Access Manager (RAM), typically within an AWS Organization. Producer accounts associate their services; consumer accounts associate their VPCs.
Does VPC Lattice work with overlapping CIDR blocks? Yes. Because it operates at the application layer and forwards requests rather than routing IP packets end to end, two VPCs with overlapping CIDRs can still communicate through a Lattice service network — a scenario that breaks VPC peering and Transit Gateway.
What compute can back a VPC Lattice service? A target group can point at EC2 instances, IP addresses, a Lambda function, an Application Load Balancer, or a Kubernetes (EKS) service, and listener rules can route by path, header, or method — including weighted routing for blue/green and canary releases.
Want to know whether you’d pick Lattice, Transit Gateway, or PrivateLink on the real exam? Pressure-test that instinct with the SAP-C02 mock exam bundle and make the right connectivity call automatic before test day.