What AWS Taught Me About the Future of European Aviation

From cloud networks to airline networks

Recently I watched an AWS video about how they'd rebuilt part of their data center network using graph theory. Routers and optical cables are a long way from airports and aircraft, but the whole time I kept thinking about airline networks.

I'd just come out of an IATA course on Network, Fleet & Schedule Planning in Miami, and had spent the better part of a week with hubs, waves, and connection banks turning over in my head. So while AWS talked about routers and packets, I saw airports as nodes and flights as the edges between them. The parallel was impossible to unsee, and it's been bothering me ever since.

Underneath the engineering sits a question every airline planner already lives with: how do you move a lot of traffic through constrained infrastructure when demand is high and disruption is guaranteed? AWS moves packets. Airlines move passengers, bags, and cargo. Both run on nodes, edges, and the painful arithmetic of what happens when one of them fails.

Replacing fat with flat

Most data centers have used a fat-tree topology: traffic climbs up through layers, crosses a core, and comes back down. It's tidy and easy to reason about. It also concentrates risk. As traffic grows, the upper layers become bottlenecks, and the usual fix is just more hardware.

AWS went the other way. Instead of adding hierarchy, it asked whether the network needed less of it. The result is what they call a Resilient Network Graph: a flatter, quasi-random topology with many alternative paths and far less dependence on central layers. They report fewer devices, higher throughput, and lower power draw.

The trick isn't randomness for its own sake. A truly random physical network would be a nightmare to cable and route. AWS paired mathematical path diversity with real engineering to make it buildable. A single packet might not take the shortest visible route, but the network as a whole runs better because traffic spreads out and no single point carries everything.

The shortest path, in other words, isn't always the best one. And airline networks are graphs too.

Why this is really a European question

Airports are nodes, flights are edges, and everything moving through them is flow. Hub-and-spoke is powerful because it manufactures connectivity: a passenger from Geneva reaches Singapore or Cape Town by funnelling through something bigger. But the same structure concentrates risk. When a hub is disrupted, the damage doesn't stay on one flight. It ripples through connection waves, aircraft rotations, crew duties, and the hotel bill at the end of the day.

Hubs aren't the problem. The problem is that airline systems still think locally: protect this connection, repair this passenger, usually after the disruption has already happened. Europe is an unusually good place to think differently, because it isn't a continent of lone mega-hubs. The Lufthansa Group alone spans Frankfurt, Munich, Zurich, Vienna, Brussels, and Rome. Treated traditionally, those are six separate funnels. Treated as a graph, they're one routing fabric.

So the Geneva passenger bound for Singapore doesn't have a single path. They have several: via Zurich, Munich, Frankfurt, or Brussels, depending on schedule, fare, and whether the connection actually holds together on the day. A cargo shipment has even more freedom, including a truck to a different hub. The graph already exists. We just don't operate it as one.

The provocative version

My first instinct was deliberately provocative: sell someone a ticket from A to B, and only tell them on the morning of departure which hub they'll route through.

For most travellers, that won't fly. A family with kids doesn't want a mystery connection, a business traveller doesn't want uncertainty, and someone who paid for a specific seat in a specific cabin doesn't want it abstracted away an hour before boarding. But for price-sensitive passengers, the ones who already accept a long layover or an odd routing to save money, it might be exactly the trade they'd take: a cheaper fare in exchange for letting the airline choose the hub. The idea isn't wrong. It's just not for everyone.

The quieter version works for everyone else. The passenger sees a normal, fixed itinerary. The airline keeps a live graph of feasible backup paths running underneath it. The shift is from reactive repair toward something closer to predictive control: knowing the alternatives before the connection breaks, not scrambling after.

Start with cargo

I once asked a cargo pilot whether he preferred flying cargo or people. His answer came back in classic dry German humour: "Cargo kotzt nicht, Cargo motzt nicht." Cargo doesn't puke and cargo doesn't complain.

Crude, but strategically on point. Cargo customers care less about the emotional journey and more about the promise: this shipment, to here, by then, handled this way, at this reliability and price. That's almost exactly the AWS packet analogy: the shipment is the flow, the network is the graph, the SLA is the contract. For general cargo, the customer often doesn't care whether the box goes via Frankfurt, Vienna, or a truck to Brussels, as long as it arrives on time and intact.

Which makes for an honest pilot project. Take general cargo, carve out the sensitive stuff, pick one origin-destination corridor, and let a routing engine choose between feasible hub paths. Then measure it against business as usual: SLA hit rate, cost per kilo, hub load, missed connections, CO2, and how often a human had to step in. It's aviation's version of testing dynamic routing somewhere low-stakes before you let it near passengers.

What the engine actually does

It doesn't shuffle people or cargo at random. It generates the feasible paths, discards the impossible ones, scores what's left, and picks the route with the best total value to the network, not just the shortest hop.

Picture someone booked Geneva → Frankfurt → Singapore. The inbound to Frankfurt is running late, the connection window is closing, and the onward flight to Singapore is the last one that day. Rather than wait for the misconnect, the engine is already weighing Geneva → Zurich → Singapore and Geneva → Munich → Singapore, scoring each on arrival time, seat availability, baggage, and downstream cost. The winning option may be longer on paper. It's the one that gets the passenger there and saves you the cascade.

The part that's actually strategic

Airlines are squeezed from every direction: congested airports, volatile weather, ATC limits, late aircraft, crew constraints, fuel, sustainability. Under that kind of pressure a rigid network is expensive, and a resilient one starts to look like an advantage. For a multi-hub group, the opportunity isn't flying more. It's using what already exists more intelligently, treating those six hubs as a single routing graph rather than six competing ones. The same logic extends to Air France-KLM, IAG, and any cargo operator combining air and road.

AWS didn't win by making cables marginally better. It won by questioning the shape of the network it had inherited. The next real step in European aviation probably won't be a new aircraft or a new loyalty tier. It'll be seeing the group for what it already is, a graph, and starting to route accordingly. Once you see it that way, you can't unsee it.