Dit jaar, tijdens re:Invent, lijkt AWS einde­lijk de onver­mij­de­lijk­heid van multi-cloud te hebben geaccep­teerd met de aankon­di­ging van een gezamen­lijk ontwik­kelde inter­con­nectie met Google Cloud. Het is een opval­lende koers­wij­zi­ging na jaren volhouden dat klanten multi-cloud niet nodig hadden. AWS schil­derde multi­cloud altijd af afschil­deren als onnodig, buiten­sporig complex en eigen­lijk een trend die achter ons ligt in plaats van een strate­gi­sche architectuur.

Jaar na jaar laten branche­rap­porten echter zien dat meer dan 85% van de organi­sa­ties al workloads draait op meerdere clouds. Nu de grootste cloud­pro­vider ter wereld een native multi-cloud inter­con­nect heeft gelan­ceerd, is dat een belang­rijk moment. Niet omdat AWS ineens innoveert op het gebied van netwerken van clouds, maar omdat het erkent wat de rest van de sector al jaren weet: multi-cloud is geen vreemde keuze of overdreven voorzorgs­maat­regel voor disaster recovery – het is de norm.

Het is beteke­nisvol, maar onder de hype blijft deze brug tussen twee clouds nog altijd ver achter bij de reali­teit van wereld­wijde, enter­prise-scale opera­ties. En daar moet de discussie nu naartoe verschuiven.

Een brug tussen twee clouds is handig, maar geen echte multi-cloud

Om eerlijk te zijn: het feit dat AWS en Google Cloud een private, hoogwaar­dige, beheerde verbin­ding bouwen, is zeker nuttig. Het verlicht een deel van de pijn die bedrijven jaren­lang hebben ervaren. Het belooft multi-cloud connec­ti­vi­teit op te zetten “binnen minuten”, met klik-en-imple­men­teer workflows in plaats van weken­lang onder­han­delen over circuits, hardware bestellen en route­ring instellen. Maar de dienst heeft één cruciale beper­king: op dit moment verbindt het alleen AWS en Google Cloud – geen Azure, geen regio­nale of soeve­reine clouds.

Een bilate­rale inter­con­nectie – zelfs als die snel te imple­men­teren is – elimi­neert niet het moeilijkste deel: het beheren van een consis­tent netwerk en gover­nance-model over verschil­lende provi­ders, accounts en regio’s, en dat op een manier die niet econo­misch wordt afgestraft door de beruchte “datazwaar­te­kracht”.

De meeste bedrijven bouwen geen enkele brug; ze proberen een systeem van wegen aan te leggen dat AWS, Azure, Google Cloud, plus on-premise en edge omvat. Binnen dit systeem zijn dagelijkse opera­ties, policy drift, segmen­tatie, obser­va­bi­lity en voorspel­baar­heid van kosten de echte bronnen van risico en moeite.

Het probleem is niet alleen technisch, maar ook economisch

Het tweede deel van het verhaal wordt vaak onder­schat in aankon­di­gingen van hypers­ca­lers, maar is doorslag­ge­vend voor de vraag of multi-cloud daadwer­ke­lijk in productie wordt genomen. Het handmatig opzetten van multi-cloud netwerken was altijd al mogelijk – traag, complex en een hoofd­pijn­dos­sier, maar wel mogelijk. Als je AWS echt met Azure wilde laten praten, en Azure met Google Cloud, en Google Cloud met OVHcloud, kon dat.

De echte showstopper was echter altijd de economie: de astro­no­misch hoge egress-kosten die cross-cloud dataver­keer commer­cieel onhaal­baar maken. “Archi­tec­to­nisch mogelijk” was altijd maar één stukje van de puzzel; “finan­cieel duurzaam” was het andere. Imple­men­ta­tie­snel­heid is belang­rijk, maar niet als je honderd­dui­zenden dollars per maand betaalt om logs, ML-datasets of analy­ti­sche workloads tussen clouds te verplaatsen.

Zolang hypers­ca­lers klanten niet toestaan om native en non-native services te combi­neren zonder finan­cieel te worden afgestraft, zullen hun multi-cloud oplos­singen slechts een deel van de oplos­sing zijn. De huidige AWS-Google Cloud inter­con­nect veran­dert daar niets aan.

Erkenning van multi-cloud barrières en een holistische aanpak

Wat wel veran­dert – en wat de aankon­di­ging van AWS stilzwij­gend beves­tigt – is hoe organi­sa­ties tegen multi-cloud aankijken. Het gaat niet langer alleen om failover of “het vermijden van lock-in”. Het gaat om best-of-breed: de AI-stack van Google gecom­bi­neerd met de databases van AWS, of misschien de identi­teits­in­te­gratie van Azure naast een soeve­reine cloud voor compli­ance. Moderne archi­tec­turen mixen en matchen steeds meer.

Inter­con­nects en private verbin­dingen zijn dus belang­rijk, maar alleen als ze schalen naar meer dan twee provi­ders en niet je budget opblazen zodra er echte data gaat stromen.

De aankon­di­ging van AWS en Google Cloud wijst op een toekomst waarin clouds “naadlozer” met elkaar samen­werken. De visie is goed, maar connec­ti­vi­teit als native functie in plaats van een gespe­ci­a­li­seerd product betekent nog steeds dat bepaalde essen­tiële elementen ontbreken, zoals:

• Een netwerk dat alle clouds verbindt, niet slechts twee;
• Intel­li­gente routing die kosten minimaliseert;
• Vrijheid van vendor lock-in – dezelfde hypers­ca­lers contro­leren nu ook de ruggengraat;
• Diepgaande zicht­baar­heids­func­ties, zoals verkeers­stroo­m­ana­lyses en AI-gestuurde anomaliedetectie.

Dit zijn de onder­delen waar hypers­ca­lers moeite mee hebben, omdat het oplossen van deze problemen hun opera­ti­o­nele risico’s bloot­legt en de struc­tu­rele wrijving vermin­dert die workloads “sticky” houdt en inkom­sten voorspel­baar maakt.

Wat emma al veel eerder bouwde

De visie die AWS en Google Cloud nu, zij het voorzichtig, omarmen, is precies de visie waar emma vanaf dag één naartoe heeft gewerkt. emma’s multi-cloud netwer­k­in­fra­struc­tuur verbindt al alle grote hypers­ca­lers en zal in 2026 worden uitge­breid met nieuwe soeve­reine, regio-speci­fieke keuzes.

Omdat emma niet gebonden is aan één provider, kan het iets doen wat hypers­ca­lers simpelweg niet zullen doen: verkeer optima­li­seren op basis van kosten, presta­ties en beleid, niet op basis van vendor-incen­tives. Door verkeer over het eigen netwerk te leiden, kan het platform datatransfer aanbieden tegen ongeveer een derde van de standaard­ta­rieven. Organi­sa­ties hebben met emma’s intel­li­gente netwerk­op­ti­ma­li­satie egress-kosten met tot wel 80% verlaagd, waardoor voorheen onbetaal­bare multi-cloud archi­tec­turen “at-scale” haalbaar werden. En dat geldt voor echte workloads, data en latentie-eisen.

Toekomstperspectief: waar betekent dit voor de sector?

De multi-cloud inter­con­nect van AWS is een beteke­nisvol signaal, omdat het de toekomst en richting van de cloud­markt beves­tigt. Toch blijft het een smalle, vendor-gestuurde brug. Organi­sa­ties die echt multi-cloud willen inzetten, hebben een wereld­wijd, vendor-agnos­tisch en econo­misch haalbaar netwerk nodig.

Ondanks de schijn­bare eenvoud van een native aanbod, opereren gespe­ci­a­li­seerde provi­ders al in de volgende fase van multi-cloud: minimaal een wereld­wijd netwerk dat drie hypers­ca­lers verbindt, met een kosten­struc­tuur die klanten niet straft voor het overschrijden van cloud­grenzen. Voor hen gaat de waarde­pro­po­sitie niet alleen over “inter­con­nectie in minuten”. Het gaat erom of de sector kan evolu­eren van connec­ti­vi­teit tussen twee hypers­ca­lers naar herhaal­bare multi-cloud opera­ties met de controls en kosten­ef­fi­ci­ëntie die het duurzaam maken. Dat is wat nodig is om multi-cloud in productie te draaien, niet alleen om het te verbinden.

Ontdek hoe emma’s netwer­k­in­fra­struc­tuur en gecen­tra­li­seerde control plane organi­sa­ties helpt de opera­ti­o­nele uitda­gingen en economie van multi-cloud te overwinnen: emma​.ms/​p​r​o​d​u​c​t​s​/​c​l​o​u​d​-​c​o​n​n​e​c​t​i​vity