Akamai CDN Architecture: DNS, Tiered Caching, and SureRoute
- Author
- Prathamesh Patil
- Length
- 1767 words
- Read
- 8 min
Akamai does not publish one universal request path that chains every product together. Its public documentation describes several related but distinct systems: Edge DNS answers authoritative DNS queries, Global Traffic Management steers DNS answers toward an appropriate data center, Tiered Distribution serves cacheable objects through parent servers near an origin, and SureRoute evaluates paths from an edge server to an origin for non-cacheable traffic.
That distinction matters. Treating all four systems as stages in one pipeline creates an architecture Akamai has not documented. This teardown instead follows the boundaries in the product documentation and marks the points where deployment-specific configuration decides which subsystem participates.
Key takeaways
- Edge DNS is an authoritative DNS platform whose Anycast service is distributed across networks and continents.
- Global Traffic Management is DNS-based steering. A resolver follows a CNAME to GTM, which applies configured policy rules before returning addresses for a selected data center.
- Tiered Distribution applies to cacheable content. Parent servers near the origin can answer other Akamai servers without every miss reaching the origin.
- SureRoute addresses the edge-to-origin path for non-cacheable content. It races available routes with a test object and keeps the best-performing result until another race.
- These are composable capabilities, not proof of a single private mapping algorithm or a universal packet path.
Research basis
This article is deliberately limited to four Akamai technical references: the GTM request flow, Edge DNS architecture, Tiered Distribution behavior, and SureRoute behavior. The documents explain product-visible behavior and configuration. They do not expose a complete internal control plane, cache-index implementation, or proprietary edge-selection algorithm.
The safest reading is therefore behavioral: explain what each service receives, what it returns, and which failure or performance problem it is designed to address. Where the documents leave an implementation private, this article leaves it private too.
Four systems, not one request chain
The public product boundary is easier to understand as separate decisions. DNS authority and DNS traffic management happen before a client connects. Cache handling and origin-path selection happen after a request reaches an Akamai delivery server, and the applicable property behavior depends on whether content is cacheable.
The diagram is a boundary map, not a claim that every DNS answer uses GTM or that every delivery request uses both origin features. Edge DNS can serve zones without GTM. GTM can return addresses for an Akamai data center, a public cloud, or an enterprise origin. A delivery property can enable Tiered Distribution, SureRoute, both, or neither according to its rules.
Edge DNS provides resilient authority
Akamai describes Edge DNS as a cloud-based authoritative DNS service designed to improve resolution availability, performance, and resilience. Its name servers are distributed across multiple points of presence and multiple networks. That distribution provides both geographic and network-level redundancy.
Edge DNS uses IP Anycast to present one logical name server through multiple physical name servers on different networks and continents. The cited page does not guarantee that a query reaches the geographically closest server or claim that measured latency is a BGP decision input. This is a network-nearest vs geographic distinction, not a product guarantee.
The documentation also says Edge DNS uses Akamai's proprietary DNS implementation rather than BIND. That supports a narrow statement about the software boundary. It does not reveal how zone data is partitioned, synchronized, or stored internally, so those mechanisms should not be reverse-engineered from the word “proprietary.”
Global Traffic Management steers DNS answers
The GTM documentation presents a standard DNS interaction with a traffic-management decision in the middle. A browser asks its configured resolver for an address. The resolver contacts the site's authoritative name server. That authority returns a CNAME pointing toward GTM, and the resolver then asks GTM for an answer. GTM applies configured policy rules, then returns addresses for an appropriate data-center location.
The selected destination is not necessarily an Akamai delivery site. Akamai explicitly lists an Akamai data center, a public cloud provider, and an enterprise origin as possible destinations. GTM is therefore best understood as DNS-based global load balancing, not as evidence for a CDN-wide edge-map data structure.
The phrase “most appropriate” is intentionally policy-aware. DNS answers can reflect configured rules and observed health. The documentation does not reduce the decision to shortest AS path, lowest latency, or geographic distance, and neither should an architecture explanation.
Tiered Distribution handles cacheable origin fetches
Tiered Distribution changes where an Akamai server retrieves cacheable content after it cannot serve the object locally. Instead of contacting the customer origin directly, it can retrieve the object from another server tier closer to that origin. Akamai designates servers near the origin as parents; those parents cache content and serve it to other servers on the platform.
This hierarchy can reduce the demand placed on the origin because requests converge on a smaller parent layer rather than every delivery server fetching independently. It can also shorten retrieval compared with a direct origin fetch when the parent has the object.
The scope is crucial: the behavior is for cacheable content. It does not establish a universal hierarchy for all requests, and the public page does not document a global cache index, constant-time lookup, push-pull invalidation bus, or a fixed number of cache tiers.
The documented Global and Local parent-map options expose a practical tradeoff. A broader parent set favors proximity to users, while a smaller regional set can increase the chance that requests converge on a cached object and improve origin offload. The right choice depends on whether end-user latency or origin offload is the stronger objective.
SureRoute evaluates non-cacheable origin paths
SureRoute solves a different problem. It tests routes between an Akamai edge server and the customer origin, records the best-performing route, and keeps alternatives available for potential failures. The feature is intended for the origin leg, not client-to-edge Anycast selection.
For performance optimization, a non-cacheable end-user request can trigger a later race. The user receives the requested content first. SureRoute then sends separate requests for a small test object over the available routes, records the winner, and uses that route for future origin requests until another race refreshes the result.
The test object is designed to measure network-route performance rather than application work. Akamai recommends serving it immediately and avoiding database or other back-end processing. This keeps the race focused on the network path.
Tiered Distribution and SureRoute can coexist because they target different content classes: cached delivery through parents versus non-cacheable retrieval along an evaluated edge-to-origin route. That is a product-level complement, not evidence that one feature calls the other in a fixed sequence.
Failure domains
The documents reveal several distinct failure boundaries.
Authoritative DNS availability. Edge DNS distributes physical name servers across networks and locations behind a logical Anycast service. A network or site problem can change which instance routing reaches. Operators still need correct zone configuration and delegation because infrastructure diversity cannot repair bad DNS data.
Destination health. GTM can account for data-center health and policy when answering DNS. DNS caching means clients and resolvers may continue using an earlier answer until it expires, so steering is not the same as per-request proxy failover.
Cache-parent reachability. Tiered Distribution adds a parent hop for cacheable misses. That reduces origin fan-out, but the parent layer becomes part of the retrieval path. Property behavior and parent-map selection therefore belong in failure testing.
Origin-route quality. SureRoute periodically re-evaluates edge-to-origin paths. Its race result can respond to changing Internet conditions, while the customer origin and test object must remain reachable and correctly configured.
These boundaries should be tested separately. A DNS incident, unhealthy destination, cold parent cache, and degraded origin route have different symptoms and recovery controls.
Results and tradeoffs
The architecture favors scoped mechanisms over one global answer.
- DNS distribution improves authoritative resilience, but Anycast wording must remain routing-aware.
- GTM can steer toward healthy destinations, but DNS caching makes the control loop coarser than request-by-request routing.
- Parent caching can reduce origin demand, but map choice trades broader proximity against stronger request convergence.
- Route racing can improve the origin leg for non-cacheable traffic, but it adds test traffic and requires a deliberately simple origin object.
The public sources support these qualitative effects. They do not support universal latency reductions, cache-hit percentages, fixed capacity limits, or an undocumented consensus mechanism. A production evaluation should measure those outcomes for the property's traffic mix and configuration.
What I would steal
The most reusable idea is separation by decision scope.
First, keep DNS authority separate from traffic steering. An authoritative platform should remain understandable even when global load-balancing policy is absent. Second, treat cacheable and non-cacheable origin traffic as different optimization problems. Parent caching reduces repeated object retrieval, while route evaluation helps traffic that must reach the origin. Third, make every optimization observable at its own boundary: DNS answer, selected destination, parent-cache outcome, and origin-route result.
That separation produces better incident questions. Instead of asking whether “the CDN routing algorithm” is broken, an operator can ask whether authority is answering, GTM is returning an intended destination, a cacheable miss is reaching a parent, or a non-cacheable origin path has degraded.
FAQ
Does Akamai use Anycast or DNS-based routing?
Both appear in the cited documentation, but at different boundaries. Edge DNS uses IP Anycast for its distributed authoritative name-server service. GTM uses DNS responses and policy to steer a resolver toward an appropriate data center.
Does Anycast always select the closest Akamai location?
No such guarantee follows from the Edge DNS page. Anycast exposes one logical service through physical name servers on multiple networks and continents, but the page does not promise geographic proximity.
What does GTM return?
GTM returns addresses for servers at a selected data-center location. The destination can be an Akamai data center, a public cloud, or an enterprise origin, depending on the configured service and policy.
When does Tiered Distribution apply?
It applies to cacheable content. A delivery server can retrieve an object from a parent server near the origin rather than sending every applicable miss directly to the origin.
What problem does SureRoute address?
SureRoute evaluates routes from an Akamai edge server to the customer origin for non-cacheable content. It records a best-performing path from periodic races and retains alternatives for potential request failures.
Are Akamai's internal mapping and cache algorithms public?
The cited pages document observable product behavior and configuration, not a complete internal mapping service, cache-index design, or control-plane protocol. Those internals should be treated as undocumented unless Akamai publishes a source that describes them.
