Several county VPCs must consume a shared partner case-management API privately without building a full VPC peering mesh to the partner network. Which approach scales private connectivity cleanly?

When several county VPCs must consume a shared partner case-management API privately, building a full VPC peering mesh to the partner network does not scale: each new consumer VPC multiplies peering connections, route entries, and operational risk. AWS PrivateLink interface endpoints let the partner expose the API as a Network Load Balancer–fronted endpoint service so consumer VPCs create interface endpoints and reach the API privately over AWS’s network—without transitive peering sprawl or internet exposure. That is the clean private-connectivity pattern for multi-VPC civic consumers of a partner service.

Peering every consumer VPC directly to every partner VPC and managing the mesh by spreadsheet recreates the operational pain PrivateLink avoids and often fails CIDR-overlap and route-scale limits. Publishing the partner API on the open Internet and relying on security groups alone expands exposure beyond the private requirement. Requiring each VPC to use public NAT IPs as the only “private” model is not private connectivity; it hairpins through public address space.

Exam caveat: PrivateLink is directional consumer-to-provider endpoint connectivity; it is not a full mesh replacement for every east-west VPC use case (Transit Gateway often handles hub-and-spoke VPC connectivity). Endpoint policies and security groups still matter for least privilege.

Operational check: create an endpoint service in the partner account and interface endpoints in parks, courts, and utilities VPCs; resolve the private DNS name; confirm traffic never requires IGW paths; and onboard a new consumer VPC with only an endpoint—no new peer to the partner network.