--- 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-10-08" --- # 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. ## Deployment topology: one control plane, any cloud Three deployment modes share one control plane: - **Managed Edge** — default for self-serve. 300+ edge POPs, global anycast. - **Managed Dedicated** — single-tenant on your cloud. - **Self-Hosted** — Helm on your Kubernetes. The gateway runs the same policies anywhere: auth, rate limit, cache, observability. Backends can be on any cloud, with any auth: | Backend | Cloud | Connectivity | Auth | | ------------- | ------- | ----------------------- | -------- | | Order service | AWS | PrivateLink | AWS IAM | | Identity API | Azure | Private Link | Azure AD | | Inventory API | GCP | Private Service Connect | GCP IAM | | Mainframe API | On-prem | WireGuard tunnel | mTLS | 3 modes (edge, dedicated, self-hosted) · Any backend (private or public) · One plane (policies travel) ## 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 auth: AWS IAM, Azure AD, GCP IAM / IAP, mTLS certificates, Bearer / shared secret, 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. ## Frequently Asked Questions ### 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 for Free](https://portal.zuplo.com/signup) — free Zuplo project, route to any cloud's backend in minutes, and move it to a different deployment surface later without rewriting a thing. - [Talk to a Solutions Engineer](/schedule-call) - [Read the docs on hosting options](https://zuplo.com/docs/articles/hosting-options)