Architecture
Zuplo on Akamai
Zuplo runs natively on Akamai Connected Cloud, on the same infrastructure as Akamai's CDN and security products. Traffic flows from Akamai's edge through GTM and App & API Protector before reaching Zuplo. Below covers the deployment model, request flow, global routing via GTM, and how Akamai authenticates to Zuplo's origin.
Deployment model
Zuplo is not a third-party gateway that connects to Akamai via API. It runs as a managed service inside Akamai Connected Cloud — on the same private backbone as the CDN and security products. Traffic between the Akamai edge and Zuplo never crosses the public internet.
Single-vendor stack
Both edge and compute run on Akamai infrastructure. No AWS, Azure, or GCP dependency in the data path.
Multi-region by default
Zuplo deploys across Akamai's global data centers. GTM routes each request to the nearest healthy region automatically.
Private backbone transit
Edge-to-gateway traffic travels over Akamai's private network, reducing latency and eliminating exposure to the public internet.
Request flow
Every request passes through Akamai's edge before reaching Zuplo. Cached responses are served at the PoP; uncached or dynamic requests proceed through the full stack.
Akamai Edge
Traffic hits Akamai's edge first. The CDN serves cached responses. App & API Protector filters DDoS, bot, and web-application attacks. GTM resolves DNS to the nearest healthy Zuplo region.
Zuplo on Akamai Connected Cloud
Validated requests flow from the edge to Zuplo, running natively on Akamai Connected Cloud. Zuplo applies authentication, rate limiting, request transforms, and routing policies.
Origin
Only policy-compliant traffic reaches your origin. The connection from Zuplo to your backend is authenticated — Akamai-originated traffic only, verified at the network or application layer.
Global Traffic Manager
Akamai's GTM sits at the DNS layer and routes every request to the nearest healthy Zuplo deployment. No client changes required — routing is transparent.
Geographic routing
DNS resolves to the nearest Zuplo deployment. Users in Europe hit a European instance; US users hit a US instance. Latency improvements of 20ms or more are typical.
- Instant region selection at DNS resolution
- Weighted load balancing across regions
- No client-side changes required
Health monitoring & failover
GTM continuously probes each Zuplo deployment. If a region fails health checks, it is removed from rotation immediately — no TTL delay, no manual intervention.
- Sub-second failure detection
- Automatic removal from DNS rotation
- Automatic recovery when health is restored
Data residency
Route EU traffic to EU-hosted Zuplo instances and US traffic to US instances. Meet GDPR and data sovereignty requirements without managing routing rules manually.
- GDPR-compliant EU data processing
- Country and region-based routing rules
- Audit trail for data locality
Active-active regions
Multiple Zuplo regions run simultaneously with no primary/secondary distinction. Any region can serve any request, and all have the same deployed configuration.
- No planned-maintenance downtime
- Independent per-region scaling
- 99.99% availability SLA
Akamai → Zuplo authentication
Zuplo's origin must only accept traffic that genuinely came from Akamai's edge — not direct calls that bypass the security stack. Four mechanisms are available; most deployments use IP allowlisting plus one additional method for defense in depth.
IP Allowlist
Zuplo's origin accepts connections only from Akamai's published edge IP ranges. Direct-to-origin attacks are blocked at the network layer.
Mutual TLS (mTLS)
Akamai presents a client certificate on every forward request. Zuplo validates the certificate before processing, ensuring only Akamai-originated traffic is accepted.
Custom Secret Header
A shared secret is configured in Akamai and validated by Zuplo on every inbound request. Requests missing or presenting the wrong secret are rejected immediately.
Auth Token 2.0
Akamai generates a cryptographically signed token for each forwarded request. Zuplo verifies the signature, ensuring the request genuinely originated from the Akamai edge.
Defense in depth: These methods work individually or in combination. IP allowlisting blocks the majority of bypass attempts at the network layer; mTLS or Auth Token 2.0 adds cryptographic verification that the traffic is genuinely Akamai-originated.