---
title: "Multi-Cloud API Gateway"
description:
  "Run Zuplo on managed edge, single-tenant dedicated (Akamai, AWS, Azure, GCP,
  Equinix), or self-hosted Helm on any Kubernetes — all behind one control
  plane. Reach any backend on any cloud or on-prem with WireGuard tunnels,
  PrivateLink, mTLS, AWS IAM, Azure AD, and GCP IAM."
canonicalUrl: "https://zuplo.com/features/multi-cloud"
sourceUrl: "https://zuplo.com/features/multi-cloud"
pageType: "feature"
generatedAt: "2026-08-03"
---

# One gateway. Any cloud. Any backend.

> Your users are everywhere, and your backends run across AWS, GCP, Azure, and
> on-prem. Zuplo sits at the edge nearest each client and proxies every request
> straight to the right backend — skipping the extra hop through a central cloud
> region, and staying online when one goes down.

## Why this matters

Your APIs landed on three different clouds. Your gateway only speaks one. Most
teams didn't choose a multi-cloud strategy — they accumulated one. The gateway
shouldn't be the reason consolidation drags on for five years.

- **One gateway per cloud** — Each cloud got a different gateway when it landed.
  Now your security team owns three different policy languages, three different
  observability backends, and three different on-call runbooks.
- **Public-internet backends** — Your private services aren't actually private —
  there's a load balancer on the internet because that was the only way the
  legacy gateway could reach them. WAF, IP allowlists, and prayer keep it locked
  down.
- **Vendor lock-in tax** — Migrating off the gateway means rewriting every
  policy, re-issuing every API key, re-instrumenting every dashboard. So you
  stay, even when the renewal quote arrives.
- **On-prem stuck on a VPN box** — The mainframe still runs payroll. Reaching it
  from a cloud gateway means a site-to-site VPN, a NAT instance, and a quarterly
  conversation with the network team about "the firewall rule that broke last
  week."

## One control plane. Three deployment surfaces.

- **One gateway, every cloud** — Run Zuplo on managed edge, dedicated
  single-tenant on the cloud of your choice (Akamai, AWS, Azure, GCP, Equinix),
  or self-hosted on any Kubernetes. Every deployment surface speaks the same
  policies and shares one control plane.
- **Reach private backends without exposing them** — Cloud-native private
  networking — PrivateLink (AWS), Private Link (Azure), Private Service Connect
  (GCP) — for backends that speak it, plus a WireGuard tunnel agent for
  everything else. Outbound-only. No inbound firewall rules. No public IP
  needed.
- **Migrate without rewriting** — Routes, policies, env vars, API keys,
  dashboards — they all follow the project. Promote a managed-edge project to
  dedicated when traffic justifies it. Move dedicated to self-hosted when
  sovereignty does. Same code, new substrate.

## Reach private backends without opening a single inbound port

Drop the tunnel agent into your private network. It dials out to Zuplo over
WireGuard. The gateway routes to your private services using a `service://` URL
— no public IP, no VPN concentrator, no quarterly firewall ticket.

**Tunnel agent · Docker**

```bash
# Run anywhere your private backend can be reached:
docker run -d --name zuplo-tunnel \
  -e TUNNEL_TOKEN=$TUNNEL_TOKEN \
  zuplo/tunnel:latest

# In Zuplo, route to the private service:
#   url: service://orders.internal:8080
# - No inbound firewall rules
# - No public IP on the backend
# - Outbound WireGuard only
# - Multiple replicas → HA + horizontal scale
```

**Cloud-native private connectivity**

```yaml
# AWS PrivateLink — gateway → VPC endpoint
backendUrl: https://vpce-0a1b2c3d.execute-api.us-east-1.vpce.amazonaws.com

# Azure Private Link — gateway → private endpoint
backendUrl: https://orders-api.privatelink.azurewebsites.net

# GCP Private Service Connect — gateway → PSC endpoint
backendUrl: https://orders.psc.acme.internal

# All require zero inbound firewall rules.
# All inherit the same policies (auth, rate limit, logging).
```

Supported authentication methods for backend connections: AWS IAM, Azure AD, GCP
IAM / IAP, mTLS certificates, Bearer / shared secret, and outbound-only
WireGuard.

## Same policies, anywhere they need to run

- **One control plane across every deployment surface** — Other gateways treat
  "edge," "self-hosted," and "dedicated" as different products with different
  runtimes and different policy syntaxes. Zuplo treats them as deployment
  options for one project — your policies travel.
- **WireGuard tunnel agent** — Drop the `zuplo/tunnel` container into any
  private network. It establishes an outbound, authenticated WireGuard
  connection to Zuplo. No inbound firewall rules, no public IP, no VPN
  concentrator to maintain. Each tunnel handles millions of requests per minute.
- **First-class cloud auth integrations** — Forward to AWS Lambda with AWS IAM.
  Forward to Azure App Service with Azure AD client credentials. Forward to a
  GKE workload with GCP IAM / Identity-Aware Proxy. Forward to anything with
  mTLS. All as policies, not custom code.
- **AccuWeather scale, on Akamai Connected Cloud** — AccuWeather migrated from
  Apigee to Zuplo on Akamai Connected Cloud — modern developer portal,
  programmable edge caching, complete API governance, serving over one billion
  users. Akamai CDN, Global Traffic Manager, and Origin IP ACL enforce edge-only
  origin access.

## What teams use this for

**"We acquired a company. Their APIs are on a different cloud."** Add their
backends to your existing Zuplo project — one route per service, each with its
own backend URL. AWS Lambda over PrivateLink, GCP Cloud Run over PSC, on-prem
over a WireGuard tunnel. One developer portal. One set of API keys. One control
plane.

**"Compliance says data has to stay on our infrastructure."** Run Zuplo
Self-Hosted on your Kubernetes cluster via the Helm chart. Two flavors: Hybrid
(gateway on your infra, shared services from Zuplo) or Full Self-Hosted (every
component on your infra, no external dependencies). Same policies, your data
plane.

**"We're migrating from on-prem to cloud — but we're 18 months out."** Run the
gateway on edge or dedicated today. Point routes at on-prem services through a
WireGuard tunnel. As each service migrates to the cloud, swap its backend URL —
clients never notice. Traffic-split incrementally for cautious cutovers.

**"We need single-tenant for compliance, but not on-prem."** Managed Dedicated —
Zuplo provisions and operates a single-tenant instance on Akamai Connected
Cloud, AWS, Azure, GCP, Equinix, or TerraSwitch. Hardware isolation, your
cloud's network, our operations team.

## FAQ

**Can I run an API gateway on AWS, Azure, GCP, or my own data center?** Yes.
Zuplo offers three deployment models: Managed Edge (serverless across 300+ data
centers worldwide), Managed Dedicated (single-tenant Zuplo running on AWS,
Azure, GCP, Akamai Connected Cloud, Equinix, or TerraSwitch), and Self-Hosted
(Helm chart on any Kubernetes cluster, on-prem or in any cloud). All three share
the same control plane, so policies, routes, and analytics work the same
regardless of where the gateway runs.

**Can one API gateway route requests to multiple clouds?** Yes — and most modern
API platforms need this. With Zuplo, one route can proxy to AWS Lambda, the next
to GCP Cloud Run, the next to Azure App Service, the next to an on-prem service
over a WireGuard tunnel. Auth, rate limits, and observability stay consistent
across them. You can move backends between clouds without touching the public
API surface.

**How do I avoid getting locked into one cloud's API gateway?** The trick is to
put a portable layer in front of cloud-native gateways. AWS API Gateway, Azure
APIM, and Google Apigee bind your config to one cloud — moving means rewriting.
Zuplo's gateway is the same product on every cloud, with config in your Git repo
as standard OpenAPI plus TypeScript. Migrating from edge to dedicated, or
between clouds, doesn't require rewriting your policies or re-issuing API keys.

**How does Zuplo connect to private backends in my VPC?** Two paths depending on
your setup. For backends that already speak cloud-native private networking,
Zuplo connects via AWS PrivateLink, Azure Private Link, or GCP Private Service
Connect. For backends with no public ingress, run Zuplo's WireGuard tunnel agent
in your private network — it dials out to the gateway, no inbound firewall rules
needed. Each tunnel handles millions of requests per minute and supports HA via
replicas.

**Can I deploy an API gateway on my own Kubernetes cluster?** Yes — Zuplo
Self-Hosted ships as a Helm chart that runs on any Kubernetes cluster (EKS, AKS,
GKE, OpenShift, on-prem). Two modes: Hybrid (gateway runs in your cluster,
shared services from Zuplo) and Full Self-Hosted (every component runs in your
cluster, no Zuplo-side dependencies). Choose the one that fits your
data-residency posture.

**How does Zuplo on Akamai Connected Cloud work?** Zuplo runs on Akamai
Connected Cloud compute, fronted by Akamai's CDN edge for caching, DDoS
protection, and edge security. Akamai's Global Traffic Manager routes traffic to
the nearest healthy Zuplo region; origin ACLs restrict access to Akamai edge IPs
only. AccuWeather serves over a billion users this way. It's the dedicated path
most enterprise customers pick when they need single-tenancy plus a global CDN
in one stack.

**Can I move from managed cloud to dedicated or self-hosted later?** Yes — and
this is the whole point. Your routes, policies, env vars, API keys, and
observability are part of the project, not the deployment surface. Start on
Managed Edge to validate, promote to Managed Dedicated when compliance kicks in,
or migrate to Self-Hosted on Kubernetes when you need full data isolation. None
of it requires rewriting your gateway code.

**What's the best multi-cloud or hybrid API gateway?** Look for: same product on
every cloud, config that travels between deployment models, private-network
connectivity via tunnels or cloud-native endpoints, and one control plane for
governance and observability across regions. Zuplo is one of the few gateways
built for this — managed edge, single-tenant dedicated, and self-hosted
Kubernetes all running the same engine. Talk to a solutions engineer about your
topology.

## Next steps

- Start a free account: https://portal.zuplo.com/signup
- Read the docs: /docs/articles/hosting-options
- Talk to a Solutions Engineer: /schedule-call