Amazon SAA-C03: Dataoverdracht & Migratie — Studiegids

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Onderdeel van de AWS SAA-C03 — Complete studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

De afweging: bandbreedte versus fysiek transport

Elke migratie begint met een rekensom. Bereken de theoretische overdrachtstijd voordat je een tool kiest:

Transfer days = (Dataset size in bits) / (Usable bandwidth in bps × 86,400)
Usable bandwidth = Link speed × Allowed utilization %

De cijfers zijn onverbiddelijk. Met een constante 100 Mbps duurt 1 TB ongeveer 24 uur; met 1 Gbps, ongeveer 2,5 uur. Een 15 Mbps-verbinding met een maximum van 70% bezetting levert slechts ~113 GB per dag op, dus voor 20 TB zou meer dan 175 dagen nodig zijn. 150 TB ’s nachts overzetten (10 uur met 80% van 100 Mbps) levert ~360 GB per nacht op, of 10,5 TB per maand — lang niet genoeg voor een deadline van 30 dagen. Zelfs bij volledige verzadiging, 24/7, verplaatst 100 Mbps slechts ~1 TB/dag, dus voor 150 TB is minimaal 150 dagen nodig. Op petabyte-schaal wordt het beeld nog somberder: een 500 Mbps-verbinding met een realistische efficiëntie levert een theoretische doorvoer van ongeveer 5,4 TB/dag, wat betekent dat voor 10 PB meer dan vijf jaar continue overdracht nodig zou zijn — langer dan het duurt om de meeste Direct Connect-circuits op te leveren.

Een redelijke vuistregel:

Het meest voorkomende foute antwoord in migratiescenario’s is de keuze voor een WAN-overdracht die wiskundig gezien niet binnen de gestelde tijd kan worden voltooid. De bijbehorende valkuil — “we draaien het gewoon elke nacht via het WAN” — is niet alleen langzamer. Het verbruikt productiebandbreedte, riskeert gedeeltelijke of corrupte overdrachten die opnieuw moeten worden geüpload, en kost doorgaans meer als de kosten voor bandbreedte en de tijd van engineers worden meegerekend. De kosten voor een Snowball-eenheid plus verzending zijn een vaste, voorspelbare post op de begroting.

De Snow Family voor offline bulkoverdracht

Snowball Edge-apparaten zijn er in twee varianten:

Snowcone is de kleine variant (~8 TB SSD), robuust en per koerier te verzenden, nuttig voor locaties met beperkte ruimte en vooraf geladen met DataSync-agents voor edge-synchronisatie. Snowmobile — een 45-voet container die tot 100 PB kan vervoeren — was gericht op datacenter-evacuaties op exabyte-schaal, maar is in de meeste regio’s uitgefaseerd ten gunste van parallelle vloten van Snowball Edge-apparaten. Het kiezen van Snowmobile voor iets minder dan een petabyte is een afleidingsmanoeuvre.

De Compute-variant is niet zomaar een grotere schijf. Het voert lokaal EC2 AMI’s, Lambda-functies en Greengrass-workloads uit, wat het de juiste keuze maakt wanneer data moet worden getransformeerd, gefilterd of PII moet worden verwijderd vóór de opname, wanneer een workload onmiddellijk in AWS moet worden hervat na opname, of wanneer de locatie geen of een onregelmatige verbinding heeft (schepen, afgelegen mijnen, tactische inzet, onderzoek op afstand). Kies Compute Optimized wanneer verwerking op het apparaat zelf vereist is; kies Storage Optimized wanneer de workload puur een bulk-kopieeractie is.

Elk Snow-apparaat past 256-bits encryptie at rest toe met KMS-sleutels die AWS nooit verlaten. De behuizingen zijn fraudebestendig (tamper-evident) met een E Ink-verzendlabel en een hardware Trusted Platform Module. Data wordt op het apparaat geschreven met de Snowball-client, het S3-compatibele eindpunt of een NFS-mount; TLS beschermt data in transit tijdens de opname en de uitwisseling van het verzendmanifest. Bij terugkomst wordt de inhoud opgenomen in S3 en wordt het apparaat cryptografisch gewist volgens de NIST 800-88-norm.

Voor werk op petabyte-schaal per locatie is parallellisatie het patroon. Een kantoor met een verbindingscapaciteit van 1–2 Gbps zou nog steeds maanden van continue verzadiging nodig hebben om 1 PB online te verplaatsen; een vloot van ~13 Storage Optimized-apparaten per locatie (elk 80 TB) die parallel worden verzonden, haalt een deadline van vier weken terwijl de internetverbinding van het kantoor wordt ontzien. Voor een klus van 600 TB in twee weken op een verzadigde 100 Mbps-verbinding is een kleine parallelle vloot het enige juiste antwoord — zelfs als we de kosten negeren, maken de natuurkundige wetten DataSync of een nieuwe Direct Connect onmogelijk.

DataSync voor online, geverifieerde, incrementele overdracht

DataSync is de juiste tool wanneer de bandbreedte voldoende is, maar de kenmerken van de workload — miljoenen kleine bestanden, diepe directorystructuren, doorlopende incrementele synchronisaties of migratie tussen verschillende bestandssystemen — eenvoudige tools zouden lamleggen. Een directory met 20 miljoen bestanden van 4 KB die met aws s3 cp wordt gekopieerd, wordt beperkt door round-trip latency, niet door doorvoersnelheid; elke PutObject brengt een TLS/HTTP round trip en API-requestkosten met zich mee. Bundelen in archieven werkt, maar je verliest de mogelijkheid om bestanden afzonderlijk te adresseren. De agent van DataSync parallelliseert over vele TCP-streams, verwerkt metadata native, verifieert elk bestand end-to-end met een SHA-256-checksum, voert retries transparant uit en rapporteert aan CloudWatch — en bereikt tot ~10 Gbps per agent met een voorspelbare prijsstelling per GB.

Bronnen en bestemmingen omvatten NFS, SMB, HDFS, zelfbeheerde object stores, S3, EFS, FSx for Windows File Server, FSx for Lustre, FSx for OpenZFS en FSx for NetApp ONTAP. Overdrachten gebruiken TLS 1.2 in transit en kunnen via VPC-interface-endpoints lopen om het openbare internet te vermijden.

Een cruciaal detail: DataSync vereist een agent voor on-premises NFS/SMB-bronnen. De agent draait als een VM op VMware, Hyper-V of KVM, op EC2 of op Snowcone. Denken dat DataSync agentless is voor on-prem is een veelvoorkomende valkuil — het is alleen agentless wanneer beide endpoints AWS-native services zijn.

Een minimale implementatie:

# Activate the on-prem agent
aws datasync create-agent \
  --activation-key ABCDE-12345-FGHIJ-67890-KLMNO \
  --agent-name onprem-nfs-agent \
  --vpc-endpoint-id vpce-0a1b2c3d

# Define source (NFS) and destination (S3)
aws datasync create-location-nfs \
  --server-hostname 10.0.5.20 \
  --subdirectory /export/video \
  --on-prem-config AgentArns=arn:aws:datasync:...:agent/agent-0abc

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::video-archive \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Role

# Task with bandwidth cap, verification, and a nightly schedule
aws datasync create-task \
  --source-location-arn <nfs-arn> \
  --destination-location-arn <s3-arn> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,BytesPerSecond=104857600,PreserveDeletedFiles=PRESERVE,PosixPermissions=PRESERVE \
  --schedule ScheduleExpression="cron(0 2 * * ? *)"

Twee operationele features zijn van belang. Bandbreedtebeperking (BytesPerSecond) voorkomt dat een gedeelde verbinding verzadigd raakt — een direct antwoord op scenario’s zoals “een 1 Gbps-verbinding gedeeld met andere afdelingen”. Filteren en plannen maken synchronisaties buiten kantooruren en het uitsluiten van tijdelijke bestanden mogelijk. Over een 10 Gbps Direct Connect waarbij gebruikers blijven lezen en schrijven, is het plannen van herhaalde taken het canonieke patroon: de initiële ‘sweep’ draagt het grootste deel over, opeenvolgende incrementele runs verwerken de delta’s, en 700 TB is haalbaar in ruim minder dan een week, zelfs bij gedeeltelijk gebruik.

Een subtielere valkuil betreft de getrouwheid van metadata. DataSync behoudt een specifieke set POSIX- of SMB-attributen — UID/GID/mode/timestamps voor NFS, eigendom en DACL’s voor SMB — maar het legt niet elk propriëtair NAS-attribuut vast. Vendorspecifieke ACL’s, uitgebreide attributen die verder gaan dan wat het protocol blootgeeft, snapshots en deduplicatiemetadata vallen buiten het bereik. Wanneer compliance een exacte NAS-replica inclusief vendor-features vereist, is DataSync alleen onvoldoende; een NetApp-bewust pad zoals FSx for ONTAP met SnapMirror, of een lift-and-shift via Storage Gateway, is dan nodig.

DataSync vult ook Snowball aan: Snowball verplaatst de initiële 150 TB, en DataSync verwerkt daarna de wekelijkse delta van een 500 GB werkset.

Storage Gateway: Hybride presentatie, geen migratie

Storage Gateway is geen migratietool — het is een hybride presentatielaag. On-premises applicaties blijven NFS, SMB, iSCSI of iSCSI-VTL spreken, terwijl de data in S3, S3 Glacier of EBS-snapshots terechtkomt. Storage Gateway verwarren met DataSync is een veelgemaakte fout: File Gateway is niet ontworpen om snel 70 TB te verplaatsen, en DataSync presenteert geen persistente share aan on-prem clients.

File Gateway is het werkpaard. Het schrijven van \\gateway\share\reports\2024\report.pdf produceert s3://bucket/reports/2024/report.pdf — native te gebruiken door Athena, Lambda, EMR of elke S3-client. Deze één-op-één mapping van bestand naar object is een groot voordeel ten opzichte van black-box back-updoelen. Lokale caching betekent dat ‘hot’ bestanden op LAN-snelheid worden geleverd; ‘cold’ bestanden worden on-demand vanuit S3 gestreamd.

De cache is het centrale punt van de appliance. Reads voor ‘hot’ data worden lokaal afgehandeld; writes komen eerst op de lokale schijf terecht en worden asynchroon geüpload. Een veelgemaakte ontwerpfout is de aanname dat ‘S3-backed’ betekent dat elke read een internet-round-trip latency met zich meebrengt — dit is niet het geval, mits de werkset in de cache past. Omgekeerd leidt een te kleine cache tot constante cache misses en lijkt de workload ’traag’. Vuistregel: cache = 20% van de totale dataset of 100% van de ‘hot’ werkset, welke van de twee groter is.

De Cached-versus-Stored-valkuil verdient speciale aandacht. De Cached-modus bewaart de primaire kopie in S3 met ‘hot’ blokken lokaal — goedkoop, elastisch, maar een cache miss is een WAN round trip. De Stored-modus bewaart de primaire kopie op de lokale schijf met asynchrone snapshots naar S3 als EBS-snapshots — elke read is lokaal en low-latency, maar de volledige dataset moet on-prem passen. Voor een back-upvervangingsvereiste van “lokale toegang tot alle data terwijl er een back-up van wordt gemaakt op AWS”, is Stored de juiste keuze; Cached zou aan deze eis niet voldoen. Kiezen voor Cached voor een workload die de volledige dataset met lage latency nodig heeft, gaat in tegen het ontwerp; kiezen voor Stored wanneer de locatie niet de volledige dataset kan hosten, is per definitie onmogelijk.

Tape Gateway is het antwoord op een zeer specifieke vraag: het uitfaseren van een fysieke tape library terwijl de workflows van Veeam, NetBackup of Commvault intact blijven door een VTL via iSCSI te presenteren, waarbij data via een lifecycle-beleid van S3 naar Glacier of Deep Archive wordt verplaatst. Het is van onschatbare waarde wanneer wettelijke bewaartermijnen zijn gedefinieerd in termen van tapemedia en de bestaande back-upsoftware niet kan worden gewijzigd.

AWS Transfer Family

Transfer Family biedt volledig beheerde SFTP-, FTPS-, FTP- en AS2-endpoints die gebruikmaken van S3 of EFS. De waardepropositie is het behoud van protocolcontracten met partners: systemen van leveranciers die bestanden alleen via SFTP versturen, kunnen dit ongewijzigd blijven doen, terwijl de ontvangende kant native S3 is — met lifecycle-beleid, Lambda-triggers en analytics-integratie.

De valkuil hier is de aanname dat een legacy-leverancier ‘zomaar kan overstappen op S3 API’s’. Veel systemen van leveranciers zijn appliances, HL7-feeds van ziekenhuizen, batchsystemen van banken of B2B EDI-pijplijnen waarvan de SFTP-client is ingebakken in firmware of ondertekende binaries. De kosten voor change management, security reviews en hercertificering om deze aan te passen, overstijgen vaak de kosten van de volledige AWS-migratie. Transfer Family omzeilt dit volledig. AS2-ondersteuning maakt bovendien EDI-workloads mogelijk met MDN-ontvangstbewijzen en ondertekening/versleuteling van berichten voor B2B-compliance.

Authenticatie ondersteunt door de service beheerde gebruikers, AWS Directory Service (Managed Microsoft AD of AD Connector voor on-prem AD), of een aangepaste identity provider via API Gateway/Lambda — waardoor bestaande bedrijfscredentials de ‘source of truth’ kunnen blijven. Een Lambda-authorizer kan per gebruiker IAM-rollen, home directory-mappings en sessiebeleid retourneren, wat isolatie per leverancier mogelijk maakt zonder infrastructuur per leverancier.

Type: AWS::Transfer::Server
Properties:
  Protocols: [SFTP]
  IdentityProviderType: AWS_DIRECTORY_SERVICE
  IdentityProviderDetails:
    DirectoryId: d-9067f4a1c2
  Domain: S3
  EndpointType: VPC
  EndpointDetails:
    VpcId: vpc-0abc123
    SubnetIds: [subnet-0a, subnet-0b]
    SecurityGroupIds: [sg-0sftp]

Amazon AppFlow

AppFlow is de beheerde integratielaag voor dataverplaatsing van SaaS naar AWS: Salesforce, ServiceNow, Google Analytics, Slack, Marketo, SAP OData, Zendesk en tientallen andere die naar S3, Redshift of Snowflake stromen. Het regelt paginering, incrementele extractie, field mapping, filtering, maskering en validatie zonder een handmatig gebouwde ETL-taak.

De veiligheidskritische functie is PrivateLink-integratie voor ondersteunde connectors (met name Salesforce). In plaats van dat het verkeer via het openbare internet naar de SaaS-tenant en terug naar AWS gaat, loopt de flow via een private VPC-endpoint — waardoor de blootstelling van extract-payloads aan het openbare internet wordt geëlimineerd en de audit-positie voor workloads in de gezondheidszorg, financiële sector en met PII wordt vereenvoudigd. Flows kunnen worden ingepland, getriggerd door gebeurtenissen bij wijzigingen in SaaS-records, of op aanvraag worden uitgevoerd, en ondersteunen tot 100 GB per flow-uitvoering.

AppFlow opereert op een hoger niveau dan DataSync of Storage Gateway: het is de juiste tool wanneer de bron een API-gestuurde SaaS is, en niet een bestandssysteem of database.

Databasemigratie: DMS en SCT

AWS Database Migration Service repliceert data tussen bron- en doel-databases terwijl de brondatabase volledig operationeel blijft. Het ondersteunt homogene (MySQL → RDS MySQL, Oracle → RDS Oracle) en heterogene (Oracle → Aurora PostgreSQL, SQL Server → MySQL) migraties, en de doelen omvatten meer dan alleen RDS, zoals Aurora, Redshift, S3, DynamoDB en Kinesis. Bronnen zijn onder andere Oracle, SQL Server, MySQL, PostgreSQL, MongoDB en Db2.

Een taak werkt in een van de drie modi:

De motor achter een ‘cutover’ met minimale downtime is Change Data Capture. Tijdens een ‘full-load-plus-CDC’ kopieert DMS bestaande rijen in bulk terwijl het transactielogboek van de bron wordt geanalyseerd — Oracle redo, MySQL binlog, SQL Server MS-CDC of MS-Replication. Zodra de volledige lading is voltooid, past CDC de wijzigingen in de wachtrij toe en houdt het doel continu up-to-date totdat de applicatie wordt omgezet. Het niet inschakelen van CDC wanneer de applicatie schrijfbaar moet blijven, is een veelvoorkomende architecturale fout: een ‘full-load-only’ zorgt ervoor dat het doel verouderd is op het moment dat de lading voltooid is.

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

Voor heterogeen werk vertaalt de AWS Schema Conversion Tool (of de cloud-variant DMS Schema Conversion) DDL, stored procedures, views en functies, en markeert het items die handmatige aanpassingen vereisen. DMS verplaatst data; SCT converteert het schema. Het overslaan van het SCT-assessmentrapport is hoe migraties drie dagen voor de ‘cutover’ mislukken.

Motorspecifieke vereisten en beperkingen kunnen hard aankomen als ze worden genegeerd. Oracle LOB’s groter dan 64 KB vereisen limited LOB mode met een vast maximum; LONG RAW heeft kanttekeningen. PostgreSQL vereist wal_level=logical en een replicatierol. MySQL vereist binary logging in ROW-formaat met voldoende binlog_row_image en verhoogde CDC-rechten (REPLICATION CLIENT, REPLICATION SLAVE). Oracle Spatial, RAC-specifiek gedrag en SQL Server CLR-assemblies worden vaak niet ondersteund. TLS wordt afgedwongen tussen de replicatie-instance en de endpoints, met SSL-modi require, verify-ca of verify-full.

DMS Serverless is de juiste keuze wanneer het workloadprofiel onvoorspelbaar of piekerig is — bijvoorbeeld een on-premise Oracle-systeem met pieken overdag en rustige nachten. U definieert MinCapacityUnits en MaxCapacityUnits in DCU’s (DMS Capacity Units) en DMS schaalt de replicatiecapaciteit op basis van CPU- en geheugendruk:

ReplicationConfigIdentifier: oracle-to-rds-cdc
ReplicationType: full-load-and-cdc
SourceEndpointArn: arn:aws:dms:...:endpoint:oracle-onprem
TargetEndpointArn:  arn:aws:dms:...:endpoint:rds-oracle
ComputeConfig:
  MinCapacityUnits: 4
  MaxCapacityUnits: 64
  MultiAZ: true

Een veelvoorkomende valkuil is de aanname dat een ‘provisioned’ DMS-instance (bijv. dms.c5.4xlarge) automatisch zal schalen. Dat zal niet gebeuren — ‘provisioned’ instances zijn EC2-hosts met een vaste grootte. Als de doorvoersnelheid de capaciteit overschrijdt, neemt de replicatievertraging toe en moet u handmatig de instance class aanpassen, waarbij de taken opnieuw worden opgestart. Provisioned DMS is geschikt voor migraties met een stabiele, bekende doorvoersnelheid; Serverless is geschikt voor onvoorspelbare migraties.

Voor een MySQL-migratie van 20 TB met een venster van twee weken en krappe downtime, is DMS met ‘full-load plus CDC’ naar Aurora MySQL of RDS MySQL de meest kosteneffectieve aanpak. Native mysqldump/mysqlpump restores veroorzaken onaanvaardbare downtime; Snowball voegt verzendvertraging en offline periodes toe.

DMS Fleet Advisor ontdekt on-premise database-inventarissen, wat nuttig is voor ‘wave planning’.

Servermigratie: AWS Application Migration Service (MGN)

AWS Application Migration Service is de primaire service voor lift-and-shift (“rehost”) en heeft CloudEndure Migration en Server Migration Service voor de meeste use-cases vervangen. MGN installeert een lichtgewicht AWS Replication Agent op elke bronserver (fysiek, VMware, Hyper-V of een andere cloud). De agent voert een initiële snapshot op blokniveau uit naar een goedkope staging area in de doel-VPC — kleine T3-instances met gekoppelde EBS-volumes — en repliceert vervolgens continu en asynchroon wijzigingen op blokniveau. Omdat de replicatie op blokniveau en continu is, duurt een cutover slechts enkele minuten: MGN converteert de staging-volumes op het moment van de cutover naar productie-EC2-instances van het beoogde instance-type.

1. Install replication agent on each source (or use agentless for vCenter)
2. Configure launch template (instance type, subnet, IAM role, tags)
3. Run "Test" launches → validate → "Cutover" launch → decommission source

Test-launches zijn essentieel en worden vaak overgeslagen. MGN start geïsoleerde test-instances op vanuit de huidige replicatiestatus zonder de lopende replicatie te verstoren. U valideert het gedrag van de applicatie, verwerpt de test, itereert, en start de cutover pas als de tests slagen — de cutover stopt de replicatie, start de definitieve instance en markeert de migratiegolf als voltooid.

De verkeerde aanpak is het handmatig exporteren van VM’s naar OVF, uploaden via aws ec2 import-image, en het opnieuw installeren van applicaties op nieuw geprovisioneerde EC2-instances. Dit is traag, foutgevoelig, vereist per VM een downtime die gelijk is aan de duur van de export, biedt geen delta-replicatie en geen mogelijkheid tot niet-verstorende tests. MGN elimineert dit allemaal — de bron blijft draaien tot de laatste seconde van de cutover, en de ‘drift’ tussen bron en doel is nagenoeg nul.

Het algemene portfolio-advies is om eerst te ‘rehosten’, en daarna te ’re-platformen’ of ‘refactoren’ binnen de Region waar de iteratiekosten lager zijn. Gelijktijdig refactoren en migreren vermenigvuldigt het risico zonder compenserend voordeel.

Hybride Connectiviteit: Direct Connect en VPN

AWS Direct Connect levert een dedicated Layer 2-circuit van een on-prem router naar een Direct Connect-locatie, en biedt consistente bandbreedte (1, 10, 100 Gbps dedicated; sub-1 Gbps via ‘partner hosted connections’) en voorspelbare latency. Virtual Interfaces (VIFs) verdelen het circuit:

• Private VIF — toegang tot één enkele VPC via een Virtual Private Gateway.
• Transit VIF — toegang tot meerdere VPC’s via een Direct Connect Gateway die gekoppeld is aan een Transit Gateway. Dit is het canonieke patroon voor grote omgevingen met meerdere VPC’s en meerdere sites.
• Public VIF — toegang tot publieke AWS-service-endpoints (S3, DynamoDB) zonder het internet te gebruiken.

DX is op zichzelf niet highly available: een enkel circuit op een enkele DX-locatie is afhankelijk van een enkel glasvezelpad. Twee veerkrachtpatronen zijn van belang:

1. DX + Site-to-Site VPN-backup via het internet is de minimaal levensvatbare HA. BGP regelt de automatische failover met AS-path prepending, MED of local-pref om in de stabiele toestand de voorkeur te geven aan DX.
2. Dubbele DX-circuits op afzonderlijke DX-locaties is het patroon met maximale veerkracht voor bedrijfskritische workloads en is vereist voor de DX SLA.

Het niet voorzien van enig back-uppad is een bekende valkuil: wanneer DX uitvalt en er geen VPN is, lopen hybride apps, DataSync-jobs en Storage Gateway-uploads allemaal vast voor de duur van de reparatie door de provider. Een pure VPN-oplossing is acceptabel voor workloads met een lagere doorvoersnelheid of als overbrugging terwijl DX wordt aangelegd, wat weken kan duren.

On-prem Router ──── DX (primary, BGP MED=100) ────┐
                                                   ├── VGW/DXGW ── VPC
On-prem Router ──── VPN over Internet (backup) ────┘

# Multi-VPC access via DX Gateway
DirectConnectGateway:
  Associations:
    - TransitGateway: tgw-corp
    - VirtualPrivateGateway: vgw-prod-vpc
  AllowedPrefixes:
    - 10.0.0.0/8

Waar encryptie op de fysieke laag verplicht is, kies dan voor een MACsec-enabled DX-verbinding. De combinatie van DX voor bandbreedte, DataSync voor orkestratie en Storage Gateway voor continue lokale toegang is het canonieke hybride patroon voor grote, live datasets die geen downtime-venster kunnen tolereren.

AWS Outposts voor On-Prem AWS-Infrastructuur

Outposts breidt de AWS-infrastructuur uit naar een klantlocatie als een volledig beheerd rack (of 1U/2U Outposts-servers). Het draait lokaal een gecureerde set services — EC2, EBS, ECS, EKS, RDS, S3 on Outposts, EMR — met dezelfde API’s als de bovenliggende Region. Control-plane-operaties lopen terug naar de bovenliggende Region via een service link van redundante, versleutelde tunnels; een WAN-storing voorkomt tijdelijk het starten van nieuwe instances, maar stopt de draaiende workloads niet.

De verdeling van de gedeelde verantwoordelijkheid is de valkuil voor operators. AWS levert en onderhoudt de hardware, de hypervisor en de beheerde services. De klant is verantwoordelijk voor:

• Fysieke ruimte, stroom, koeling en netwerkvoorzieningen die voldoen aan de Outposts-specificaties (redundante stroomtoevoer, upstream switches, geschikte PDU’s).
• Fysieke beveiliging van de faciliteit.
• Lokale netwerkconfiguratie — de Local Gateway (LGW) voor on-prem verkeer en de service link-uplink.
• OS- en applicatie-aangelegenheden van workloads, precies zoals in de Region.
• Adequate WAN-connectiviteit terug naar de bovenliggende Region.

Outposts elimineert de operationele taken niet — het verschuift de abstractie. Aannemen dat AWS verantwoordelijk is voor de stroomvoorziening van het datacenter of het upstream-netwerk is een fundamentele misvatting. Het is ook niet “elke AWS-service on-prem draaien”: de lijst met ondersteunde services is eindig, en services zoals Route 53 of IAM blijven Region-gebaseerd.

Voor een Hadoop/Spark-modernisering waarbij data om regelgevende redenen on-premise moet blijven, is EMR on Outposts het juiste patroon — beheerde, elastische Spark-clusters met in-Region tooling en lokale dataresidentie. Storage Gateway of DataSync voldoen niet aan de eis van dataresidentie; een lift-and-shift naar EMR in de Region voldoet niet aan de compliance.

Content Distribueren naar Edge Fleets

Wanneer Outposts-servers, winkels of edge-apparaten herhaaldelijk dezelfde grote payload ophalen — bijvoorbeeld een nachtelijke softwarerelease — verzadigt het rechtstreeks ophalen uit een S3-bucket in één enkele regio de uplinks en verlengt het de implementatietijd. Het correcte patroon is CloudFront met een S3-origin en signed URLs:

S3 bucket (ap-northeast-1)  ← Origin Access Control
        │
   CloudFront distribution (global edge PoPs)
        │
   Signed URLs (short expiry, per-server or per-release)
        │
   Edge devices download from nearest PoP

Het eerste apparaat in een regio warmt de edge-cache op; elk volgend apparaat haalt de data op met edge-latency. Signed URLs voorkomen ongeautoriseerde downloads zonder dat er per apparaat IAM-credentials nodig zijn, en er is geen vloot van regionale replica’s om te beheren.

Twee anti-patronen die je moet vermijden: de release hosten op een enkele EC2-webserver (een ramp voor schaalbaarheid en latency), en de S3-bucket repliceren naar elke regio via Cross-Region Replication alleen om de downloadlatency te verminderen (onnodige opslagkosten en operationele complexiteit die CloudFront-caching gratis oplost).

Beslissingsoverzicht

← Opslag · Alle domeinen · Netwerken →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Amazon →