Multi-cloud Dedicated Cloud Gateway network architecture

Uses: Kong Gateway

Hostname strategies

The three supported hostname strategies differ in how they route traffic across deployments, and what infrastructure they require:

Option	How it works	Pros	Cons
Cloud-specific hostnames (recommended)	Each cloud deployment gets its own hostname. Clients use the hostname for the cloud they want to target: `aws.api.example.com` → AWS DCGW → AWS upstreams `azure.api.example.com` → Azure DCGW → Azure upstreams `gcp.api.example.com` → GCP DCGW → GCP upstreams You manage DNS records. Each hostname CNAMEs directly to that cloud’s gateway endpoint.	Deterministic routing (no accidental cross-cloud traffic) Clear operational blast radius per cloud Predictable latency and egress costs No additional routing layer required	Clients must know which hostname to call Multiple DNS records and certificates to manage
Single global hostname with geo-proximity DNS	A single hostname routes traffic to the nearest cloud deployment based on the client’s geographic location. DNS selects the closest gateway deployment and the request lands on that cloud’s data planes, which route to upstream services configured in that deployment. DNS routing is not HTTP-aware. `api.example.com/azure` does not guarantee traffic reaches the Azure deployment. If your APIs or upstreams differ per cloud, use cloud-specific hostnames to avoid cross-cloud routing.	Single hostname for all consumers Optimizes latency automatically Supports active/active resiliency	Only works when APIs and upstreams are identical across all clouds Can introduce cross-cloud latency or private networking issues if upstreams are cloud-specific No path, header, or tenant-based routing
Single hostname with L7 edge routing	A CDN or global load balancer sits in front of all cloud deployments and routes traffic based on path, header, or tenant. The L7 edge handles WAF, TLS termination, and traffic steering before forwarding requests to the correct deployment.	HTTP-aware routing under a single hostname Supports path-based, header-based, and tenant-based routing Centralized WAF and TLS termination	Adds an architectural component you own and operate Introduces an additional latency hop Most operationally complex option

Option

How it works

Pros

Cons

Cloud-specific hostnames (recommended)

Each cloud deployment gets its own hostname. Clients use the hostname for the cloud they want to target:

aws.api.example.com → AWS DCGW → AWS upstreams
azure.api.example.com → Azure DCGW → Azure upstreams
gcp.api.example.com → GCP DCGW → GCP upstreams

You manage DNS records. Each hostname CNAMEs directly to that cloud’s gateway endpoint.

Deterministic routing (no accidental cross-cloud traffic)
Clear operational blast radius per cloud
Predictable latency and egress costs
No additional routing layer required

Clients must know which hostname to call
Multiple DNS records and certificates to manage

Single global hostname with geo-proximity DNS

A single hostname routes traffic to the nearest cloud deployment based on the client’s geographic location. DNS selects the closest gateway deployment and the request lands on that cloud’s data planes, which route to upstream services configured in that deployment.

DNS routing is not HTTP-aware. api.example.com/azure does not guarantee traffic reaches the Azure deployment. If your APIs or upstreams differ per cloud, use cloud-specific hostnames to avoid cross-cloud routing.

Single hostname for all consumers
Optimizes latency automatically
Supports active/active resiliency

Only works when APIs and upstreams are identical across all clouds
Can introduce cross-cloud latency or private networking issues if upstreams are cloud-specific
No path, header, or tenant-based routing

Single hostname with L7 edge routing

A CDN or global load balancer sits in front of all cloud deployments and routes traffic based on path, header, or tenant. The L7 edge handles WAF, TLS termination, and traffic steering before forwarding requests to the correct deployment.

HTTP-aware routing under a single hostname
Supports path-based, header-based, and tenant-based routing
Centralized WAF and TLS termination

Adds an architectural component you own and operate
Introduces an additional latency hop
Most operationally complex option

Architecture

The following diagrams show the architecture for each multi-cloud configuration option:

Cloud-specific hostnames

Each cloud deployment gets its own hostname. Clients use the hostname for the cloud they want to target:

 
flowchart LR
    client1["Client"] --> aws_dns["aws.api.example.com"]
    client2["Client"] --> azure_dns["azure.api.example.com"]
    client3["Client"] --> gcp_dns["gcp.api.example.com"]

    aws_dns --> aws["AWS DCGW"]
    azure_dns --> azure["Azure DCGW"]
    gcp_dns --> gcp["GCP DCGW"]

    aws --> aws_up["AWS upstreams"]
    azure --> azure_up["Azure upstreams"]
    gcp --> gcp_up["GCP upstreams"]

You can optionally use api.example.com (geo‑routed) for generic global access or disaster recovery.

Geo-proximity DNS

A single hostname routes traffic to the nearest cloud deployment based on the client’s geographic location.

 
flowchart LR
    client["Client"] --> dns["api.example.com (geo-proximity DNS)"]

    dns --> aws["AWS DCGW"]
    dns --> azure["Azure DCGW"]
    dns --> gcp["GCP DCGW"]

    aws --> aws_up["AWS upstreams"]
    azure --> azure_up["Azure upstreams"]
    gcp --> gcp_up["GCP upstreams"]

L7 edge routing

A CDN or global load balancer sits in front of all cloud deployments and routes traffic based on path, header, or tenant.

 
flowchart LR
    client["Client"] --> hostname["api.example.com"]
    hostname --> edge["Global L7 edge (CDN/global load balancer)"]

    edge --> aws["AWS DCGW"]
    edge --> azure["Azure DCGW"]
    edge --> gcp["GCP DCGW"]

    aws --> aws_up["AWS upstreams"]
    azure --> azure_up["Azure upstreams"]
    gcp --> gcp_up["GCP upstreams"]

The global L7 edge would have:

Path-based routing (/aws/*, /azure/*, /gcp/*)
Header-based or tenant-based routing
Centralized WAF/TLS termination

Next Steps

Dedicated Cloud Gateways production readiness checklist