DEDICATED CLOUD GATEWAY · REVIEW DRAFT

Static connectivity and management topology

TGW attachmentCP/DP associationAll links are static and arrowless; no API calls are shown.
Private and public Dedicated Cloud Gateways with separate Control PlanesAn internal Control Plane and a public Control Plane in the Konnect North America geo manage separate private and public Dedicated Cloud Gateway Data Plane deployments in Tokyo. The private gateway is attached to a customer Transit Gateway that connects three Service Provider VPCs. The public-ingress gateway is also attached to the same Transit Gateway and reaches a private upstream. API access and private connectivity are separate settings. Every line is a static connectivity or management definition without direction arrows. Konnect · North America (US geo)Internal Control PlanePublic Control Plane Internal API DCGW VPCKong-managed · Tokyo (ap-northeast-1)Private-ingress DP poolapi_access: private · Private upstreams Public API DCGW VPCKong-managed · Tokyo (ap-northeast-1)Public-ingress DP poolapi_access: public · Private upstreams One TGW attachmentOne TGW attachment Customer AWS Transit GatewayPlatform-managed hub · Tokyo Provider A VPCAccount A · Tokyo · TGW attachment AApp AInternal API consumer Provider B VPCAccount B · Tokyo · TGW attachment BApp BPrivate upstream Provider C VPCAccount C · Tokyo · TGW attachment CApp CPrivate upstream · Selected APIs via Kong
Private path: hub-and-spoke

Both DCGW VPCs and the three provider VPCs attach to TGW: five attachments total. Route tables, security rules, and private DNS constrain reachability.

Public ingress ≠ public upstream

The Public API DP accepts Internet traffic but reaches App C privately via TGW. Provider C needs no Internet-facing upstream endpoint.

Configuration, not execution

Lines define durable associations and reachability. Open the request-flow view to see directional App → DP → App API calls.