AWS en Google laten clouddiensten onderling samenwerken met nieuwe standaard

Amazon en Google gaan samenwerken om verbindingen tussen AWS en Google Cloud eenvoudiger te maken. Interconnect, zoals de dienst heet, is een door Amazon ontworpen standaard waar Google als eerste gebruik van maakt. De api maakt het overbodig om bijvoorbeeld specifieke vlans, BGP-sessies of versleutelde verbindingen op te zetten.

Amazon Web Services heeft Interconnect-multicloud als preview beschikbaar gemaakt. Interconnect is een nieuwe standaard die door AWS is opgezet en waarvoor het bedrijf heeft samengewerkt met Google. Google Cloud is de eerste dienst die verbindingen met AWS mogelijk maakt, maar Amazon zegt dat ook andere cloudproviders er gebruik van kunnen maken.

Volgens de twee bedrijven is Interconnect bedoeld om het opzetten van verbindingen tussen meerdere clouddiensten mogelijk te maken. Via Interconnect moet het mogelijk worden om data en applicaties te kunnen gebruiken die op verschillende diensten worden gehost. Het is bijvoorbeeld mogelijk vanuit Google Cloud een datapipeline op te zetten om datasets uit een S3-bucket te halen, of dat een applicatie die in AWS draait data uit Google Cloud kan halen.

Het opzetten van zulke verbindingen was altijd veel gedoe, want klanten hadden praktisch twee keuzes als ze dat wilden. Ze konden ervoor kiezen alles onder te brengen bij een clouddienst, of zelf proberen verbindingen te leggen.

Dat laatste is een ingewikkeld proces met veel verschillende stappen, zeggen AWS en Google. Beheerders moeten bijvoorbeeld een fysieke verbinding opzetten, IP-adressen toewijzen, vlans opzetten en routingsessie met bijvoorbeeld BGP opzetten. Bovendien moeten ze voor die processen vaak aparte securityreviews doen, die ook weer tijd kosten.

Cross-Cloud Interconnect, zoals Google zijn implementatie noemt, moet veel van die taken overnemen. "Deze verbindingen zijn innovatieve, beheerde diensten die alle onderliggende verbindingen, vlans en routerinstances in minuten kunnen regelen", zegt Google.

Cloudproviders zijn al langer bezig hun diensten meer open te maken voor beheerders. Zo stopte Google Cloud vorig jaar al met egressfees voor migraties. AWS deed dat enkele maanden later. De bedrijven zeggen dat te doen om beheerders meer mogelijkheden te geven, maar dat is niet het hele verhaal. Zo zijn er, hoewel AWS, Microsoft Azure en Google Cloud oppermachtig zijn in hostingland, concurrenten die migratie makkelijker maken. Cloudflare begon in 2021 een S3-concurrent, die voornamelijk gebouwd was rondom het feit dat er geen egressfees waren.

Bovendien zijn de clouddiensten huiverig voor toezichthouders, die in toenemende mate eisen stellen aan de openheid. Toezichthouders zoals de Britse CMA begonnen bijvoorbeeld al een onderzoek naar hoe makkelijk of moeilijk het is om over te stappen tussen bepaalde clouddiensten. Amazon en andere bedrijven zeiden toen nog stellig dat dat overstappen heel eenvoudig was.

Reacties (32)

[jax1285]

Dit is er tussen Oracle OCI en MS Azure al jaren en ook al een tijd voor Google GCP, heet gewoon interconnect.

https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/azure.htm

https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/access-to-google-cloud-platform.htm

[Mellow Jack]

Niet helemaal. Je moet zelf een plan maken voor je VLANs en BGP. Bij Microsoft hebben ze expressroute en bij AWS volgens mij direct connect.

Moet wel zeggen dat het opzetten nou niet echt Rocket Science is. Maar misschien is dit wel handig voor clubjes software developers die helemaal geen verstand hebben vd onderliggende lagen.

[jax1285]

Klopt en bij Oracle heet het FastConnect. Uiteindelijk is het een automatisering i.c.m. een connection partner als Equinix, MegaPort enz.

[Da-WiZZy0n]

Maar met deze nieuwe methode heb je die tussenpartij niet nodig. Dat is dan al geregeld en hoef je niet weken te wachten op je lijntje.

[jax1285]

Hoeft bij Oracle - Azure interconnect ook niet, is volledig geautomatiseerd.

[Da-WiZZy0n]

Dat zou kunnen, maar ging dit niet over AWS <-> GCP?

Bij Oracle <-> Azure krijg je ook een layer 2 meermaals uitgevoerde glaslijn zonder poespas?

[jax1285]

Klopt maar het wordt gepresenteerd alsof het de beste uitvinding ooit is compleet nieuw geen andere hyperscaler heeft het.

En ja, ook layer 2 en redundant.

[Kerfuffle]

Ik vermoed dat Amerikaanse cloud providers ook wel de noodzaak zien tot het verlagen van barrières nu dat Europese cloud providers snel aan het opkomen zijn.

[n4m3l355]

Is dit niet juist het verhogen van barrières? Immers nu kun je makkelijk tussen Amazon/Google werken maar voor andere cq kleinere hosts wordt het verhoudingsgewijs lastiger. Uiteindelijk zou het fijn zijn als dit een open standaard is die iedere cloud dienst kan implementeren maar dat gebeurd dus niet.

[Da-WiZZy0n]

Hoezo wordt het lastiger? Er verandert niets aan hoe je interconnects maakt met partijen die niet zo'n soort partnership heeft met AWS of Google, dat kan mogelijk al, maar met een tussenpartij zoals Equinix. Het is aan de 'kleinere hosts' om dat aan te bieden op deze manier.

[PeterPluijms]

Moet je wel gebruik maken van open technologie en niet van de paas componenten. Dan heb je nog steeds een enorme vendor lockin.

[Cartman!]

Zolang je je daar bewust van bent is dat niet perse erg en kun je zeer kosten efficient applicaties draaien.

Als ik soms met concollegas spreek over de hosting kosten slaan ze steil achterover hoe goedkoop wij opereren met onze vendor lockin terwijl alles wel volledig redundant is uitgevoerd. De Europese cloud loopt flink wat jaren achter als het gaat om managed diensten zoals AWS Lambda, DynamoDB, EventBridge en ik zie ze dit ook de komende jaren niet benaderen.

[PeterPluijms]

Wij hebben inmiddels de les gehad dat goedkoop op de lange termijn regelmatig duurkoop is. Zodra ze je binnen hebben en je hebt geen realistisch exit-scenario zit je muurvast. Dan begint vaak ook uit het verhogen met de prijzen, bij de volgende contractverlenging ben je het haasje. Of de partij wordt overgenomen en verhoogt daarna de prijzen (VMWare, SolarWinds). Dat zal met een Azure/AWS minder snel gebeuren, maar prijzen verhogen weten ze wel genoeg van.

Daarom gebruiken we meer en meer open (source) technologie die in ieder geval portable is / kan zijn. Die kan dan misschien wel bij de grote jongens draaien, maar je kúnt weg. Het geeft ook een veel betere onderhandelingspositie. Of beter verwoord:

YouTube: The Gambler (2014) - F*** You Scene (7/10) | Movieclips

Geldt zowel prive als zakelijk. Maar to each his own

[Cartman!]

Ik draai al 10+ jaar workloads in AWS en het is enkel goedkoper geworden, nooit duurder Portable klinkt leuk maar komt ook met een prijs, je hebt engineers nodig die ermee kunnen omgaan om dit elders op te bouwen. Die kosten bespaar je ook allemaal met managed diensten.

[david-v]

Europese cloud providers snel aan het opkomen zijn.

Ik denk eerder de regelgeving vanuit de EU.

[david-v]

Bedrijven die multicloud werken maken (hoop ik) gebruik van bijvoorbeeld terraform om dit soort connecties uit te rollen vanuit een pipeline. Dat dit nu via een dienst minder scripting vereist is wel mooi, maar niet meer dan dat. Uiteindelijk doet deze service precies hetzelfde dan wat je zelf in je scripts hebt staan lijkt me, of mis ik iets?

[Jay-v]

Nee, tot nu toe had je een VM met VPN of SD WAN om de verbinding op te zetten (op 1 van de 2 kanten) en moest je het zelf HA opzetten en BGP managen (of handmatig routing tabellen bijhouden). Een alternatief was iets als megaport gebruiken.

[david-v]

In de documentatie van Microsoft voor verbindingen tussen Azure en AWS zie ik een andere architectuur. Was/is dat zo anders tussen Google cloud en AWS?

[Da-WiZZy0n]

In de documentatie valt te lezen dat het om een layer 2 verbinding gaat via Direct Connect (AWS zijde), dus geen VPN/IPsec tunnel en zijn er dus ook geen instances nodig hiervoor.

Dit gaat dus om een verbinding met veel hogere doorvoer en lagere latencies. De oplossing tussen AWS/Azure is een eenvoudige VPN.

Terraform/IaC heeft er vrij weinig mee te maken, m.a.w.: Deze verbinding was gewoon überhaupt niet mogelijk, ook niet met scripting.

[4tro]

Tussen AWS ligt sowieso al een dikke 100 Gbit verbinding hoor, al een aantal jaren zelfs.

Ik heb die ooit nog helemaal vol getrokken met een migratie van een kleine 400 TiB aan plaatjes van s3 naar gcs.

Scriptje dat voor mij elke zoveel minuut een transfer jobs startte voor een set prefixes.

Leverde me een telefoontje op van Google SRE's die benieuwd waren hoe ik hun throttles omzeilde 🤣

En ja, dat was een duur geintje, maar verdiende zichzelf in een paar maandjes weer terug

[Reactie gewijzigd door 4tro op 2 december 2025 06:06]

[Da-WiZZy0n]

Welke services/componenten gebruikte je daarvoor?

[4tro]

Googles transfer service api en een Python script om jobs te genereren. Kreeg vooral het idee dat ze wilden weten hoe ik het deed en hoe ze honderden jobs konden throttlen zodat hun verbinding niet dicht getrokken werd. Had niet het idee dat ze boos waren.

[Da-WiZZy0n]

Ah, maar je hebt het dan over migratie van object storage. Is wel iets anders dan een private interconnect natuurlijk.

[4tro]

Ging meer over het idee van veel hogere doorvoer, het zal misschien een beetje latency schelen omdat het over ideale connectie heen gaat, maar qua doorvoer zal het niet heel veel uitmaken, en zeker niet genoeg om in normale omstandigheden iets uit te maken voor de gemiddelde gebruiker

[Mellow Jack]

Dit klopt niet. Direct Connects en Express Routes zijn al jaren de standaard manier van interconnects. Niet zo bekend met Google maar die hebben vast ook al jaren iets vergelijkbaars.

Wat deze dienst "speciaal" maakt is dat je de bijhorende netwerken, gateways en routeringen niet hoeft te verzinnen/deployen

[Da-WiZZy0n]

Dat hebben ze ook, Google inclusief.

Maar of je de twee clouds aan elkaar kon knopen zo, is maar de vraag. Dan had je dus Equinix, Megaport, etc. nodig om dit te regelen. Zoals je dat ook moet als je een Direct Connect aanvraagt naar on-prem, mits je zelf niet in het DC zit waar AWS met Direct Connect een PoP heeft. Geen idee of die clubs dit aanboden tussen beide clouds, maar ik vermoed van wel.

Het nieuwe is dus dat dit allemaal al voor je geregeld is en je geen tussenpartij in de hand hoeft te nemen.

[Reactie gewijzigd door Da-WiZZy0n op 2 december 2025 13:58]

[Kun]

En wat zijn de egressfees van Interconnect? Is dat al bekend?

[david-v]

Dat is vast gedeeltelijk inbegrepen bij de maandelijkse fee van de service.... Gratis 100GB per maand ofzo, daarna per GB betalen, voor niks gaat de zon op

[Da-WiZZy0n]

Vanaf Google of AWS? Bij Google kun je hier de pricing bekijken: https://cloud.google.com/network-connectivity/docs/interconnect/pricing#cci-pricing

AWS heeft de pricing nog niet online gezet (is ook nog in preview), maar ik gok dat je naar pricing van Direct Connect kunt kijken en daar wat bovenop..

[Reactie gewijzigd door Da-WiZZy0n op 2 december 2025 00:55]

[PolarBear]

Te zien op de volgende factuur

[Ootje70]

De door Amazon ontworpen standaard....? Dus omdat dit door hen is ontwikkeld en er nu in 1 koppeling (integratie) gebruik van maakt is dit een standaard? Er is hier sprake van bilaterale integratie tussen twee partijen, gebaseerd op hun eigen API’s of protocollen. Een koppelingstandaard ontstaat meen ik pas wanneer de koppeling is gebaseerd op een open, gedocumenteerde en breed geaccepteerde specificatie (bijvoorbeeld OAuth 2.0, OpenID Connect, of een standaard voor data-uitwisseling zoals JSON-LD). Of wanneer meerdere partijen dezelfde specificatie gebruiken, waardoor interoperabiliteit ontstaat maar daar is imho hier nog geen sprake van.

[Paddy99]

Ik heb zelf een kleine homelab, maar ben niet geavanceerd genoeg om te begrijpen hoe moeilijk is het nu echt om dit zelf aan te leggen als IT professional? Als in, is dit een standaard voor de echte IT prof of voor de AI programmeur die niet aan networking wil doen?