Wereldwijde cloudinfrastructuur en organisatie van resources

Een regio is een geografisch gebied waar een aanbieder clouddiensten aanbiedt vanuit een groep datacenters. Door een regio te kiezen, plaats je de meeste resources, zoals een database, in dat gebied. Regio’s zijn ontworpen om onafhankelijk te werken, wat helpt om regionale storingen te begrenzen.

Lees de locatie correct

AWS, Microsoft Azure en Google Cloud gebruiken verschillende namen voor vergelijkbare locaties. Een weergavenaam helpt mensen een plaats te herkennen; een code identificeert die in opdrachten en sjablonen.

Een naam alleen kan misleiden. Azure West Europe (westeurope) ligt in Nederland; North Europe ligt in Ierland. Google Cloud europe-west4 ligt in Nederland, terwijl europe-west1 in België ligt. AWS Europe (Frankfurt) gebruikt eu-central-1. Als een land is voorgeschreven, controleer dan de gedocumenteerde fysieke locatie.

De aanbieders beheren enkele tientallen regio’s in Noord- en Zuid-Amerika, Europa, Azië en de Stille Oceaan, het Midden-Oosten en Afrika. Hun aanwezigheid blijft groeien. Een actuele infrastructuurkaart is nuttiger voor een locatiekeuze dan een uit het hoofd geleerd aantal regio’s.

Maak onderscheid tussen locatie en bereik

Het bereik van een resource beschrijft het gebied waartoe die behoort of dat die kan bedienen.

Het label regionaal zegt op zichzelf weinig over bescherming tegen storingen. Een regionale resource kan vanuit meerdere zones bereikbaar zijn en toch afhankelijk zijn van infrastructuur in één zone. Controleer de redundantie-instelling om te achterhalen of de resource een zonestoring overleeft.

Bij een locatie hoort ook een controle van gegevensstromen. Een database kan in de gekozen regio draaien terwijl een back-up- of replicatiefunctie de gegevens elders naartoe kopieert. Geografisch redundante opslag van Azure is daarvan een voorbeeld. Controleer waar de primaire gegevens, back-ups en replica’s naartoe gaan voordat je de regio als volledige grens voor de gegevenslocatie beschouwt.

Controleer wat de regio biedt

Dienstenlijsten en prijzen verschillen per regio. Controleer of de vereiste databasefunctie, machinegrootte en mogelijkheden voor weerbaarheid beschikbaar zijn. Mogelijk moet ook toegang voor een account worden ingeschakeld: AWS-regio’s die na 20 maart 2019 zijn geïntroduceerd, zijn standaard uitgeschakeld en sommige Azure-regio’s hebben beperkte toegang.

Stel dat een machine is aangemaakt in eu-west-1, maar dat een AWS-resourcelijst nu us-east-1 toont. De lege lijst betekent niet dat de machine is verwijderd. Schakel over naar de regio waarin de machine is aangemaakt en controleer het geselecteerde account en de filters. Als je de weergave verandert, blijft de machine draaien en blijven de kosten doorlopen.

Een beschikbaarheidszone is een geïsoleerde groep van één of meer datacenters binnen een regio. De stroomvoorziening, koeling en netwerkvoorzieningen zijn onafhankelijk van die van andere zones. AWS en Azure noemen dit een beschikbaarheidszone; Google Cloud noemt het een zone.

Begrijp de fysieke lagen

Een datacenter is een gebouw met servers en ondersteunende apparatuur. Een zone kan meerdere van zulke gebouwen gebruiken en een regio groepeert zones. Als je een zone als precies één gebouw beschouwt, krijg je een verkeerd beeld van de storingsgrenzen van de aanbieder.

Zones liggen ver genoeg uit elkaar om de kans te verkleinen dat ze samen worden getroffen door een lokale brand, een stroomprobleem of een overstroming, maar dicht genoeg bij elkaar voor snelle communicatie. AWS plaatst zones binnen ongeveer 100 km van elkaar; Azure beschrijft zones als gewoonlijk binnen 100 km van elkaar en streeft naar een retourtijd van minder dan ongeveer 2 ms. Snelle verbindingen maken synchrone replicatie praktisch: een schrijfbewerking wordt pas bevestigd nadat de vereiste kopieën over zones zijn opgeslagen.

Een grote regionale gebeurtenis kan nog steeds meerdere zones treffen. Meerdere zones bieden bescherming tegen een zonestoring; een tweede regio biedt een afzonderlijke locatie voor herstel na een regionale storing.

Lees zone-identificaties

AWS voegt een letter toe aan een regiocode, zoals in eu-central-1a. Google Cloud voegt een koppelteken en een letter toe, zoals in europe-west4-a. Azure gebruikt logische zonenummers zoals 1, 2 en 3.

Overeenkomende namen bij verschillende klanten kunnen misleiden. Azure-zone 1 kan in verschillende abonnementen aan verschillende fysieke zones zijn toegewezen. AWS heeft namen in zijn oudste regio’s onafhankelijk toegewezen voor accounts die vóór november 2025 zijn aangemaakt; nieuwere accounts gebruiken een consistente toewijzing. Een AWS-AZ-ID, zoals euc1-az1, identificeert dezelfde fysieke zone in alle accounts. Teams die fysieke plaatsing afstemmen, vergelijken AZ-ID’s of gedocumenteerde toewijzingen aan fysieke zones.

AWS stelt dat elke regio minstens drie zones heeft. Veel Azure-regio’s hebben er drie, maar sommige hebben er geen. Google Cloud-regio’s hebben meerdere zones. Controleer zowel de gekozen regio als de zoneondersteuning van de dienst.

Kies de bescherming die je nodig hebt

Azure Storage laat zien waarom alleen het aantal kopieën niet genoeg is. LRS bewaart drie lokale kopieën in één datacenter. ZRS verdeelt kopieën over drie zones. GRS voegt een kopie in een tweede regio toe voor herstel. Drie kopieën in één gebouw delen nog steeds de risico’s van dat gebouw; plaatsing in drie zones neemt die specifieke afhankelijkheid weg.

Aanbieders spreiden updates over zones om de gevolgen van een foutieve wijziging te beperken. Kopieën kunnen ook overdrachtskosten veroorzaken: in oktober 2026 brengen AWS en Google Cloud veel overdrachten tussen zones in rekening, terwijl Azure geen kosten rekent voor overdrachten tussen zones binnen dezelfde regio. Prijzen per dienst blijven van belang als je een volledig ontwerp vergelijkt.

Een edgelocatie, of aanwezigheidspunt (PoP), brengt geselecteerde diensten dicht bij gebruikers. Deze locaties bieden caching en toegangspunten tot het netwerk. Ze bieden niet het brede aanbod aan reken- en databasediensten van een regio. Aanbieders hebben honderden edgelocaties, die wijder verspreid zijn dan hun regio’s.

Volg een verzoek door een CDN

Een contentdistributienetwerk (CDN) bewaart herbruikbare kopieën dicht bij lezers. Amazon CloudFront, Azure Front Door en Google Cloud CDN zijn voorbeelden.

1. Routering stuurt het verzoek naar een geschikte edgelocatie. CloudFront gebruikt selectie op basis van DNS; andere diensten gebruiken anycast, waarbij meerdere locaties hetzelfde IP-adres bekendmaken, of een combinatie.
2. De locatie controleert haar cache, een opslagplaats voor herbruikbare content.
3. Bij een cachetreffer geeft de locatie een bruikbare opgeslagen kopie terug. Bij een cachemisser haalt ze het object op bij de bronserver, de gezaghebbende opslag of server.
4. Geschikte content blijft in de cache voor latere verzoeken, afhankelijk van de geldigheidsduur (TTL) en cacheregels.

CloudFront gebruikt ook grotere regionale edgecaches tussen veel edgelocaties en de bronserver. Een object dat uit een kleine cache is verwijderd, kan daar nog beschikbaar zijn, zodat een extra reis naar de bronserver niet nodig is.

De afbeeldingen van een nieuwssite komen uit Frankfurt. Een lezer in São Paulo bevindt zich hemelsbreed op ongeveer 9.800 km afstand. Zelfs een ideale retourreis via glasvezel duurt ongeveer 98 ms; werkelijke routes duren langer. Bij een cachemisser moet de afbeelding nog steeds bij de bronserver worden opgehaald. Latere lezers kunnen de opgeslagen afbeelding lokaal binnen enkele milliseconden ontvangen.

Afbeeldingen, video’s, scripts, stijlbladen en downloads werken goed omdat veel mensen dezelfde bytes opvragen. Een persoonlijke winkelwagen heeft normaal gesproken een nieuw antwoord van de bronserver nodig. Een edgelocatie kan de verbinding verbeteren zonder dat elk antwoord in de cache kan worden opgeslagen. Edgelocaties kunnen ook DNS-query’s beantwoorden, zoals bij Route 53, of verkeer toelaten op het backbone-netwerk van een aanbieder, zoals bij AWS Global Accelerator.

Maak onderscheid tussen infrastructuur dicht bij gebruikers

Azure Arc voegt een beheerverbinding toe: Azure Resource Manager kan servers en Kubernetes-clusters buiten Azure beheren, ook op eigen locatie en in andere clouds. Het verandert een gebouw van een klant niet in een Azure-regio.

Volg gegevens in de cache over grenzen heen

Een wereldwijd CDN kan content in meerdere landen opslaan. Een regel die buitenlandse kijkers blokkeert, regelt de toegang van het publiek; die bepaalt niet waar kopieën in de cache worden opgeslagen of waar verwerking plaatsvindt. Content die strikt binnen één land moet blijven, vereist een CDN dat de toegestane locaties garandeert of een leveringsroute die opslag in de cache in het buitenland vermijdt. Controleer dit afzonderlijk van de regio van de bronserver.

Hoge beschikbaarheid betekent dat je gebruikers blijft bedienen als onderdelen uitvallen. Een enkelvoudig storingspunt is een afzonderlijke afhankelijkheid waarvan het verlies de applicatie stillegt. Twee webservers delen nog steeds een enkelvoudig storingspunt als beide afhankelijk zijn van één onbeschermde database.

Bescherm de volledige route van een verzoek

Laat applicatie-instances in verschillende zones draaien. Een loadbalancer controleert hun status en stuurt verzoeken naar gezonde instances. Bescherm ook de gegevenslaag met een zoneredundante database of een synchrone stand-byreplica in een andere zone, zoals bij een Amazon RDS Multi-AZ-configuratie.

Houd applicatie-instances waar mogelijk toestandsloos. Sla de sessie van een gebruiker op in een gedeelde, weerbare gegevensdienst in plaats van alleen in het geheugen van één instance. Dan kan een gezonde instance in een andere zone het volgende verzoek beantwoorden zonder dat de gebruiker de winkelwagen of sessie verliest.

Eén enkele virtuele machine blijft in de gekozen zone. Kies meerdere zonegebonden instances of een dienstoptie die zoneredundantie biedt.

Reken beschikbaarheid om naar uitvaltijd

Een jaar van 365 dagen heeft 8.760 uur. Zet de beschikbaarheid om in een breuk, trek die af van één en vermenigvuldig met de periode:

Bij 99,9% is de niet-beschikbare fractie 0,001, dus is de uitvaltijd 8,76 uur per jaar. Bij 99,95% is dat 4,38 uur. Bij 99,99% is dat ongeveer 52,6 minuten. Deze omrekeningen beschrijven een percentage over die periode; een daadwerkelijke dienstenniveauovereenkomst bepaalt ook hoe de beschikbaarheid wordt gemeten.

Stel voor een ideale illustratie dat elk van twee zones de volledige applicatie kan draaien, elk 99,9% van de tijd beschikbaar is en de storingen onafhankelijk zijn. De kans dat beide uitvallen is:

De resulterende beschikbaarheid is 99,9999%, ongeveer 32 seconden uitvaltijd per jaar. Gedeelde softwarefouten, configuratiefouten en regionale afhankelijkheden doorbreken de aanname van onafhankelijkheid. Deze berekening verklaart het voordeel van redundantie; het is niet de toegezegde beschikbaarheid van de applicatie.

Zorg voor voldoende overblijvende capaciteit

Een webwinkel heeft bij piekbelasting zes instances nodig. Twee instances in elk van drie zones leveren er normaal zes, maar slechts vier nadat een zone uitvalt. Om na het verlies van één willekeurige zone zes instances over te houden, moet elk van de twee overblijvende zones drie instances leveren. Implementeer er in totaal negen.

Met twee zones moet elke zone alle zes kunnen dragen, zodat het totaal 12 wordt. In het algemeen geldt bij gelijke aantallen instances per zone:

Hier is $N$ de benodigde piekcapaciteit en $z$ het aantal zones. Rond naar boven af, omdat een instance een hele eenheid is. Voor tien instances verdeeld over vier zones wordt tien gedeeld door drie naar boven afgerond op vier per zone: in totaal 16. Als één zone uitvalt, blijven er 12 over, wat genoeg is. Dit plan gaat ervan uit dat de vereiste capaciteit al draait; wachten op nieuwe instances voegt een afhankelijkheid voor herstel toe.

Een tweede regio ondersteunt herstel na een regionale ramp. Die kan ook gebruikers op afstand bedienen, aan landspecifieke locatievoorschriften voldoen of een dienst of capaciteit bieden die in de eerste regio niet beschikbaar is. Elke reden stelt andere eisen aan het ontwerp.

Stel twee hersteldoelstellingen vast

De herstelpuntdoelstelling (RPO) is het maximaal aanvaardbare gegevensverlies, uitgedrukt in tijd. De hersteltijddoelstelling (RTO) is de maximaal aanvaardbare tijd om de dienst te herstellen. Een back-up kan recente gegevens bewaren, maar herstel kan te lang duren; een snelle herstart kan nog steeds te veel gegevensverlies opleveren.

Een bedrijf kopieert zijn nachtelijke back-up om 01.00 uur en verliest de hoofdregio om 17.00 uur. In de beschikbare herstelkopie ontbreken 16 uur aan wijzigingen. Daarmee wordt een RPO van één uur niet gehaald. Vaker voltooide back-ups of continue replicatie zijn nodig; een schema helpt alleen als kopieën de herstellocatie daadwerkelijk op tijd bereiken.

Stem de voorbereidende maatregelen af op de hersteltijd

Meer onderdelen draaiend houden kost meestal meer en vermindert het herstelwerk. Back-up en herstel duurt doorgaans uren of langer. Actief-actief kan binnen seconden tot minuten herstellen, maar het ontwerp van de volledige applicatie bepaalt het resultaat.

Begrijp de gegevensachterstand

Tussen regio’s is replicatie meestal asynchroon: een schrijfbewerking wordt bevestigd voordat de kopie op afstand compleet is. Frankfurt en de omgeving van Washington D.C. liggen ongeveer 6.500 km uit elkaar, zodat alleen al een ideale retourreis via glasvezel ongeveer 65 ms duurt. Op die reis wachten bij elke schrijfbewerking zou vertraging toevoegen.

Het verschil in tijd tussen de actuele gegevens en de kopie op afstand is de replicatievertraging. Die kan toenemen bij zware belasting of netwerkproblemen. Bewaak de vertraging ten opzichte van de RPO. Een tweede regio met een verouderde replica biedt geografische scheiding, maar voldoet daarmee niet aan de doelstelling voor gegevensverlies.

Gebruik Azure-paren correct

Azure koppelt veel regio’s, zoals North Europe aan West Europe en East US aan West US. De koppeling ondersteunt gespreide platformupdates, prioriteit bij herstel en geografische replicatie van sommige diensten. De meeste paren blijven binnen één geografisch gebied. Brazil South is een uitzondering: de gekoppelde regio is South Central US.

Een paar implementeert geen kopie van een applicatie en regelt niet alle failoverstappen. Veel nieuwere Azure-regio’s hebben geen paar en een klant kan een andere toegestane secundaire regio kiezen. Controleer het replicatiegedrag van elke dienst.

Wereldwijde routering kan gebruikers naar gezonde regio’s leiden via Route 53, Azure Front Door of wereldwijde belastingverdeling van Google Cloud. Begroot dubbele resources en overdrachten tussen regio’s en test het volledige hersteltraject, inclusief quota en handmatige stappen. Als gegevens in een land met slechts één regio moeten blijven, gebruik dan de zones en lokale herstelmogelijkheden van die regio; een kopie in het buitenland zou in strijd zijn met de locatie-eis.

Latentie is de vertraging tijdens het transport. Retourtijd (RTT) meet de tijd voor een verzoek en het antwoord daarop, meestal in milliseconden. Bandbreedte meet hoeveel gegevens een verbinding per seconde kan vervoeren. Meer bandbreedte helpt bij het verplaatsen van een groot bestand, maar kan de reistijd naar een verre regio niet wegnemen.

Schat het fysieke minimum

Licht gaat door glasvezel met ongeveer 200.000 km/s. Elke kilometer voegt ongeveer 5 microseconden toe aan een enkele reis. Om een minimale RTT te schatten, verdubbel je de afstand voor de heen- en terugreis, deel je die door die snelheid en reken je seconden om naar milliseconden:

Dat geeft ongeveer 1 ms per 100 km. De hemelsbrede afstand is een ondergrens: kabels volgen in werkelijkheid langere routes en routers, wachtrijen en verwerking voegen vertraging toe.

Voor gebruikers in Sydney ligt Singapore op ongeveer 6.300 km afstand. Verdubbeld is dat 12.600 km. Delen door 200.000 geeft 0,063 seconden, oftewel ongeveer 63 ms. Noord-Virginia ligt op ongeveer 15.700 km afstand, wat minstens ongeveer 157 ms oplevert. Een regio in Sydney kan de reistijd terugbrengen tot enkele milliseconden.

Tel herhaalde reizen mee

Een vertraging kan klein lijken totdat een taak die herhaalt. Stel dat het openen van een verbinding en het ontvangen van een eerste antwoord vier opeenvolgende retourreizen kost. Bij elk 157 ms bedraagt het reisgedeelte 628 ms. Bij elk 5 ms is dat 20 ms. Het exacte aantal reizen hangt af van hergebruik van verbindingen en protocolgedrag; tel de reizen die de workload werkelijk maakt.

Hetzelfde effect treedt op tussen applicatieonderdelen. Een pagina voert 50 databasequery’s na elkaar uit. Als elke query op afstand 15 ms toevoegt, voegt de reeks 750 ms toe. Bij 1 ms binnen dezelfde regio is dat 50 ms. Dit zijn communicatietijden voor query’s; databasewerk kan extra tijd kosten. Door onderdelen die vaak communiceren bij elkaar te houden, betaal je niet steeds opnieuw de vertraging door afstand.

Kies de juiste verandering

Een edgecache helpt als die het verzoek kan beantwoorden. Die kan een databasetransactie die niet in de cache staat niet lokaal maken voor elke gebruiker. Meer bandbreedte verandert evenmin de afstand tot de bronserver.

Meet vanaf werkelijke gebruikerslocaties

Netwerkroutes volgen beschikbare verbindingen, peering en verkeersomstandigheden, niet de kortste lijn op een kaart. Vergelijk gemeten RTT’s of responstijden van de applicatie vanaf de plaatsen waar gebruikers werkelijk verbinding maken. Test representatieve tijdstippen en verzoeken voordat je een regio kiest. Een nabijgelegen regio is een sterke kandidaat; metingen bepalen of de werkelijke route goed voldoet voor de workload.

Een goede regiokeuze begint bij de workload: wie die gebruikt, welke diensten nodig zijn, waar de gegevens naartoe mogen en hoe herstel moet plaatsvinden. Als je regio’s zonder deze vereisten vergelijkt, kun je een lage prijs krijgen voor een locatie waarop de applicatie niet kan draaien.

Filter voordat je scores geeft

Zes factoren zijn vaak van belang: compliance en gegevenslocatie, latentie voor gebruikers, beschikbaarheid van diensten en functies, prijs, mogelijkheden voor weerbaarheid en duurzaamheid. Maak onderscheid tussen harde eisen en voorkeuren. Een landsbeperking of een ontbrekende essentiële dienst zorgt ervoor dat een regio afvalt. Een goede prijs kan niet compenseren dat een regio niet aan die eis voldoet.

Kies voor de resterende regio’s een consistente scoreschaal en gewichten die optellen tot 100%. Hogere scores moeten altijd een betere aansluiting betekenen, dus ook een hogere prijsscore voor lagere kosten. Vermenigvuldig elke score met het gewicht en tel de resultaten op.

Werk een beslissing uit

Een bedrijf in Duitsland vereist dat gegevens in de EU worden opgeslagen. Het schrapt een regio in de VS voordat het twee toegestane kandidaten vergelijkt. De scores lopen van 1 tot 5, waarbij 5 het beste is.

Het bedrijf geeft latentie een gewicht van 50%, prijs 30% en diensten 20%:

B staat nipt voor. Voor een handelsscherm verandert het bedrijf de gewichten naar 70%, 20% en 10%:

Het advies verandert omdat de bedrijfsprioriteit is veranderd. Vermeld de gewichten en de onderbouwing van de scores, zodat iemand anders de keuze kan begrijpen. Een precies ogende totaalscore is alleen zo bruikbaar als die invoer.

Bereken de kosten van de volledige opzet

Prijzen voor rekenvoorzieningen verschillen per regio door energie, grond, vraag en andere lokale kosten. Neem opslag, back-ups, capaciteit in een tweede regio en gegevensverplaatsing mee in de vergelijking. Overdrachten tussen regio’s en naar het internet worden doorgaans in rekening gebracht; inkomende gegevens zijn meestal gratis. Als je applicatieonderdelen die veel gegevens uitwisselen in verschillende regio’s plaatst, kan dat een kleine besparing op rekenkosten tenietdoen.

Voor weerbaarheid moet je de zoneondersteuning en een toegestane herstellocatie controleren. Voor duurzaamheid moet je kijken naar de elektriciteit die in de regio wordt gebruikt; aanbieders publiceren indicatoren zoals het regionale aandeel koolstofvrije energie van Google Cloud. Schonere elektriciteit kan de voetafdruk van dezelfde workload verkleinen.

Test ten slotte de best scorende regio’s met werkelijke latentiemetingen en de prijscalculator van de aanbieder. Leg de gekozen locatie, harde eisen, gewichten en redenen vast. Het kost werk om resources en opgeslagen gegevens te migreren. Beoordeel de keuze daarom opnieuw wanneer gebruikerslocaties, wetten, diensten of de regionale aanwezigheid van de aanbieder veranderen.

Gegevenslocatie beschrijft waar gegevens worden opgeslagen en verwerkt. Verplichte lokale gegevensopslag is een wettelijke eis om bepaalde gegevens binnen een land te bewaren. Gegevenssoevereiniteit gaat over de wetten en autoriteiten die zeggenschap over de gegevens kunnen hebben, ook via het bedrijf dat ze onder zich heeft. Lokale opslag en juridische zeggenschap hangen samen, maar beantwoorden verschillende vragen.

Volg meer dan de database

Een database in Azure germanywestcentral heeft de primaire opslag in Duitsland. Onderzoek ook back-ups, replica’s, logboeken, toegang voor ondersteuning, wereldwijde identiteitsdiensten en CDN-caches. Elk daarvan kan een andere locatie introduceren. De EU Data Boundary van Microsoft, voltooid in februari 2025, voegt toezeggingen toe voor opslag en verwerking binnen de EU en de EVA voor de diensten en gegevens die eronder vallen, met een gedocumenteerd bereik en uitzonderingen.

Een effectieve beoordeling vraagt zowel waar elke kopie naartoe gaat als welke organisatie toegang kan krijgen. Beleidsregels kunnen resourcelocaties beperken; versleutelingssleutels onder beheer van de klant en toegangsmaatregelen voor ondersteuning pakken andere delen van het probleem aan. Eén beheersmaatregel kan niet elke vraag beantwoorden.

Pas het doorgiftekader van de AVG toe

De Algemene verordening gegevensbescherming (AVG) geldt voor verwerking binnen haar territoriale bereik. Dat omvat vestigingen in de EER en bepaalde organisaties in het buitenland die goederen of diensten aanbieden aan mensen in de EU of hun gedrag volgen. De EER bestaat uit de EU, IJsland, Liechtenstein en Noorwegen. De AVG staat opslag in het buitenland toe als aan de toepasselijke voorwaarden is voldaan; er geldt geen algemene regel dat opslag alleen in de EER mag plaatsvinden.

Voor doorgifte aan een afzonderlijke ontvanger buiten de EER biedt hoofdstuk V deze routes:

Japan, het Verenigd Koninkrijk en Zwitserland zijn voorbeelden van bestemmingen met een adequaatheidsbesluit. Het EU–VS Data Privacy Framework (DPF), vastgesteld op 10 juli 2023, geldt voor deelnemende gecertificeerde Amerikaanse organisaties. Het verving de eerdere route via het privacyschild, die op 16 juli 2020 in Schrems II ongeldig werd verklaard. Het Gerecht verwierp in september 2025 een beroep tegen het DPF; in oktober 2026 liep een hoger beroep. Voor een doorgiftebesluit zijn de actuele status van het kader en de certificering van de ontvanger nodig.

Maak onderscheid tussen toegang en opslag

Gegevens die in de EER worden bewaard beschikbaar maken voor een afzonderlijke ondersteuningsorganisatie buiten de EER kan een doorgifte zijn, ook als de database lokaal blijft. De EDPB maakt onderscheid tussen die situatie en een medewerker van dezelfde verwerkingsverantwoordelijke die tijdens een verblijf in het buitenland toegang heeft tot gegevens; dat laatste is geen doorgifte aan een andere ontvanger volgens hoofdstuk V. De verwerking heeft nog steeds passende bescherming nodig.

De Amerikaanse CLOUD Act uit 2018 kan aanbieders die onder Amerikaanse rechtsmacht vallen via een toepasselijke juridische procedure verplichten gegevens waarover zij beschikken of zeggenschap hebben te verstrekken, inclusief gegevens die in het buitenland zijn opgeslagen. Het adres van een server alleen kan daarom geen uitsluitsel geven over soevereiniteit.

Een Nederlandse kliniek die een in de VS gevestigde aanbieder gebruikt, kiest een EU-regio, brengt buitenlandse ontvangers en ondersteuningsstromen in kaart, controleert de toepasselijke DPF- of SCC-route en beheert versleutelingssleutels en beleidsregels voor toegestane locaties. De kliniek documenteert deze keuzes naast de andere verplichtingen voor gegevensbescherming. Andere landen en contracten voegen eigen beperkingen toe, vooral voor medische, financiële en overheidsgegevens.

Een soevereine cloud voegt beheersmaatregelen toe voor gegevens, beheer en afhankelijkheid van wereldwijde systemen om aan de eisen van een rechtsgebied te voldoen. Een gewone regio in het juiste land biedt een locatiekeuze. Een soeverein aanbod kan ook veranderen wie de dienst beheert en hoe onafhankelijk die kan draaien.

Stel drie verschillende vragen

Bij gegevenssoevereiniteit vraag je waar gegevens worden bewaard en wie de toegang en versleutelingssleutels beheert. Bij operationele soevereiniteit vraag je wie de dienst beheert en ondersteunt en waar die mensen werken. Bij technische soevereiniteit vraag je of de omgeving kan werken zonder de wereldwijde systemen van de aanbieder. Beoordeel elke dimensie aan de hand van de werkelijke wettelijke, contractuele of beveiligingseis.

Vergelijk afzonderlijke omgevingen

Overheidsomgevingen ondersteunen programma’s zoals FedRAMP, met een bereik per dienst en verantwoordelijkheden voor de klant. Chinese omgevingen staan los van de wereldwijde diensten en vereisen de juiste accounts en eindpunten. Afzonderlijke cloudpartities hebben hun eigen identiteits- en API-grenzen; met een aanmelding bij de wereldwijde cloud krijg je niet automatisch toegang tot hun resources.

Bekijk het niveau van het Europese aanbod

In oktober 2026 is AWS European Sovereign Cloud beschikbaar; de eerste regio is in januari 2026 geopend in Brandenburg, Duitsland. Die is fysiek en logisch gescheiden van andere AWS-regio’s en wordt vanuit de EU beheerd door inwoners van de EU onder in Duitsland gevestigde vennootschappen.

Microsoft Sovereign Cloud omvat beheersmaatregelen van Sovereign Public Cloud in publieke regio’s, Sovereign Private Cloud met Azure Local op de locatie van een klant en nationale partnerclouds zoals Bleu in Frankrijk en Delos Cloud in Duitsland. Deze keuzes bieden verschillende beheerconstructies.

Het aanbod van Google Cloud omvat Data Boundary-beheersmaatregelen binnen de publieke cloud, Dedicated-aanbiedingen op afzonderlijke, door partners beheerde infrastructuur en Air-Gapped-omgevingen op basis van Google Distributed Cloud die losgekoppeld van Google en het internet werken. S3NS in Frankrijk en het aanbod van Thales in Duitsland illustreren de aanpak met lokale partners. Productnamen alleen bepalen niet welke diensten, locaties of onafhankelijkheidstoezeggingen een contract bevat.

Kies voldoende zeggenschap zonder benodigde mogelijkheden te verliezen

Een winkelier kan mogelijk aan zijn vereisten voldoen met een gewone EU-regio, waarborgen voor doorgifte en door de klant beheerde sleutels. Een overheidsinstantie met een nationale kwalificatie-eis controleert of een specifieke partner of soevereine aanbieding die kwalificatie heeft voor de vereiste diensten. Voor gerubriceerd offline werk kan een fysiek geïsoleerde omgeving nodig zijn.

Strengere isolatie kan de dienstkeuze beperken, nieuwe functies vertragen, de kosten verhogen en minder herstelregio’s overlaten. Vergelijk het werkelijke dienstenaanbod, de toelatingsvoorwaarden, de toezeggingen over beheer en de toegestane herstellocaties. Het label soeverein alleen garandeert geen bescherming tegen elke buitenlandse wet.

Aanbieders plaatsen geïmplementeerde dienstresources in beheercontainers. Die containers scheiden kosten, toegang en dienstlimieten. Hun namen verschillen: een AWS-account, een Azure-abonnement en een Google Cloud-project vervullen grotendeels vergelijkbare rollen.

Maak onderscheid tussen een container en een persoon

Eén persoon kan toegang hebben tot meerdere containers en één container kan veel mensen bedienen. Toegang delen plaatst een resource niet in een tweede container. Als je een analist bijvoorbeeld machtigt om een dataset in een ander project te bevragen, blijft het eigenaarschap van de dataset in het oorspronkelijke project.

Een AWS-account heeft een account-ID van 12 cijfers. De rootgebruiker is gekoppeld aan het e-mailadres waarmee het account is aangemaakt en heeft uitzonderlijke rechten. Bescherm deze gebruiker met multifactorauthenticatie en gebruik die alleen voor taken waarvoor de rootgebruiker nodig is. Voor dagelijks werk gebruik je normaal gesproken rollen en andere bevoegde identiteiten. Een account-ID identificeert een resourcegrens, geen met naam genoemde medewerker.

Begrijp de relatie met de Azure-directory

Een Microsoft Entra-tenant is de identiteitsdirectory van een organisatie. Een abonnement is een grens voor resourcebeheer en facturering die precies één tenant vertrouwt. Een tenant kan veel abonnementen ondersteunen. Een aangemelde persoon kan machtigingen hebben in sommige daarvan en geen in andere.

De term “Azure-account” kan verwijzen naar een aanmeldidentiteit of een factureringsconstructie en is daarom te vaag als je bespreekt waar een virtuele machine thuishoort. Benoem het abonnement en de tenant afzonderlijk.

Lees Google Cloud-projectidentificaties

Een project heeft een naam voor weergave, een permanente project-ID en een door de aanbieder toegewezen projectnummer. De naam kan veranderen en hoeft niet uniek te zijn. De ID is wereldwijd uniek en kan na het aanmaken niet veranderen. Die bestaat uit 6–30 kleine letters, cijfers of koppeltekens, begint met een letter en kan niet eindigen op een koppelteken. Zo is lumen-shop-prod een project-ID, terwijl “Lumen Shop Production” de weergavenaam kan zijn.

Projecten organiseren geïmplementeerde diensten, terwijl organisatie- en mapresources daarboven projecten organiseren. Facturering wordt afzonderlijk gekoppeld, zodat meerdere projecten een factureringsaccount kunnen delen zonder één project te worden.

Verdeel werk met bruikbare grenzen

Een bedrijf scheidt zijn winkel in ontwikkeling, testen en productie. Het gebruikt drie AWS-accounts, drie Azure-abonnementen of drie Google Cloud-projecten. Elke omgeving krijgt een afzonderlijk machtigingsbereik en kostenoverzicht. Die scheiding beperkt de schade die een ontwikkelfout kan veroorzaken als de machtigingen daarop zijn ingesteld.

Containers hebben ook quota, zoals regionale limieten voor virtuele CPU’s. Nieuwe containers kunnen met lage quota beginnen en veel limieten kunnen op verzoek worden verhoogd. Een herstelomgeving heeft voldoende quotum nodig voordat een storing optreedt; een werkend sjabloon alleen reserveert geen capaciteit en verhoogt die limieten niet.

Teams delen containers vaak in naar omgeving, afdeling of product om kosten en toegang overzichtelijk te houden. Geografische plaatsing is een afzonderlijke keuze: één container kan resources in meerdere regio’s bevatten.

Resources die samen worden aangemaakt, gewijzigd en verwijderd, delen een levenscyclus. Azure-resourcegroepen maken van die levenscyclus een beheergrens. Tags en labels voegen doorzoekbare beschrijvingen toe aan resources zonder hun fysieke plaatsing te veranderen.

Gebruik Azure-resourcegroepen

Voor gewone geïmplementeerde Azure-dienstresources bevindt een resourcegroep zich binnen één abonnement. Elke dergelijke resource hoort bij één groep; groepen kunnen geen andere groepen bevatten. Resources en beheerobjecten op abonnementsniveau bestaan op hogere bereiken, zodat de hiërarchie ook objecten buiten resourcegroepen heeft.

Een groep heeft een locatie voor de metadata, de vastleggingen die de groep en de resources daarin beschrijven. Die locatie dwingt niet af dat elk lid zich in dezelfde regio bevindt. Een webserver in één regio en de herstelresource daarvoor in een andere regio kunnen een groep delen.

Als je een resourcegroep verwijdert, verwijder je de inhoud. Dat is handig voor tijdelijk werk en gevaarlijk als er niet-gerelateerde productieresources in staan. Een verwijderingsvergrendeling kan onbedoelde verwijdering blokkeren totdat een bevoegd persoon die opheft. Kies een groep waarvan de leden veilig beslissingen over aanmaken, toegang en uitfasering kunnen delen.

Deze Azure CLI-opdracht maakt bijvoorbeeld een groep voor de productiewinkel aan:

az group create --name rg-shop-prod-weu --location westeurope

Een afzonderlijke groep rg-shop-test bevat een tijdelijke testomgeving. Als je die testgroep verwijdert, wordt de inhoud samen verwijderd. De productiegroep blijft afzonderlijk. Het patroon in de naam identificeert resourcetype, applicatie, omgeving en locatie, waardoor lijsten gemakkelijker te overzien zijn.

Toegang die aan een groep is toegewezen, zoals Reader, geldt voor de resources daarin. Veel resourcetypen kunnen tussen groepen of abonnementen worden verplaatst, afhankelijk van beperkingen van de dienst. Zo’n verplaatsing verandert de plaatsing voor beheer; de resource migreert niet naar een andere regio.

Vergelijk groepering in AWS

AWS Resource Groups kan resources verzamelen op basis van overeenkomende tags of een CloudFormation-stack. Een resource kan in meerdere van zulke groepen voorkomen. Als je een AWS Resource Group verwijdert, verdwijnt de groepering en blijven de resources bestaan. Dat verschilt van de verplichte Azure-container voor de levenscyclus van gewone geïmplementeerde resources. In Google Cloud vormen projecten de belangrijkste groeperingsgrens voor dienstresources.

Voeg nuttige tags en labels toe

Tags in AWS en Azure en labels in Google Cloud koppelen sleutel-waardebeschrijvingen aan resources. Voorbeelden zijn environment=prod, cost-center=4120 en owner=web-team. Ze helpen om inventarisaties en kostenrapporten te filteren of resources voor automatisering te selecteren.

Gebruik afgesproken sleutels en waarden. Als het ene team “prod” schrijft en het andere “Prod”, kan een rapport resources splitsen die bij elkaar horen. Tags van Azure-resourcegroepen worden standaard niet doorgegeven aan de resources daarin; beleid of automatisering kan de bedoelde waarden toepassen.

Een tag is beschrijvende metadata. Een label met “privé” isoleert geen netwerkverkeer en een groep “Europe” noemen verplaatst de resources niet naar Europa. Toegangsregels, netwerken en regio-instellingen bieden die beheersmaatregelen.

Een beheerhiërarchie organiseert containers in een boomstructuur. Met bovenliggende bereiken kan een organisatie veel accounts, abonnementen of projecten samen beheren. Overerving betekent dat toepasselijke instellingen op een bovenliggend niveau worden doorgegeven aan de onderliggende niveaus.

Vergelijk de boomstructuren van de aanbieders

Azure geeft elke tenant een rootbeheergroep, die standaard “Tenant root group” heet. Beheergroepen kunnen zes niveaus diep worden genest, zonder het root- en abonnementsniveau mee te tellen. Elke beheergroep of elk abonnement heeft één bovenliggend niveau.

AWS Organizations heeft een beheeraccount dat de organisatie aanmaakt en geconsolideerde facturen betaalt. Organisatie-eenheden (OU’s) groeperen accounts en kunnen vijf niveaus onder de root worden genest. Een account hoort bij één organisatie tegelijk. Het beheeraccount heeft een afzonderlijke rol en wordt niet beperkt door het servicecontrolebeleid van de organisatie.

De organisatie van Google Cloud is gekoppeld aan het domein van het bedrijf. Mappen vereisen een organisatie en kunnen geneste mappen bevatten. Een cursist die een gratis proefversie gebruikt, kan een project zonder organisatie hebben.

Volg een overgeërfde regel

Een bedrijf scheidt Retail en Logistics, elk met productie en ontwikkeling. Azure gebruikt beheergroepen voor afdelingen met daaronder abonnementen. AWS gebruikt OU’s voor afdelingen met daaronder accounts. Google Cloud gebruikt mappen voor afdelingen met daaronder projecten.

Als een beleidsregel van een Azure-beheergroep implementaties alleen in EU-regio’s toestaat, erven de onderliggende abonnementen die beperking. De groepsnaam is slechts een label; de beleidsregel dwingt de locatieregel af. In AWS kan een servicecontrolebeleid (SCP) van een OU een maximale machtigingsgrens voor lidaccounts instellen. Een SCP geeft een gebruiker op zichzelf geen machtiging om in die accounts te werken.

Begrijp overgeërfde toegang

Bij rolgebaseerd toegangsbeheer van Azure en toestemmingsbeleid van Google Cloud IAM worden toekenningen over bereiken heen bij elkaar opgeteld. Een toekenning van alleen-lezenrechten op een onderliggend niveau heft schrijftoegang die van een bovenliggend niveau is overgeërfd niet op. Om die brede toegang te verwijderen, wijzig je het bereik waarop die is toegekend of gebruik je een passende weigeringsmaatregel.

Azure Policy kan niet-conforme resourceconfiguraties weigeren, zoals een verboden locatie. Dat staat los van de roltoewijzingen die toegang verlenen. Weigeringsbeleid van Google Cloud kan specifieke machtigingen blokkeren. Beleidsregels van AWS Organizations verschillen eveneens van toekenningen van accounttoegang; IAM Identity Center kan machtigingensets aan meerdere accounts toewijzen.

Een auditteam dat bovenaan een Azure- of Google Cloud-hiërarchie passende leestoegang krijgt, kan resources in de onderliggende afdelingen lezen. Lidmaatschap van een AWS-OU alleen geeft dat team geen toegang tot accounts.

Houd de boomstructuur gescheiden van de kaart

Als je een abonnement of project verplaatst, veranderen de overgeërfde beleidsregels en toegang. De resources blijven in hun bestaande regio’s. Beoordeel de effectieve regels van de nieuwe tak vóór een verplaatsing: een logische reorganisatie kan de machtigingen van veel mensen beïnvloeden zonder één server te verplaatsen.

Een knop in de browser, een opdracht en een programma kunnen allemaal dezelfde cloudhandeling aanvragen. Elk stuurt een geauthenticeerd verzoek naar een programmeerinterface (API). De interface verandert hoe een persoon of applicatie werkt; machtigingen en dienstlimieten blijven gelden.

Stem de interface af op de taak

De grafische programma’s zijn de AWS Management Console, het Azure-portal en de Google Cloud-console. De belangrijkste CLI-programma’s zijn aws, az en gcloud. Azure PowerShell en AWS Tools for PowerShell bieden een andere opdrachtstijl. Mobiele apps zijn nuttig voor statuscontroles en meldingen.

Zo toont aws ec2 describe-instances --region eu-central-1 een lijst met EC2-instances in Frankfurt. az group list toont Azure-resourcegroepen en gcloud compute zones list toont Google Cloud-zones. Dit zijn API-clients, geen afzonderlijke inventarisaties van resources.

AWS CloudShell, Azure Cloud Shell en Google Cloud Shell bieden de bijbehorende CLI in een browser. Ze verminderen installatiewerk en gebruiken de aangemelde cloudcontext. Je moet nog steeds controleren op welk account, abonnement of project de sessie is gericht.

Volg de juiste API-route

In Azure maken handelingen in de besturingslaag resources aan, wijzigen of verwijderen ze via Azure Resource Manager. Dat past autorisatie en beleidsregels toe op verzoeken voor resourcebeheer. Handelingen in de gegevenslaag gebruiken het eigen eindpunt van de dienst, zoals bij het uploaden van een bestand naar een bestaand opslagaccount. Een programma kan beide soorten handelingen via verschillende clients uitvoeren.

SDK’s ondersteunen talen zoals Python, JavaScript, Java, C# en Go. Ze helpen bij het ondertekenen van verzoeken, het aanroepen van diensten en het opnieuw proberen na tijdelijke storingen. Een webapplicatie gebruikt een SDK wanneer elke upload door een gebruiker een opslaghandeling moet activeren; er is dan geen persoon nodig om de beheerconsole te bedienen.

Controleer de doelcontext

Standaardinstellingen kunnen ongemerkt de verkeerde bestemming kiezen. In de AWS-configuratie kun je een standaardregio instellen. De Google Cloud-configuratie kan een project en een regio voor rekenvoorzieningen selecteren, bijvoorbeeld met gcloud config set project lumen-shop-prod en gcloud config set compute/region europe-west4.

Azure gebruikt een geselecteerd abonnement, terwijl opdrachten voor het aanmaken van resources hun gedocumenteerde locatieparameters of standaardwaarden gebruiken. De metadatalocatie van een resourcegroep bepaalt niet in alle gevallen de locatie van elke resource. Controleer de bestemming van de opdracht voordat je die uitvoert.

Gebruik waar mogelijk kort geldige toegangsgegevens, zoals rollen of aangemelde sessies. Houd toegangssleutels buiten broncode en gedeelde documenten. Als je van de beheerconsole naar een CLI overstapt, omzeil je toegangscontroles niet: een geweigerde API-handeling blijft geweigerd, ongeacht welke client die verstuurt.

Eén tijdelijke resource met de hand aanmaken kan handig zijn. Dezelfde omgeving opnieuw bouwen voor testen, productie en herstel vereist een proces dat kleine verschillen tussen herhaalde klikhandelingen voorkomt. Infrastructuur als code (IaC) slaat de resourcebeschrijving op in tekstbestanden en gebruikt een implementatieprogramma om de omgeving aan te maken of bij te werken.

Beschrijf een toestand of een reeks stappen

Een declaratief sjabloon zegt wat er moet bestaan, zoals twee virtuele machines met een gekozen grootte en locatie. Het implementatieprogramma vergelijkt die gewenste toestand met de huidige omgeving en bepaalt de wijzigingen. Een imperatief script somt handelingen in volgorde op, zoals “maak de groep aan en maak daarna de machines aan.”

Een stack groepeert de resources die door een CloudFormation-implementatie worden beheerd. Met parameterwaarden kan een team een sjabloon hergebruiken voor verschillende locaties of groottes zonder meerdere gekopieerde bestanden te onderhouden.

Hergebruik een geteste omgeving

Een team heeft een webwinkelsjabloon dat is getest in Frankfurt, eu-central-1. Om de herstelinfrastructuur in Ierland voor te bereiden, geeft het eu-west-1 op als regioparameter. Voor testen geeft het een kleinere machinegrootte op. Versiebeheer legt het sjabloon en de beoordeelde wijzigingen vast, zodat de bedoelde configuratie zichtbaar is voor het team.

Het hergebruiken van infrastructuurcode kopieert de actuele gegevens van de applicatie niet. Back-ups of replicatie leveren die gegevens nog steeds en de gekozen herstelregio heeft nog steeds de vereiste diensten, machtigingen, quota en juridische geschiktheid nodig. Sjablonen maken het bouwen van consistente infrastructuur herhaalbaar; het volledige herstelplan omvat deze andere afhankelijkheden.

Pas wijzigingen consequent toe

Een idempotente handeling kan worden herhaald zonder nog een wijziging toe te voegen nadat het beoogde resultaat is bereikt. Bij ongewijzigde configuratie, invoer en resources hoort een declaratieve implementatie die de gewenste toestand heeft bereikt geen verdere infrastructuurwijzigingen op te leveren. Een script dat alleen uit aanmaakopdrachten bestaat, kan bij een volgende uitvoering mislukken of duplicaten aanmaken.

Een configuratieafwijking is een verschil tussen de gedeclareerde configuratie en de werkelijke resources. Iemand kan in de beheerconsole bijvoorbeeld een machinegrootte vergroten zonder het sjabloon bij te werken. CloudFormation-detectie van configuratieafwijkingen of een terraform plan kan helpen zulke verschillen te vinden. Een Terraform-plan toont voorgestelde wijzigingen; beoordeel die voordat je ze toepast.

IaC maakt wijzigingen beoordeelbaar, bewaart hun geschiedenis en helpt verloren omgevingen opnieuw op te bouwen. Het vereist ook dat je de bestanden onderhoudt en het programma begrijpt. Gebruik de handmatige interface voor een eenmalige verkenning en zet stabiele, herhaalde omgevingswijzigingen daarna in code, zodat de beoordeelde beschrijving juist blijft.