Akamai Dedicated Architecture
Zuplo integrates with Akamai Connected Cloud to provide a secure, highly available API platform. This document provides a high-level architecture overview of how Zuplo deploys within the Akamai ecosystem, leveraging Akamai's edge platform for global traffic management and secure connectivity.
Overview
A typical Zuplo deployment on Akamai Connected Cloud consists of the following components:
- Akamai CDN (Edge Servers) - Akamai's globally distributed edge network handles incoming client requests, providing caching, DDoS protection, and edge security.
- Akamai Global Traffic Manager (GTM) - Routes traffic to the appropriate Zuplo Gateway instances based on geographic location, health status, and load balancing policies.
- Zuplo Gateway - Deployed on Akamai Connected Cloud, the gateway handles authentication, authorization, rate limiting, and request routing. A shared secret header or mTLS ensures only your Akamai property can reach the gateway.
- Backend Services - Your origin servers can be hosted on Akamai compute, customer VPCs, on-premise data centers, or public cloud providers.
This architecture provides a seamless, first-class API management solution that integrates natively with Akamai's infrastructure.
Architecture
The following diagram shows how client requests flow through the Akamai platform to Zuplo and your backend services:
Request flow
- Client to Akamai CDN - Clients send requests to your API domain. Akamai's edge servers receive the request at the nearest point of presence (PoP).
- CDN to GTM - The edge server forwards the request to Akamai Global Traffic Manager, which determines the optimal Zuplo instance to handle the request.
- GTM to Zuplo - GTM routes the request to a Zuplo Gateway. The gateway accepts the request only if it carries your shared secret header or presents your mTLS client certificate.
- Zuplo to Backend - The Zuplo Gateway processes the request (applying policies, authentication, rate limiting) and forwards it to your backend services.
Akamai Global Traffic Manager
Akamai GTM provides intelligent traffic routing with the following capabilities:
- Geographic routing - Route requests to the nearest regional gateway for low latency
- Automatic failover - Redirect traffic when a data center or gateway becomes unavailable
- Load balancing - Distribute traffic across multiple gateway instances using weighted round-robin or performance-based routing
- Health monitoring - Monitor the health of Zuplo gateway instances using liveness tests and remove unhealthy targets from rotation
GTM uses liveness tests to continuously monitor the health of your Zuplo deployments. When a gateway fails health checks, GTM automatically routes traffic to healthy instances, providing seamless failover.
Securing the connection from Akamai to Zuplo
Every request that reaches the gateway must prove it came from your Akamai property. We recommend one of these:
- Shared secret header - Akamai adds a secret header to every request it forwards, using the Modify Incoming Request Header behavior. The gateway rejects requests without it.
- Mutual TLS - Akamai presents a client certificate from its mTLS Origin Keystore, and the gateway rejects connections without one.
You can add Origin IP ACL as an extra layer that limits connections to Akamai's edge IP addresses. Don't use it on its own: the Origin IP ACL ranges are shared by every Akamai customer, and Akamai states that it "isn't a substitute for authentication".
For setup steps for each option, see Securing Zuplo from direct access.
All traffic between Akamai edge and origin uses TLS encryption.
Multi-region deployment
Deploy your Zuplo Gateway to multiple regions on Akamai Connected Cloud for high availability, lower latency, and disaster recovery. GTM intelligently routes traffic to the closest healthy region.
Benefits of multi-region deployment
- Low latency - Users connect to the nearest regional gateway
- High availability - Regional failures don't affect global availability
- Disaster recovery - GTM automatically fails over to healthy regions
- Compliance - Meet data residency requirements by deploying to specific regions
GTM failover configuration
Configure GTM properties with appropriate settings:
- Routing delay - Time to wait before routing away from an unhealthy data center
- Recovery delay - Time to wait before routing back to a recovered data center
- Health check intervals - Frequency of liveness tests against gateway endpoints
Backend connectivity
Zuplo Gateway supports multiple methods for securing connections to your backend services. Most authentication methods work regardless of where your backend is hosted, giving you flexibility to choose the approach that best fits your security requirements.
Authentication methods
The following authentication methods can be used to secure connections between Zuplo and your backend services. For complete documentation, see Securing your backend.
| Method | Description |
|---|---|
| Shared Secret / API Key | Add a secret header to requests that only the gateway knows. Simple to implement and widely used by companies like Stripe and Supabase. |
| Zuplo JWT Service | Issue signed JWTs that your backend validates using Zuplo's JWKS endpoint. Provides cryptographic proof that requests originate from your gateway. |
| mTLS (Mutual TLS) | Certificate-based authentication where both gateway and backend present certificates. Provides zero-trust security for enterprise requirements. |
| Cloud Provider IAM | Use AWS IAM, GCP Identity-Aware Proxy, or Microsoft Entra ID to authorize requests. No credentials to manage - uses federated identity. |
| Secure Tunnel (VPN) | WireGuard-based tunnel for backends that can't be exposed to the internet. Useful for on-premise or bare-metal deployments. |
| Private Network | VPC peering, PrivateLink, or Transit Gateway for private connectivity without traversing the public internet. |
Recommendations by backend location
While most authentication methods work anywhere, some approaches are better suited for specific scenarios:
| Backend Location | Recommended Methods | Notes |
|---|---|---|
| Akamai Connected Cloud | Shared secret, Zuplo JWT, mTLS | All methods work well; choose based on your security requirements |
| AWS | AWS IAM (federated identity), mTLS, shared secret | IAM provides credential-free auth; works with Lambda, API Gateway, ECS, EKS |
| GCP | GCP Identity-Aware Proxy, GCP Service Auth, mTLS | IAP provides zero-trust access to Cloud Run, GKE, and Compute Engine |
| Azure | Microsoft Entra ID Service Auth, mTLS, shared secret | Microsoft Entra ID integrates with App Service, Functions, and AKS |
| On-Premise / Data Center | Secure tunnel, mTLS, shared secret | Tunnel allows private connectivity; mTLS provides strong authentication |
| Third-Party APIs | Shared secret, API keys, mTLS | Use whatever the third-party API supports |
Choosing an authentication method
Consider these factors when selecting an authentication method:
- Simplicity - Shared secrets are easiest to implement and work everywhere
- Security - mTLS and cloud IAM provide the strongest authentication
- Credential management - Federated identity (AWS/GCP/Azure IAM) eliminates credential rotation
- Network isolation - Private networking and tunnels keep traffic off the public internet
- Compliance - mTLS is often required for enterprise and regulated environments
CDN configuration
For detailed instructions on configuring Akamai CDN properties for your Zuplo deployment, see Setting up Akamai CDNs. This guide covers:
- Property hostname configuration for Zuplo Gateway and developer portal
- Origin server settings with host header forwarding
- Caching behaviors for API responses
Next steps
- Setting up Akamai CDNs - Configure Akamai CDN properties for your deployment
- Networking - Learn about networking options for managed dedicated deployments
- Architecture - General managed dedicated architecture overview