Cloud Platform Engineering · Chapter 5 of 9
Edge, DNS and delivery — what these services are before what they are called
Authoritative DNS, CDNs, anycast and the firewall layer: what each one actually does, then what each provider calls it, then where the mapping is a lie.
A table of equivalent product names is useless if you do not already know what the products do. So this chapter does the concepts first — and if you know them, skip to the table.
What these things actually are
Managed DNS is authoritative nameservers as a service. You delegate your domain to the provider, and it answers queries for it. The reason to use a cloud provider's rather than any other is routing policy: answering the same query differently by geography, by weight, by latency, or by whether a health check is currently passing. That last one makes DNS part of your failover story, which is also why DNS caching and TTLs become an availability concern rather than a detail.
Private DNS zones are the same thing for names that should only resolve inside your network. Every provider has this and it is where a surprising share of hybrid-connectivity problems actually live — a workload that cannot reach an on-premises service usually resolves the name to the wrong address rather than failing to route.
A CDN caches your content at points of presence near users. The obvious benefit is latency; the less obvious and often larger ones are origin offload — your servers stop serving the same bytes repeatedly — and terminating TLS at the edge. TLS, Transport Layer Security, is the encryption behind the padlock in a browser; setting it up costs an extra round trip, so doing it at a nearby edge rather than at your own servers removes that delay from every new connection.
Anycast is announcing the same IP address from many locations and letting routing send each user to the nearest one. It is what makes a single global entry point possible. Without it, a globally distributed service needs DNS to hand different users different addresses — which works, but inherits every DNS caching problem.
A web application firewall and DDoS protection are different layers and get conflated constantly. A WAF inspects HTTP requests and blocks ones matching rules — injection attempts, known bad patterns, rate limits per client. DDoS protection absorbs volume at layers 3 and 4, before anything gets far enough to be inspected. A WAF will not save you from a volumetric attack, and DDoS protection will not stop one well-formed malicious request.
Where the mapping stops being a translation
GCP folds global anycast into the load balancer itself. Its global load balancer types are anycast by default, so a single external IP serves users worldwide and routes them to the closest healthy backend. On AWS the equivalent is two products: regional load balancers, with Global Accelerator in front providing the anycast entry point. The architectures end up similar; the number of moving parts and the failure modes do not.
Azure's Front Door is one product doing three jobs — content delivery, anycast entry and layer-7 routing. That is why it appears in three rows of the table. It makes the simple case simpler and the comparison harder, because “what is the Azure equivalent of CloudFront” has a technically correct answer that is also incomplete.
And one difference that is not architectural at all: Route 53 is also a domain registrar — you can buy the domain there. Cloud DNS is not; you register elsewhere and delegate. It sounds trivial until you are working out which team in a large company controls the domain, which turns out to be a load-bearing organisational question during any migration.
Check yourself