Microsoft Azure haakt in 2026 aan op multicloudstandaard van AWS en Google

De door AWS en Google ontwikkelde verbindingsmogelijkheid voor verschillende clouddiensten krijgt volgend jaar Microsoft Azure als aangesloten cloudaanbieder erbij. Nu is Google de eerste cloudleverancier die via AWS Interconnect aansluit op het cloudaanbod van Amazon.

Amazon Web Services noemt Microsofts cloudaanbod Azure in zijn aankondiging van AWS Interconnect. Die nieuwe standaard voor multicloudverbindingen start nu als preview waarbij Google als eerste aanhaakt. 'Later in 2026' volgt Azure. Het is niet bekend wanneer dat zal zijn en welke clouddiensten van Microsoft dan aansluiten op welke clouddiensten van AWS. Het zou bijvoorbeeld opslag bij AWS kunnen zijn van data voor Azure-toepassingen. Tweakers heeft vragen uitgezet.

De door AWS en Google ontwikkelde standaard om verschillende clouddiensten van verschillende aanbieders met elkaar te verbinden, is nu als preview beschikbaar in vijf AWS-regio's. Het gaat om gebieden die corresponderen met regio's die Google hanteert voor zijn clouddiensten. De vijf regio's zijn AWS us-east-1 en Google us-east4 in de Amerikaanse staat Virginia, AWS us-west-1 en Google us-west2 in de staat Californië, AWS us-west-2 en Google us-west1 in de staat Oregon, AWS eu-west-2 en Google europe-west2 in de Britse stad Londen, plus AWS eu-central-1 en Google europe-west3 in de Duitse stad Frankfurt.

Europese gebruikers zijn daarmee ook in beeld voor deze nieuwe multicloudmogelijkheid, die AWS en Google bieden. Cloudaanbieder Salesforce haakt ook aan: het verbindt zijn datadienst Data 360 voor zakelijke gebruikers. AWS Interconnect lijkt nu omarmd door grote Amerikaanse cloudbedrijven, waar cloudreus Microsoft komend jaar dus bijkomt. AWS en Google presenteren hun samenwerking voor Interconnect als 'meer dan een multicloudoplossing: het is een stap naar een meer open cloudomgeving'. De specificatie voor de api is open en beschikbaar op Microsofts ontwikkelplatform GitHub.

Reacties (61)

[Jeoh]

MSSQL databases hosten in Azure (vanwege de veel lagere licentiekosten) en de rest in AWS

[DDX]

Maar dat kan toch al, net zoals voorbeeld wat in artikel staat:

Het zou bijvoorbeeld opslag bij AWS kunnen zijn van data voor Azure-toepassingen. Tweakers heeft vragen uitgezet.

Je kan toch gewoon firewall openzetten voor de services die mogen verbinden met de sql server.

[WernerL]

Een SQL server wil je toch niet een publiek IP geven lijkt me. Het is makkelijker en veiliger als SQL server alleen benaderbaar is vanuit een virtueel netwerk. Lijkt me dat juist dat nu mogelijk wordt zonder veel gedoe.

[Snow_King]

Hoezo niet? Private netwerken zijn echt schijnveiligheid.

Je hebt een firewall op elk modern OS, die kan gewoon verbindingen filteren. Als je om welke reden dan ook door de FW komt (of in een privaat netwerk...) dan heb je nog steeds de Authenticatie van de DB server zelf.

Geen enkel probleem om een DB aan een publiek IPv4/IPv6 adres te hangen, wel moet je gewoon de juiste maatregelen treffen en dus niet de poorten voor de hele wereld open zetten.

[Pogostokje]

Geen enkel probleem om een DB aan een publiek IPv4/IPv6 adres te hangen, wel moet je gewoon de juiste maatregelen treffen en dus niet de poorten voor de hele wereld open zetten.

Dit is veel te simpel gedacht en een heel slecht idee. Verdiep je even in het fenomeen "zero trust" en vooral waarom dat een zeer belangrijk onderwerp is in de wereld van security. Zou je toch iets op die manier bouwen kom je ook niet door de NIST/NIS2 audits heen met je omgeving wat ook een signaal zou moeten zijn dat men het er over eens is dat wat je zegt echt niet iets is wat je zult tegenkomen in het wild.

[Snow_King]

Je komt prima door een NIS2 audit heen met een statefull firewall en een database aan een publiek IPv4/IPv6 adres. Dat is echt het probleem niet.

Je hebt nog steeds zero trust. Je blokkeert al het verkeer en alleen vanaf specifieke locaties sta je het wel toe.

Wist je dat Meta hun hele netwerk ook zo gebouwd heeft? Alle servers hebben publieke IPv6 adressen en enkel vanaf specifieke locaties/sources kan je er bij.

Meta heeft geen enkel RFC1918 adres in gebruik voor hun servers, alles is publiek IPv6 met firewalls. Dat kan gewoon en is gewoon veilig.

[Houtenklaas]

Je komt prima door een NIS2 audit heen met een statefull firewall en een database aan een publiek IPv4/IPv6 adres.

Paar dingen uit NIS2.

Item 89:

Essentiële en belangrijke entiteiten moeten een breed scala aan basispraktijken op het gebied van cyberhygiëne toepassen, zoals zero trust-beginselen, software-updates, configuratie van apparaten, netwerksegmentatie, identiteits- en toegangsbeheer of gebruikersbewustzijn, opleidingen voor hun personeel organiseren en het bewustzijn van cyberdreigingen, phishing of socialengineeringtechnieken vergroten.

Item 125:

De bevoegde autoriteiten moeten erop toezien dat hun toezichthoudende taken met betrekking tot essentiële en belangrijke entiteiten worden uitgevoerd door opgeleide beroepsbeoefenaars, die over de noodzakelijke vaardigheden moeten beschikken om die taken uit te voeren, met name inzake het uitvoeren van inspecties ter plaatse en toezicht buiten de locatie, met inbegrip van het opsporen van zwakke punten in databases, hardware, firewalls, encryptie en netwerken. Die inspecties en dat toezicht moeten op objectieve wijze worden uitgevoerd.

Ik herhaal het nog maar even. Netwerksegmentatie, firewalls, zwakke punten in databases, encryptie (met sleutelbeheer). En dat afgetopt met een jaarlijks Risk Assessment en een Risk Treatment plan waarin staat wat de bedrijfsrisico's zijn als je geen IT meer hebt (1 uur, 1 dag, 1 week, 1 maand, nooit meer), ransomware je bedrijf gijzelt, imagoschade die dat oplevert en noem maar op.

Netwerkarchitectuur, security en beheer is een vak en echt iets meer dan het knopen van een server aan het internet en vertrouwen op die firewall. Dat is exact alles wat Zero Trust probeert te voorkomen.

[Snow_King]

Dus je zegt dat een database server nooit een IPv6 adres kan krijgen omdat dat geen zero trust is?

[david-v]

Als je database server een publieke IP adres krijgt dan krijg je binnen no time tig scans op dat IP adres. Hackers zijn dol op databases met een publieke ip adres.

Maar ik denk dat wat jij bedoelt is dat de database achter een firewall staat en dat de database zelf niet benaderbaar is met een publieke IP adres, toch?

Antwoord op je vraag is dus nee, je wilt een database server niet een publieke IP adres geven. Het enige publieke adres is die van je firewall.

[Snow_King]

Als de firewall alle inbound connecties op DROP heeft staan weet niemand dat daar een database achter zit.

Verdiep je eens goed in statefull firewalls zoals die van Windows of Netfilter op Linux, prachtige firewalls waar je gewoon niet doorheen komt.

En waarom zou je firewall een publiek adres hebben en je DB server niet? Port forwarding? NAT als schijnveiligheid toepassen?

Nee, je DB kan gewoon een publiek IPv4/IPv6 adres hebben als er in het pad maar een goed afgestelde statefull firewall zit. Private netwerken met RFC1918 IPv4 adressen zijn echt niet nodig. Het mag wel, maar het is geen vereiste.

Als je dus vanaf GCP bij een DB op AWS wil, dan kan je dat gewoon via een publiek adres routeren en versleutelen via TLS 1.3

[david-v]

Ik weet niet in elke branche je werkt of wat je ervaring is. Maar in al de jaren dat ik dit wel doe (nog voor 2000) heb ik nog nooit meegemaakt dat een database een external facing IP adres had. Ik heb het dan wel over bedrijfsmatige toepassingen. Misschien ben ik de enige, maar gezien alle comments die je krijgt moet jij misschien wat meer onderzoek gaan doen.

Bij alle DO's door mensen aangeven, VPN, VNets en noem maar op kom je steevast met schijnbeveiliging. Ik wens je veel succes met je external facing databases. Hou vooral de firewall logs in de gaten, tenminste als je door de bomen nog het bos kan zien.

[Snow_King]

Al 20 jaar in de hosting industrie waar dit echt de normaalste zaak van de wereld is. In de hosting industrie is alles public facing zo ongeveer, ook databases.

[Gielovic]

Dat lijkt me sterk...want totaal onnodig. Enkel je webapplicatie en eventueel een admin tool a la phpmyadmin moeten bij je database kunnen. Die zijn publiek beschikbaar (de laatste bij voorkeur ook met enige filter). Met welk doel zou je die database aan het internet hangen?

[Snow_King]

Op die servers draait gewoon de database en die servers hebben een publiek IP-adres. Die zijn niet weg gestopt in een privaat netwerk. Zijn dus gewoon direct internet-facing.

[Hoover]

Dat maakt het ook erg makkelijk om tal van mysql servers te hacken.
Met een simpele google search kom je tal van servers tegen welke amper tot niet voor SQL injection beveiligd zijn omdat ze op antieke PHP versies draaien. Met een Kali iso kun je dan makkelijk scripts uitvoeren om de database te browsen.
En dan zie je dat die SQL servers vrijwel altijd rechtsreeks aan het internet hangen waardoor je met elke SQL management tool er bij kan.
Geen gedoe meer met scripts daardoor.

Ik had bij een hostingpartij in de VS een SQL server gevonden met daarop 100en databases van hun klanten.Van simpele sites van kerken tot hobbytrein sites. Voornamelijk hele kleine dingen.

Hing open en bloot aan het internet. Boel sites logde zelfs in met admin accounts waardoor ik heel snel die server kon inzien.
Veel van die databases bevatte een users login tabel met leesbare email adressen en wachtwoorden van hun klanten. Daarin stonden tig email adressen [e-mail] of andere varianten die de hackers achter hadden gelaten.

Melding proberen te maken bij de hosting partij dat dit het geval was.
Nooit meer wat van gehoord. Jaren later nogmaals gekeken bij hen. Geen verbetering.

[FwRtje]

Tja, wij enkele maanden geleden volledig over gegaan op zero trust van cloudflare. 3x raden wat er uitviel enkele weken geleden. Dag productie.

[Ballenbakz]

Zero trust is een security uitgangspunt, niet te verwarren met het gelijknamige product van cloudflare. Dat heeft niks met elkaar te maken.

[FwRtje]

Jup, en toch werkte niks meer xD

[NeuroTechie]

Iets genaamd redunantie als je productie zo belangrijk is, anders mag je nooit klagen, al kost het 2-3 keer zoveel. Wij hebben alles zelfs 6-voudig, geen publiekelijk DNS in 6 verschillende landen en die verbonden zijn met 192 dedicated glasvezellijnen die eigendom zijn van ons en door een tiental landen gaan. Kostte een hoop, maar het was nodig (gigantisch farmaceutisch bedrijf). Je kunt dit ook veel kleiner opzetten en alsnog redunantie hebben, het alleen plannen, nadenken en geld vrijmaken. Anders moet je genoegen nemen met downtime.

[Sito]

Private netwerken zijn geen schijnveiligheid. Als je alles in Azure in een private virtual network hebt draaien kan niemand er van buitenaf bij.

Een SQL Server (of wat dan ook) zou je nooit publiek naar buiten beschikbaar moeten stellen, zelfs al gebruik je de juiste beveiligingsmaatregelen: MFA voor users, managed identity voor apps.

[sdsnatcher73]

Dat is ook schijnveiligheid. Dat private netwerk bestaat niet echt en is maar gewoon een stukje software wat het doet lijken dat het een private netwerk is. Dus ook daar hangt alles samen met regels die verkeer toestaan of niet, en ook daar kunnen fouten gemaakt worden en vulnerabilities in zitten.

[david-v]

Je legt uit wat een vnet is en vervolgens zeg je dat dit schijnveiligheid is, want het is software en daar kunnen vulnerabilities in zitten. Gelukkig zijn echte fysieke routers, switches, firewalls, load balancers enz allemaal vrij van vulnerabilities en leveren die geen schijnveiligheid, want ze zijn fysiek en bevatten uiteraard geen software....oh wacht. VPN is ook schijnveiligheid, want ook dat is "virtueel" en puur software...

Ik ben je echt kwijt...

[Gielovic]

Ja precies en die firewall op het OS, of authenticatie op de database server waar op vertrouwd wordt is geen software...

[sdsnatcher73]

Is ook software inderdaad en dus ook inherent onveilig.

[sdsnatcher73]

Ook de fysieke firewalls zijn software ja, en geven ook geen 100% veiligheid. Als je puur daarop vertrouwt. Het was een reactie op jouw bericht waar je schrijft “kan niemand er van buitenaf bij”, en dat is zeker de bedoeling maar absoluut geen garantie op veiligheid.

[david-v]

Ik heb nooit gezegd dat niemand erbij kan, dat was @Sito .

[Mit-46]

Je conclusie is wel contradictio in terminis

Zo kan je alles wel in een publiek netwerk hangen, maar!, wel zolang alles vervolgens op de juiste manier dichtgetimmerd wordt....

[GrooV]

Geen schijnveiligheid, als ik mijn SQL server benaderbaar maak voor het hele internet wordt deze 24/7 gescanned. Zodra er een 0day exploit is dan ben ik direct vatbaar. Met een prive netwerk gebeurt dit niet en moet ik uiteraard zorgen dat alles up to date is maar een aanvaller moet eerst zorgen dat deze binnen is.

Een kluis van de bank is ook niet vanaf de straat benaderbaar, ook al is deze nog zo veilig

[Snow_King]

Als jij je firewall aan hebt staan kan er een 0day in MSSQL zitten, maar dan kan iemand van buiten nog steeds niet communiceren met die poorten.

Alles dicht behalve vanaf specifieke IP's, geen enkel probleem. Je gaat uiteraard niet de MSSQL service voor de gehele wereld open zetten, dat schrijf ik ook nergens.

[Caelorum]

Zero day kan ook in de firewall zitten. Laagjes op laagjes is helemaal niet zo slecht, want je vertrouwd niet 100% op de veiligheid van 1 product tussen jouw database en de boze buitenwereld.

[Snow_King]

Je firewall is laag 1, de database is laag 2. Het is niet dat je daar zo maar doorheen komt.

[Caelorum]

Er zit nog steeds maar 1 laag tussen de buitenwereld en de database. De database die niet als core service/verantwoordelijkheid heeft om aanvallen van buiten te weerstaan.

Kijk, je mag doen wat je wilt, maar er is een goede reden waarom een layered security architectuur als een best practice wordt gezien. Je wilt gewoon én een firewall én network segmentatie én applicatie security hebben. Zelfs amazon geeft het in hun documentatie aan, ondanks alle zooi die ze verder nog uithalen (wat je als een groot bedrijf met oneindig resources kan doen): https://docs.aws.amazon.com/en_us/wellarchitected/latest/framework/sec-design.html

[Snow_King]

Wat ik ergens anders ook al stel: Dus je kan nooit IPv6 gebruiken voor een dergelijke applicatie?

[Caelorum]

Eh natuurlijk wel, maar dan nog kan je gewoon netwerk segmentatie doen en het niet publiek beschikbaar maken, nog los van een firewall.

[david-v]

Dus laag 2, je database, heeft geen publieke IP adres en is niet direct benaderbaar via het internet. Maar in meerdere posts blijf je vragen waarom je database geen publieke IP adres zou mogen hebben. Je geeft zelf antwoord op je vraag.

[Houtenklaas]

Weleens gehoord van "Zero Trust", het opwerpen van meerdere drempels om hackers tegen te houden en "Zero Days"? Een productiedatabase aan een extern internetadres hangen is simpelweg vragen om ellende. Genoeg voorbeelden de afgelopen tijd met o.a. Fortinet dat dat niet zo'n goed idee is.

[Snow_King]

Zeker. Je firewall blokkeert alles en staat alleen specifieke sources toe, dat kan. Je hoeft echt geen RFC1918 IPv4 adressen te gebruiken voor een veilige database.

Zowel Windows als Linux hebben zeer goede statefull firewalls die dit prima kunnen doen. En als die uit zou staan heb je nog steeds de database server zelf die niet zo maar een login accepteert.

[Houtenklaas]

Weet je de XZ Utils backdoor nog? Dan kan je firewall nog zo fijn zijn, als dezelfde server een gat kent EN aan het internet hangt gaat dat je niet helpen. Daarnaast is het "best practice" dat het device maar één taak heeft. Niet server EN firewall dus. Het is een risico die volstrekt onnodig is.

[wooha]

Sommige exploits hebben geen authenticatie nodig. Wat hopelijk minder vaak voorkomt bij securityprotocollen dan bij achterliggende applicaties.

Die firewall vind je waarschijnlijk niet voldoende als de client geen veilig en ongedeeld IP adres heeft, zoals bij sommige hosted omgevingen, als de client achter een bedrijfs-NAT zit of als je niet wil vertrouwen op de authenticiteit van IP adressen via tussenliggende infrastructuur. Dan gebruik je mTLS of een VPN. Net zoals je in je eigen netwerk wil voorkomen dat systemen achter een niet gerelateerde netwerkpoort een IP adres kunnen gebruiken van een client (of uit een IP subnet) die toegang heeft tot de databaseserver.

[DDX]

Als je een 'shared' azure instance gebruikt zal de server gewoon een public ip hebben.
Waar een firewall voorzit (die default erg open staat)

En zoveel mensen die dus vinkje 'Allow Azure services and resources to access this server' hebben aanstaan en denken dat ze dan alleen hun eigen azure services toegang geven....
Al zie ik dat dat vinkje inmiddels default uitstaat.
(https://learn.microsoft.c...esql#allow-azure-services)

[Reactie gewijzigd door DDX op 2 december 2025 15:33]

[WernerL]

Maar dat is alleen als public access aan staat. Azure biedt ook de mogelijkheid om public access helemaal uit te zetten. In de organisatie waar ik werk is dat zelfs verplicht vanwege security reden. Alles hangt met een private IP in een Azure VNET. Dan kan niemand er van buiten af bij, tenzij je verkeer via bijvoorbeeld een loadbalancer naar je SQL server toestaat.

[baseoa]

Als je het over internet wil kunnen bereiken, heb je een internetprotocoladres nodig (IP-adres). Daar kun je allerlei software aan toevoegen zoals NAT, stateful firewalls, VPN's, andere soorten tunnels... maar het blijft IP-verkeer dat er uiteindelijk aan de andere kant van de pijp uit moet komen

Als je denkt dat een dienst (bijv. MSSQL) niet veilig is, kun je het in een vpn verpakken waar alleen die server met de toegestane clients in zitten. Dat werkt volledig onafhankelijk van de vendor van de servers

[Reactie gewijzigd door baseoa op 2 december 2025 15:32]

[laurxp]

Klopt, maar nu hoef je de firewall niet meer open te zetten! De cloudproviders zorgen zélf voor een veilige verbinding tussen je interne resources op beide platforms. Een privaat netwerk tussen twee clouds opzetten is nu net zo makkelijk als een privaat netwerk binnen één cloud opzetten.

[DDX]

Dat klinkt zoals azure sql server nu bij heel veel mensen volledig open staat voor iedereen die op azure draait.
Gelukkig zit er nog authenticatie, maar meeste mensen hebben vinkje aanstaat dat alle azure services erbij mogen.

[thof]

Dat mag ik toch hopen van niet, het is al jaren bekend dat je dat niet zou moeten doen. Het vinkje staat (tegenwoordig) by default ook uit. De meeste pentests vinden dit ook wel, als ze een beetje kennis hebben van Azure en het niet vanuit een blackbox perspectief onderzoeken.

[JackJack]

Ik ben benieuwd of europese alternatieven ook aan zullen sluiten.
Gezien de huidge politieke spanningen lijkt me dat best interessant voor de komende jaren.

[Pogostokje]

Uitdaging: er zijn op dit moment geen europese alternatieven die ook maar in de buurt komen van wat Azure, AWS en Google Cloud momenteel aanbieden. Er zitten honderden diensten in die cloud oplossingen die al 15-20 jaar in ontwikkeling zijn waarbij de focus ligt op het afstappen van VMs. De europese "cloud alternatieven" lijken juist de nadruk te leggen op het kunnen starten van VMs met wat toeters en bellen zoals netwerken. Dat is simpel en al helemaal uitgedacht, maar micro service innovatie zit daar niet. Die situatie is niet waar de grote cloudafnemers naar op zoek zijn, en die brengen het meeste geld in het laadje. Met andere woorden: de alternatieven zijn en blijven vooralsnog zo klein in verhouding dat ik mij afvraag of iemand zich er druk om gaat maken om daar op aan te haken. Uiteindelijk moet het financieel rendabel zijn, het zijn commerciele doelen.

[NoTechSupport]

Het klinkt alsof je de Europese alternatieven niet kent en/of niet wilt kennen, maar dat wilt nog niet zeggen dat ze er niet zijn.

[Pogostokje]

Ik ken helaas inderdaad geen europees alternatief dat (zo'n diversiteit aan) microservices aanbiedt zoals dat de 3 die ik noemde dat doen, en ik zou ze graag willen kennen als dat wel zo is. Waar denk jij aan bijvoorbeeld?

Waar ik beroepsmatig mee te maken heb zijn europese bedrijven die reageren op een vraag in de markt en beweren dat ze een alternatieve cloud aanbieden, maar dat zijn dan puntje bij paaltje vooral VMs, netwerk en databases, en een enkeling een containerplatform. Waar zijn de serverless functies, appservices, eventhubs, en dan heb ik het nog niet over de IAM kant van specifiek Azure: een EntraID implementatie in de grote zin van het woord. Een stapel VM's kunnen aanbieden is mijn ogen en voor mijn toepassingen niet een alternatief voor Azure of AWS clouddiensten.

[Martinspire]

Als je werkelijk alles zelf wilt aanpassen, ja dan kun je er niet omheen. Maar ik denk dat veel bedrijven prima met off-the-shelf oplossingen vooruit kunnen en de gangbare standaard gewoon hanteren (al dan niet geforceerd). Ik denk dat voor veel bedrijven de prijzen te hoog gaan worden, zeker als je daar nu de hardware prijsstijgingen bij meeneemt (wat overigens alle softwareboeren ook weer lekker een excuus geeft om de prijzen te verhogen).

[Pogostokje]

Als je als bedrijf alleen maar naar de cloud gaat om daar een virtuele machine op te starten, dan kun je daar overal wel terecht. Maar de diensten waar ik het over heb, zijn juist de serverless diensten of gebruiken hardware en software die je zelf niet even in huis haalt (inclusief de expertise om het te beheren).

Dat de IT organisatie van een kleinere organisatie alles op servers installeert: prima idee. Maar kijk nu eens naar enterprise omgevingen? Die zijn vaak veel meer bezig met compute optimalisatie, hebben grote datastromen, willen AI daar op inzetten, werken eventdriven, etc. Dan wil je een van die honderden andere micro-diensten gebruiken en is een virtuele machine pas de laatste fallback mogelijkheid.

Ik begrijp je opmerking over off-the-shelf niet zo in deze context, maar misschien hebben we het niet over hetzelfde.

[locke960]

Ik ben benieuwd wie aan wie betaald voor een dergelijke interconnect. Kom je er als nieuwe/kleinere partij ook nog tussen, of hebben we straks een triumviraat met een monopolie?

[laurxp]

Traditioneel is het antwoord "niemand aan niemand": bij een verbinding tussen gelijkwaardige partijen is iedere kant verantwoordelijk voor haar eigen kosten.

Bij een scheve machtsverhouding zal de kleinste partij doorgaans moeten betalen - hoewel ze dat vaak kwijtschelden als ze er zélf geld door besparen (bijv. door minder data betaald via hun eigen upstream peers te hoeven verzenden).

Google bied settlement-free peering aan, dus een lokale ISP of significante hoster zal in principe gratis mogen verbinden. Maar een contract tussen zulke giganten als Microsoft en Amazon? Joost mag het weten...

[baseoa]

Google is juist weg aan het migreren van vrij peeren, naar ik lees: https://news.ycombinator.com/item?id=45849318

Ze trekken weg van de internet exchanges en willen in plaats daarvan privécontracten opzetten met individuele partijen

[Insidio2]

ik ben er zeker van dat de kosten om dit te mogen gebruiken zal zowel op je AWS omgeving als Azure subscriptie aangerekend worden.

[Prince]

Klinkt niet meer dan logisch; bij cloud provider 1 stuur je data naar het internet; dat kost een bepaald bedrag per GB. Bij provider nr 2 haal je "van" het internet, dat kost ook een bepaald bedrag per GB.
Eventueel een feature prijs erbij. Natuurlijk de diensten die je benaderd moeten ook betaald worden, maar ik denk dat het logisch is dat als je vanuit Azure naar je S3 bij AWS gaat, je nog steeds de GET en PUT's bij je S3 bij AWS moet betalen; alsook data buiten je region.

[The-Abyss]

En nu nog een interconnect naar Nextcloud

[Llopigat]

Lijkt me geen slimme zet van Microsoft. Je geeft eigenlijk toe dat de concurrent beter is dan jij en speelt het spelletje dan volgens hun regels.

Aan de andere kant, dit is wel een patroon. Microsoft kan zelf geen browser maken maar leukt die van concurrent Google op. Kan zelf geen goede AI maken dus koopt gewoon de helft van OpenAI

Maar op een gegeven moment verf je je strategisch toch in een hoek met dat soort dingen.

[Ballenbakz]

Lijkt me geen slimme zet van Microsoft. Je geeft eigenlijk toe dat de concurrent beter is dan jij en speelt het spelletje dan volgens hun regels.

Dat geven ze helemaal niet toe en de cijfers laten ondergeschiktheid ook zeker niet zien. Bekijk het liever andersom: het geeft bedrijven die bij AWS of Google zitten de kans om laagdrempelig ook Azure diensten te gaan gebruiken. Dat levert geld op, en wie weet, stappen bedrijven zelfs voor bepaalde diensten wel helemaal over.

[Martinspire]

Is dit niet zozeer dat men allemaal een standaard begint die ongeveer hetzelfde doet, waarbij nu de grootste partij toch zijn zin heeft door kunnen drukken en de rest het niet genoeg in het harnas jaagt om er echt een punt van te maken.

Verder weten ze toch wel: men stapt niet zomaar over zolang er zoveel configuratie aan het platform vast zit.

[sebastiaanl]

Wat betekent dit voor overheidsinstanties waaronder gemeenten en belastingdienst, voor het het 'beheersen' van de gegevens die op Europese Azure servers worden opgeslagen. Zijn die dan middels deze koppeling plots niet meer enkel op Europese servers ontsloten?