31 AUG 2026 — AWS has described the network design now standard in its data centres: a flat, deliberately near-random topology called Resilient Network Graph, using 69 per cent fewer routers and 40 per cent less network power. Asked whether customers see the saving, the answer was effectively no.
What the design actually is
Conventional data centre networks are hierarchical — the fat-tree design — and routing protocols such as BGP and OSPF compute a shortest path between any two points. RNG abandons both. The fabric is flat and wired in a deliberately near-random pattern, which produces many roughly equivalent routes between any pair of endpoints rather than one best one.
That breaks shortest-path routing by design, so AWS replaced it. SIDR, for Scalable Intent-Driven Routing, handles the control plane. Spraypoint handles forwarding: it sprays traffic simultaneously across neighbouring routers and uses designated waypoints to steer packets to their destination, which AWS says yields nearly twice as many independent paths between routers as standard shortest-path techniques.
Note the two numbers are not the same claim. The topology offers a very large number of possible routes; the protocol delivers roughly double the independent paths a conventional network would use. The second figure is the one with an engineering meaning, because an independent path is one that fails separately.
Why randomness beats structure here
A near-random graph sounds undesigned, but it is the opposite.
Structured topologies such as fat-tree or Clos are easy to reason about and have predictable failure behaviour, which is why they became standard. Their weakness is that the structure itself concentrates risk: losing a specific link or switch removes a specific, identifiable set of paths, and the network must be over-provisioned to survive that.
A near-random graph has no such structure to lose. With many roughly equivalent paths between endpoints, a link failure removes a small fraction of capacity rather than a tier of it, so the fabric needs less redundant hardware to reach the same availability.
AWS puts a number on that: 69 per cent fewer routers in the aggregation fabric, alongside 33 per cent higher throughput and 40 per cent lower network equipment power. Those three figures are one result. The efficiency comes from needing less equipment, not better equipment, and the router count is the cause with the power figure as its consequence.
The saving has not reached the bill
Asked whether the benefit had been retained rather than passed on, AWS's answer was effectively yes.
That is a straightforward commercial position and it is unusual to see it stated. Infrastructure efficiency gains at hyperscale are ordinarily invisible in both directions: customers cannot verify them and providers do not discuss them. Here the provider has quantified a saving and confirmed it kept it.
The caveat for any buyer is that the 40 per cent figure is specifically network equipment power, not data centre power. Networking is one line in that budget, well behind compute and cooling, so the effect on a total energy bill is far smaller than the headline. AWS says network equipment power and is precise about it; the number will be repeated without the qualifier.
The accompanying paper puts cost reduction against legacy architectures at 9 to 45 per cent, and that range is worth more attention than the single figures. A spread that wide means the benefit depends heavily on which legacy design is being replaced and at what scale, which is the honest shape of an infrastructure claim and the part that gets dropped first.
The forward-looking sentence is about pricing
Matt Rehder, vice president of global network engineering, and Stephen Callaghan, senior principal network development engineer, said AWS is moving towards flat-rate pricing for new network products.
For anyone operating in this region, that sentence about pricing matters more than the topology. Cloud networking has long been priced by the gigabyte moved. Data egress is the charge that most distorts architecture, keeping workloads inside one provider not because moving them is hard, but because moving the data out is metered. Flat-rate pricing, if it extends to egress, changes that calculation.
Read it carefully though. The statement is about new network products and a direction of travel, not a change to existing egress rates. Regulatory pressure in Europe has already forced waivers for customers leaving a provider entirely, which is a narrower remedy than flat pricing, and nothing here says the general rate is moving.
Why the ASEAN context sharpens this
Two facts make network cost more consequential here than in North America or Europe.
The region is a set of separate markets rather than one, so an application serving Singapore, Jakarta, Manila and Ho Chi Minh City typically spans multiple regions and availability zones, and inter-region traffic is billed. An architecture that would be single-region in the United States is multi-region here by geography alone.
Data residency rules add to it. Where a regulator requires certain data to remain in-country, the workload splits and the split generates cross-border traffic that a compliance requirement created rather than a design choice. Those bytes are charged at the same rates.
So a shift to flat-rate network pricing would land harder in Southeast Asia than in markets where the same application fits in one region — and it would land on architectures that were shaped by the metered pricing in the first place, which is not something a price change reverses quickly.
Why nobody heard about it
SIDR was presented publicly at re:Invent in 2023 and again in 2024, and the RNG paper was published without mentioning it. The design has been running in production since last year, in data centres including Spain and Germany, and is now the default for most AWS workloads.
The argument that AWS has undersold this is fair, and there is a less flattering reading available alongside it. Infrastructure that works is invisible, and a provider has little to gain from explaining a design its customers cannot choose, opt out of, or verify. Publishing the paper without mentioning the protocol that makes it work looks like a deliberate decision rather than an oversight.
View author profile → · Editorial policy
