KONG VPC HUB · REVIEW DRAFT

Static network topology

Dashed, arrowless links = configured VPC peering.No API requests are shown in this view.
Three Service Provider VPCs peered directly with the Kong Hub VPCThree separate static peering relationships connect VPC A, VPC B and VPC C to the Hub. The Hub hosts private and public API Data Plane pools in Tokyo, each controlled by its own Control Plane in North America. No VPC to VPC transit or API call arrows are represented. Konnect · North America (US)Internal CP + Public CPManagement layer · not part of VPC peering Kong Hub VPCPlatform Account · Tokyo (ap-northeast-1) Private DP poolSelf-hosted Kong · Internal CP Public API DP poolSelf-hosted Kong · Public CP Peering A–HubStatic · bidirectional Peering B–HubStatic · bidirectional Peering C–HubStatic · bidirectional Provider A VPCAccount A · TokyoApp AInternal API consumer Provider B VPCAccount B · TokyoApp BInternal APIs Provider C VPCAccount C · TokyoApp CInternal + selected public APIs
Configuration, not execution

Three persistent links between VPC boundaries, not Apps or DPs. Each requires routes and security rules on both sides.

No transitive peering

No direct A/B/C peering. Kong terminates the client connection and opens an upstream connection; it is not a VPC transit router.

Read together with the API flow

A → Hub uses Peering A–Hub. Hub → B/C uses Peering B–Hub/C–Hub. Internet → public ingress is not peering; its private upstream leg uses Peering C–Hub.

Concept design · Peering reflects the supplied topology, not approval of the ~100-VPC scale. AWS peering requirements · Published for review.