Amazon SAA-C03: Opslag & Datalevenscyclus — 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.

S3-opslagklassen en het spectrum van kosten/latentie

S3-opslagklassen bevinden zich op een spectrum waarbij de ophaallatentie, minimale opslagduur en ophaalkosten per GB worden afgewogen tegen de opslagkosten per GB. De juiste keuze maken is de belangrijkste hefboom voor kostenoptimalisatie bij object storage.

S3 Standard is de standaard: ’eleven-nines’ duurzaamheid over drie of meer AZ’s, latentie van milliseconden, geen ophaalkosten, hoogste prijs per GB. Standard-IA en One Zone-IA verlagen de opslagkosten met ongeveer 40-50%, maar voegen ophaalkosten per GB toe, een minimale factureerbare duur van 30 dagen en een minimale objectgrootte van 128 KB (kleinere objecten worden gefactureerd als 128 KB, wat de besparing tenietdoet). One Zone-IA verlaagt de kosten verder door opslag in een enkele AZ - alleen geschikt voor reproduceerbare secundaire kopieën waarbij het verlies van een enkele AZ aanvaardbaar is.

S3 Intelligent-Tiering is de juiste keuze wanneer toegangspatronen onbekend, onvoorspelbaar of wisselend zijn voor een grote hoeveelheid data. Het migreert objecten automatisch tussen frequent, infrequent, archive-instant, archive en deep-archive tiers op basis van waargenomen toegang, en brengt hiervoor een kleine monitoringkost per object in rekening. Omdat er geen ophaalkosten zijn tussen de frequent en infrequent tiers en geen minimale duur, is dit de veiligste standaardkeuze voor data lakes en gemengde workloads met objecten ≥128 KB. Het is de verkeerde keuze wanneer je al weet dat objecten permanent ‘hot’ zijn (extra monitoringkosten) of een decennium lang permanent ‘cold’ (Deep Archive is veel goedkoper).

Glacier Instant Retrieval biedt toegang in milliseconden tegen archiefprijzen voor data die per kwartaal of minder vaak wordt benaderd - medische beelden, compliance-PDF’s die onmiddellijk moeten worden geproduceerd wanneer daarom wordt gevraagd. Glacier Flexible Retrieval biedt ophaaltijden van minuten tot uren. Glacier Deep Archive is de goedkoopste tier in AWS met ongeveer $1/TB/maand, met een standaard ophaaltijd van 12 uur (of 48 uur voor bulk) en een minimum van 180 dagen - het juiste antwoord voor 7-10 jaar wettelijke bewaarplicht en als vervanging voor tape.

De twee meest voorkomende kostenvalkuilen zijn tegenovergestelde fouten. Het selecteren van Standard voor data die langdurig zelden wordt gelezen, verspilt geld omdat Standard geen prijsvoordeel biedt voor ‘cold storage’ - een dataset van 5 TB die jarenlang in Standard wordt bewaard, kost meerdere keren meer dan dezelfde data in Deep Archive. Omgekeerd is het direct plaatsen van gloednieuwe objecten in Standard-IA of Glacier een valkuil, omdat de minimale kosten voor 30/90/180 dagen plus de ophaalkosten de besparingen overtreffen wanneer objecten nog ‘hot’ zijn. Glacier Flexible of Deep Archive zijn ook ronduit onverenigbaar met elke workload die een synchrone leesbewerking verwacht - een gebruiker die wacht op een HTTP GET kan een ophaal-SLA van minuten tot 12 uur niet tolereren. Glacier Instant Retrieval is de enige Glacier-tier die compatibel is met onmiddellijke toegang.

Lifecycle Policies en versiebeheer

Een lifecycle-configuratie is declaratieve JSON/YAML die aan een bucket is gekoppeld en die objecten overzet of laat verlopen op basis van leeftijd, tag of prefix. Transities worden eenmaal per dag geëvalueerd en worden pas uitgevoerd nadat de opgegeven leeftijd is bereikt - een Days: 30-transitie betekent dat Standard-tarieven van toepassing zijn voor de eerste 30 dagen. Transities moeten naar steeds koudere tiers gaan, en objecten kleiner dan 128 KB worden niet overgezet van Standard naar IA omdat de per-object overhead zwaarder weegt dan de besparingen; consolideer kleine objecten eerst via tar/zip of S3 Batch Operations.

Een standaard policy voor een workload die 30 dagen ‘hot’ is, daarna ‘cold’, maar gedurende de hele periode onmiddellijke toegang vereist, vier jaar wordt bewaard, met de juiste hygiëne:

Rules:
  - ID: archive-and-clean
    Status: Enabled
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 180
        StorageClass: DEEP_ARCHIVE
    NoncurrentVersionTransitions:
      - NoncurrentDays: 30
        StorageClass: GLACIER
    NoncurrentVersionExpiration:
      NoncurrentDays: 365
    Expiration:
      Days: 1460
    AbortIncompleteMultipartUpload:
      DaysAfterInitiation: 7

Een veelvoorkomende valkuil bij versiebeheer: in een bucket met versiebeheer voegt een lifecycle-regel die huidige objecten laat verlopen, slechts delete markers toe; eerdere versies stapelen zich stilletjes op en blijven kosten genereren. Niet-huidige versies vereisen hun eigen expliciete NoncurrentVersionTransitions en NoncurrentVersionExpiration. Neem ook altijd AbortIncompleteMultipartUpload op - achtergebleven onderdelen van multipart uploads zijn onzichtbaar in de console-lijst en blijven voor onbepaalde tijd opslagkosten genereren.

Voor gemengde patronen - zeg, IoT-telemetrie die de eerste maand ‘hot’ is voor ML-training, daarna een jaar lang per kwartaal wordt opgevraagd, en vervolgens wordt gearchiveerd - is het juiste antwoord Intelligent-Tiering voor het eerste jaar (waarbij de klasse automatisch optimaliseert tussen trainingspieken en inactieve dagen), gevolgd door een geplande transitie naar Deep Archive op dag 365.

Versioning, MFA Delete en Object Lock

Eenmaal ingeschakeld, kan versioning alleen nog worden opgeschort (suspended); het kan niet worden uitgeschakeld. Elke PUT creëert een nieuwe versie-ID; een DELETE plaatst een ‘delete marker’ in plaats van de data te verwijderen. Versioning beschermt tegen onbedoeld overschrijven, maar is geen onveranderlijkheid (immutability): elke principal met s3:DeleteObjectVersion kan een specifieke versie permanent verwijderen. MFA Delete voegt de vereiste toe dat het root-account een MFA-token moet aanbieden om versies permanent te verwijderen of de status van versioning te wijzigen. Dit dicht het risico op onbedoeld verwijderen voor waardevolle buckets, maar voorkomt nog steeds niet dat een geautoriseerde actor data kan vernietigen.

Echte onveranderlijkheid vereist S3 Object Lock, wat versioning vereist en doorgaans bij het aanmaken van de bucket moet worden ingeschakeld. Het heeft twee modi die vaak door elkaar worden gehaald:

Retentie kan per object worden toegepast (Retain-Until-Date) of via een Legal Hold, die geen vervaldatum heeft. Voor boekhouddocumenten die één jaar ‘hot’ moeten zijn, negen jaar gearchiveerd, en tien jaar lang niet verwijderd mogen worden, is het juiste patroon Object Lock in Compliance-modus met een retentie van tien jaar, gecombineerd met een lifecycle-transitie naar Deep Archive op dag 365. Governance is geen acceptabel substituut voor een wettelijke verplichting — een toezichthouder zal “iemand met permissies had dit kunnen verwijderen” niet accepteren als onveranderlijkheid.

Om retentie toe te passen op een bestaande verzameling PDF’s in een enkele taak, gebruik je S3 Batch Operations, aangestuurd door een S3 Inventory-manifest. Batch Operations is het beheerde antwoord voor grootschalige mutaties — retentie, tagging, PUT-copy her-encryptie, Lambda-aanroepen — over miljarden keys; handgeschreven iteratiescripts zijn niet het juiste patroon.

Encryptie: SSE-S3, SSE-KMS en Bucket Keys

Elke bucket heeft standaard encryptie. SSE-S3 (AES-256, door S3 beheerde sleutels) is gratis en vereist geen sleutelbeheer. SSE-KMS gebruikt een KMS customer master key, wat per-sleutel CloudTrail-audittrails, op IAM gebaseerd sleutelbeleid en controle over sleutelrotatie mogelijk maakt — tegen de kosten van KMS API-aanroepen en, nog belangrijker, KMS request throttling dat een bottleneck kan vormen voor lees-workloads met hoge doorvoer. Kies SSE-KMS wanneer je die controles daadwerkelijk nodig hebt (regelgevende attestatie, scheiding van taken, delen van sleutels tussen accounts). Standaard voor SSE-KMS kiezen “voor de zekerheid” voegt onnodige kosten en complexiteit toe wanneer SSE-S3 aan de vereisten voldoet.

S3 Bucket Keys pakken de kosten van SSE-KMS-requests aan. S3 genereert een kortstondige sleutel op bucket-niveau vanuit de CMK en leidt lokaal per-object datasleutels af, waardoor een KMS GenerateDataKey/Decrypt-aanroep per object wordt vermeden en de KMS-requestkosten tot 99% worden verlaagd:

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

Overschakelen naar SSE-S3 om “KMS-kosten te vermijden” is de verkeerde workaround wanneer de vereisten KMS verplichten — Bucket Keys voldoen aan zowel compliance- als kostendoelstellingen zonder KMS op te geven.

Het inschakelen van standaard bucket-encryptie zorgt ervoor dat alle toekomstige uploads versleuteld zijn (niet-versleutelde PUTs worden transparant versleuteld). Om niet-versleutelde PUTs volledig te weigeren, weiger schrijfacties die de header missen:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

Standaard encryptie doet niets met bestaande, niet-versleutelde objecten. Her-versleutel ze via S3 Inventory + Batch Operations die een Copy-taak uitvoeren die elke key ‘in place’ overschrijft — het standaardpatroon voor bulk-her-encryptie.

Ad-hoc client-side encryptie is inferieur aan standaard encryptie plus KMS: het verspreidt sleutelbeheer over applicatieteams, kan niet centraal worden geaudit via CloudTrail KMS-events en kan geen Bucket Keys gebruiken.

Cross-Region Replication en Multi-Region KMS Keys

Cross-Region Replication (CRR) kopieert objecten asynchroon naar een bucket in een andere regio voor compliance, DR of latency. Same-Region Replication (SRR) dient voor compliance-scheiding, log-aggregatie en kopieën tussen accounts. Beide vereisen versioning op de bron- en doelbucket en een IAM-rol die de bronbucket aanneemt (assume). CRR is het antwoord met weinig inspanning wanneer een bucket naar een andere regio moet worden gespiegeld — het scripten van aws s3 sync, het koppelen van Lambdas aan ObjectCreated, of het uitvoeren van geplande batchkopieën introduceert operationele overhead, race conditions en stille fouten. Noch CRR, noch SRR repliceert standaard bestaande objecten; gebruik S3 Batch Replication voor backfills.

Interacties met encryptie zijn waar ontwerpen vaak mislukken:

• SSE-S3-objecten repliceren transparant.
• SSE-KMS-objecten worden niet standaard gerepliceerd — je moet expliciet ‘opt-in’ doen, een doel-KMS-sleutel in de doelregio specificeren en de replicatierol kms:Decrypt op de bronsleutel en kms:Encrypt op de doelsleutel verlenen. Een single-Region-sleutel kan geen objecten in een andere regio versleutelen.
• Client-side-encrypted objecten repliceren als ondoorzichtige ciphertext; de doelregio heeft er niets aan, tenzij het sleutelmateriaal van de client daar beschikbaar is.

De historische frictie van het beheren van twee onafhankelijke CMK’s wordt opgelost door AWS KMS multi-Region keys, die hetzelfde sleutelmateriaal en dezelfde key-ID (met een regio-prefix) in meerdere regio’s presenteren. Een gerepliceerd object kan dan in de doelregio worden gedecrypt zonder cross-region KMS-aanroepen en zonder de datasleutel opnieuw te ‘wrappen’. Dit is het canonieke patroon voor versleutelde, gerepliceerde buckets die bruikbaar moeten blijven bij een regionale failover.

Het delen van snapshots en objecten tussen accounts onder een door de klant beheerde KMS-sleutel vereist dat de principals van het doelaccount kms:Decrypt, kms:CreateGrant, kms:DescribeKey en kms:ReEncrypt* op de bronsleutel bezitten via een key policy, plus overeenkomstige IAM-permissies. Door AWS beheerde sleutels (bijv. aws/ebs, aws/s3) kunnen niet tussen accounts worden gedeeld, dus door de klant beheerde sleutels zijn verplicht voor cross-account workflows.

Block Public Access en Toegang Beperken tot CloudFront

S3 Block Public Access (BPA) heeft vier instellingen — nieuwe publieke ACL’s blokkeren, bestaande publieke ACL’s negeren, nieuwe publieke bucket policies blokkeren, publieke bucket policies beperken — die configureerbaar zijn per bucket en, nog belangrijker, op accountniveau. BPA op accountniveau heeft voorrang op elke bucket policy die publieke toegang zou verlenen en is de juiste controlemaatregel voor “geen enkel object in dit account mag publiek zijn”. Bucket policies alleen zijn kwetsbaar: een nieuwe bucket kan zonder policy worden gestart; BPA op accountniveau is ‘fail-closed’ (blokkeert standaard).

Om te voorkomen dat een beheerder in een member-account BPA uitschakelt, pas je een Service Control Policy toe op de Organizations OU of root:

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

Om S3-content uitsluitend via CloudFront te serveren, koppel je een Origin Access Control (OAC) — de moderne vervanging voor de verouderde OAI — aan de distributie en beveilig je de bucket policy op basis van de ARN van de distributie:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E123"
    }
  }
}

BPA blijft ingeschakeld op de bucket. Voor tijdelijk beperkte toegang tot private objecten door een specifieke gebruiker (verlooptijd voor upload/download), genereer je een presigned URL. De ingebedde handtekening hiervan erft de permissies van de principal die de URL heeft ondertekend.

Private Netwerkpaden: Gateway Endpoints

EC2-naar-S3-verkeer binnen een VPC gebruikt niet automatisch de private backbone van AWS. Zonder configuratie worden S3 API-calls omgezet naar publieke endpoints en lopen ze via de internet gateway of NAT gateway. Dit brengt kosten voor NAT-dataverwerking met zich mee en stelt het verkeer bloot aan het internet. Een gateway VPC endpoint voor S3 (en DynamoDB) is gratis, wordt toegevoegd als een prefix-list route in gespecificeerde route tables en houdt het verkeer op het AWS-netwerk. Interface endpoints (PrivateLink) voor S3 bestaan ook en zijn betalend; deze zijn nuttig wanneer de toegang afkomstig is van on-premises via Direct Connect. Koppel het endpoint aan een bucket policy met de aws:SourceVpce condition om af te dwingen dat de bucket alleen bereikbaar is vanaf goedgekeurde VPC-endpoints — het standaardpatroon voor gereguleerde workloads.

Object Lambda voor On-the-Fly Transformatie

S3 Object Lambda voegt een Lambda-functie in het GET/HEAD/LIST-pad in, zodat het object dat aan de aanvrager wordt geretourneerd, tijdens het lezen wordt getransformeerd. Dit voorkomt het dupliceren van data voor elke variant (geredigeerd, van formaat veranderd, opnieuw geformatteerd) en handhaaft één ‘source of truth’ in de onderliggende bucket. Typische toepassingen: PII-redactie voor analisten versus volledige data voor auditors, watermerken van afbeeldingen per gebruiker, XML-naar-JSON-conversie voor legacy clients. IAM- en bucket policies beveiligen nog steeds het onderliggende object; de Lambda-functie ziet alleen wat de bijbehorende execution role toestaat.

Event Notifications

S3 verstuurt events (s3:ObjectCreated:*, s3:ObjectRemoved:*, replicatie- en lifecycle-events) naar Lambda, SQS, SNS of EventBridge. EventBridge heeft de voorkeur wanneer je meerdere targets, filtering op object-metadata of cross-account routing nodig hebt; directe notificaties zijn eenvoudiger en goedkoper voor single-target pipelines, zoals het genereren van thumbnails bij een upload. Notificaties zijn ‘at-least-once’, dus de consumers moeten idempotent zijn.

Doorvoeroptimalisatie: Multipart Upload en Transfer Acceleration

Voor objecten groter dan 100 MB is multipart upload een best practice; boven de 5 GB is het verplicht. De delen worden parallel geüpload, mislukte delen worden onafhankelijk opnieuw geprobeerd en de doorvoer schaalt met de concurrency. Byte-range GETs bieden vergelijkbaar parallellisme bij downloads. Zoals eerder vermeld, voeg altijd een AbortIncompleteMultipartUpload lifecycle-regel toe om te voorkomen dat je betaalt voor achtergebleven (orphaned) delen.

S3 Transfer Acceleration leidt uploads via de dichtstbijzijnde CloudFront edge over de backbone van AWS — gebruik dit voor wereldwijd verspreide clients die naar één enkele bucket uploaden. Voor downloads plaats je CloudFront vóór S3 om te cachen aan de edge. Transfer Acceleration is gericht op uploads; CloudFront is gericht op downloads; ze lossen gerelateerde maar verschillende problemen op.

EBS: Volumetypes, Encryptie en Snapshots

EBS-volumes zijn AZ-scoped block devices die aan één enkele EC2-instance gekoppeld zijn. gp3 is de standaard general-purpose SSD; het cruciale voordeel ten opzichte van gp2 is dat IOPS (tot 16.000) en throughput (tot 1.000 MiB/s) onafhankelijk van de capaciteit worden geprovisioneerd. Dit elimineert het gp2-antipattern waarbij opslag overgeprovisioneerd wordt enkel om prestatiedoelen te halen. io2 Block Express levert tot 256.000 IOPS met een latency van minder dan een milliseconde voor latency-gevoelige databases. st1 en sc1 zijn HDD-gebaseerd voor throughput-georiënteerde sequentiële en ‘cold’ workloads. Multi-Attach op io1/io2 bestaat, maar is beperkt tot 16 instances in dezelfde AZ die een cluster-aware filesystem draaien — een zeldzame uitzondering, geen algemeen ‘shared EBS’-patroon. Proberen om EBS breed te koppelen over meerdere instances (bijvoorbeeld achter een load balancer) is een categoriefout die precies het symptoom ‘sommige documenten zichtbaar na een refresh, andere niet’ veroorzaakt, omdat elk volume een privé block device is.

EBS-volumes versleutelen data at rest met AES-256 door gebruik te maken van data keys die door KMS worden ‘gewrapt’. Encryptie is transparant — geen prestatieverlies, geen aanpassingen aan de applicatie. Zodra een volume versleuteld is, zijn afgeleide snapshots en volumes ook versleuteld; je kunt het niet ter plekke ontsleutelen. Activeer EBS encryption by default per regio, zodat elk nieuw volume en elke nieuwe snapshot versleuteld wordt, ongeacht of de ontwikkelaar eraan denkt:

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

Bestaande, niet-versleutelde volumes worden niet met terugwerkende kracht versleuteld — herstel vereist een snapshot, een kopie met encryptie, en het aanmaken van een volume vanuit de versleutelde snapshot.

Snapshots zijn incrementele back-ups op block-niveau die worden opgeslagen op door S3 beheerde infrastructuur — maar ze zijn niet gratis (je betaalt voor de behouden gewijzigde blocks), ze verdwijnen niet wanneer het bronvolume wordt verwijderd, en ze worden niet verwijderd wanneer een AMI die ernaar verwijst, wordt gederegistreerd. Verplaats ze na verloop van tijd naar de EBS Snapshots Archive tier (75% goedkoper, 24–72 uur hersteltijd) via aws ec2 modify-snapshot-tier, Amazon Data Lifecycle Manager (DLM) of AWS Backup. Fast Snapshot Restore (FSR) ‘warmt’ een snapshot vooraf op in specifieke AZ’s, zodat instances die ervan worden gestart onmiddellijk volledige prestaties leveren — activeer dit voor AMI’s achter autoscaling groups die snelle scale-out moeten kunnen verwerken.

Recycle Bin vangt verwijderde EBS-snapshots en AMI’s op in een herstelvenster (1 dag tot 1 jaar). Zonder dit is het verwijderen van een snapshot onmiddellijk en permanent:

aws rbin create-rule \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --resource-type EBS_SNAPSHOT \
  --description "30-day snapshot recovery"

Alleen vertrouwen op dagelijkse EBS-snapshots voor langdurige compliance-retentie is een veelvoorkomende architecturale fout — snapshots hebben een prijs die dichter bij ‘warm storage’ ligt en vereisen expliciete transities naar een archief.

Amazon EFS: Gedeelde POSIX voor Linux-Fleets

EFS is een volledig beheerd, elastisch, POSIX-compliant NFSv4.1-bestandssysteem dat gelijktijdig kan worden gemount vanaf duizenden EC2-, ECS-, EKS- of Lambda-clients verspreid over meerdere AZ’s in een regio, en vanaf on-premises hosts via Direct Connect of VPN. De bepalende eigenschap is dat hetzelfde bestandssysteem, met identieke file handles en semantiek op byte-niveau, voor elke client tegelijk zichtbaar is. EFS is daarom het juiste antwoord wanneer een Linux-fleet achter een load balancer een gemeenschappelijke set bestanden moet delen — uploads van gebruikers, configuratiebestanden, gedeelde home-directories.

Mount targets bevinden zich in elk AZ-subnet dat je configureert. De amazon-efs-utils helper maakt TLS in transit en IAM-autorisatie voor mounts mogelijk:

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

EFS-storage classes omvatten twee dimensies. Lifecycle management verplaatst bestanden die 7–90 dagen niet zijn benaderd van Standard naar Infrequent Access en optioneel naar Archive, wat de opslagkosten tot 92% verlaagt; Intelligent-Tiering verplaatst ze bij toegang weer terug. One Zone-classes slaan data op in één enkele AZ voor ~47% minder — geschikt voor dev/test of reproduceerbare data, nooit voor data waarvan verlies tijdens een AZ-storing onacceptabel is. Een kostenbesparende maatregel voor een workload die al op EFS Standard-IA draait, is overstappen naar EFS One Zone-IA zonder enige aanpassing aan de applicatie.

Prestaties hebben twee onafhankelijke ‘knoppen’. Performance mode (ingesteld bij aanmaak): General Purpose heeft de laagste latency en is correct voor metadata-intensieve web-serving; Max I/O is een verouderde optie die is vervangen door Elastic. Throughput mode: Bursting schaalt met de grootte (50 KB/s per GB baseline, burst credits wanneer onder de baseline), bij Provisioned betaal je voor een vaste MB/s onafhankelijk van de grootte, en Elastic — de huidige standaard — schaalt automatisch tot 10+ GB/s zonder capaciteitsplanning. Een klein bestandssysteem onder aanhoudende belasting kan zijn bursting credits uitputten en terugvallen (throttling) naar een lage baseline. Daarom moeten I/O-intensieve workloads met een kleine omvang Elastic of Provisioned gebruiken.

EFS is geen vervanging voor block storage met hoge IOPS. Elke EFS I/O is een NFS RPC over het netwerk, dus single-writer, sub-milliseconde, transactielog-achtige workloads horen thuis op EBS io2 Block Express — één enkel volume levert 256.000 IOPS met sub-ms latency, wat EFS per operatie niet kan evenaren. EFS is ook extreem duur voor ‘cold data’ vergeleken met Deep Archive; compliance-data op EFS bewaren ‘omdat het makkelijk is’ is onverdedigbaar.

FSx: Windows, Lustre, ONTAP, OpenZFS

FSx is een familie van beheerde bestandssystemen, geselecteerd op basis van protocol en workload:

FSx for Windows File Server levert native SMB 2.0/3.1.1 met NTFS ACLs, DFS Namespaces, schaduwkopieën en Kerberos via Active Directory. Een Multi-AZ-implementatie plaatst een actieve bestandsserver in één AZ met een synchroon gerepliceerde standby in een andere, en één DNS-naam voor failover. AD-integratie is verplicht: FSx moet lid worden van AWS Managed Microsoft AD of een bereikbare, zelfbeheerde AD, en clients authenticeren als domeingebruikers tegen domein-SIDs. Het overslaan van AD, of clients laten verwijzen naar een bestandssysteem in een niet-vertrouwd forest zonder een cross-forest trust, leidt tot het klassieke symptoom van ’toegang geweigerd’ ondanks dat de share zichtbaar is. FSx for Windows is de ‘drop-in’-bestemming voor lift-and-shift van Windows-bestandsshares.

FSx for Lustre is een parallel POSIX-bestandssysteem voor HPC, ML-training, EDA en genomics — duizenden clients, honderden GB/s doorvoersnelheid, sub-ms metadata. De cruciale AWS-feature is de data repository-koppeling met S3: object keys verschijnen als bestanden in de Lustre-namespace en worden ’lazy’ geladen bij de eerste toegang (of vooraf geladen via hsm_restore); nieuwe/gewijzigde bestanden worden op schema of on-demand terug geëxporteerd naar S3. Het canonieke HPC-patroon is:

1. Kopieer on-prem datasets naar S3 (via DataSync of Storage Gateway).
2. Creëer een Lustre-systeem gekoppeld aan die bucket.
3. Mount op alle Spot-workers; lees inputs en schrijf outputs op ’line rate’.
4. Exporteer resultaten naar S3, dat de duurzame opslagplaats voor de lange termijn blijft.
5. Verwijder het Lustre-bestandssysteem wanneer de taak is voltooid.

Scratch-implementaties van Lustre hebben geen replicatie en verliezen data bij hardwarefalen — dit is de goedkoopste en snelste optie, geschikt voor tijdelijke jobdata. Persistent-implementaties repliceren binnen een AZ voor hogere duurzaamheid. De doorvoersnelheid wordt geprovisioneerd in MB/s per TiB (50/125/250/500/1000), waardoor capaciteit van prestaties wordt losgekoppeld.

FSx for NetApp ONTAP is het multi-protocol antwoord: NFS, SMB en iSCSI gelijktijdig op dezelfde data, met snapshots, SnapMirror-replicatie, FlexClones en deduplicatie. Kies ONTAP bij het consolideren van gemengde Linux NFS- en Windows SMB-shares die cross-protocol toegang met Multi-AZ-redundantie vereisen, of bij migratie vanaf on-prem NetApp. FSx for OpenZFS vult een niche voor Linux-workloads die ZFS-features (snapshots, clones) via NFS nodig hebben. Verwar de multi-protocol kracht van ONTAP niet met de andere varianten.

Kies je verkeerd, dan faal je op een duidelijke manier: EBS voor een gedeelde workload, EFS voor een Windows SMB-share, of Lustre voor een AD-geïntegreerde Windows-share zijn allemaal mismatches — match eerst het protocol en het toegangspatroon.

Storage Gateway: Hybride Toegang

Storage Gateway presenteert cloudopslag alsof deze lokaal is. Dit is anders dan DataSync, dat data verplaatst.

Voor een rendering-applicatie die zijn mediabibliotheek naar S3 heeft verplaatst maar nog steeds low-latency reads on-prem nodig heeft, is S3 File Gateway de juiste keuze — NFS/SMB-toegang, lokale cache, en ‘cold’ objecten worden on-demand uit S3 gehaald. FSx File Gateway is de oplossing voor bijkantoren: een LAN-snelheid SMB-cache van een centrale FSx-share in de cloud, niet een oplossing voor gedeelde toegang tussen EC2 instances (die FSx direct zouden moeten mounten). Volume Gateway is van toepassing wanneer de workload block iSCSI gebruikt in plaats van file-semantiek. Tape Gateway vervangt fysieke tape libraries onder bestaande back-upsoftware.

Dataoverdracht en Migratie

AWS DataSync is een agent-gebaseerde online migratiedienst voor NFS, SMB, HDFS en object stores naar S3, EFS of FSx — tot 10× sneller dan open-source tools, met encryptie, integriteitsverificatie, scheduling en behoud van POSIX-metadata en NTFS ACL’s. Voor een grootschalige SMB-migratie met miljoenen kleine bestanden en diepe hiërarchieën is de oplossing met de minste overhead DataSync naar FSx for Windows: SMB blijft behouden, ACLs/timestamps intact, doorvoer van kleine bestanden wordt afgehandeld via parallelle transfers, en er zijn geen applicatiewijzigingen nodig. Zo’n dataset direct naar S3 migreren is een valkuil — object storage gaat slecht om met het listen van kleine bestanden in diepe prefixes en SMB-clients kunnen geen buckets mounten.

AWS Snow Family levert fysieke appliances voor offline dataoverdracht: Snowcone (tot 8 TB, robuust voor edge-locaties), Snowball Edge (tot ~80 TB bruikbaar, met compute-opties), en Snowmobile (op exabyte-schaal). Vuistregel: als een netwerkoverdracht langer dan een week zou duren, is Snowball goedkoper en sneller.

AWS Transfer Family stelt SFTP, FTPS, FTP en AS2 beschikbaar, ondersteund door S3 of EFS — dit is de juiste oplossing wanneer externe partners standaard protocollen voor bestandsoverdracht moeten blijven gebruiken.

AWS Backup, Cross-Region Copy en Vault Lock

AWS Backup centraliseert beleid voor EBS, EFS, FSx, RDS, DynamoDB, S3 en meer. Een back-upplan definieert de planning, retentie in warm storage, de overgang naar cold storage en acties voor kopiëren naar andere regio’s en accounts:

BackupPlan:
  Rules:
    - RuleName: DailyWithDRCopy
      TargetBackupVault: prod-vault
      ScheduleExpression: "cron(0 5 * * ? *)"
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 2555        # 7 years
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:...:backup-vault:dr-vault
          Lifecycle:
            MoveToColdStorageAfterDays: 30
            DeleteAfterDays: 2555

De overgang naar cold storage vereist minimaal 90 dagen retentie in warm storage plus minimaal 90 dagen in cold storage; verkeerd geconfigureerde lifecycles worden afgewezen. Voor wettelijk verplichte retentie van meerdere jaren, combineer dit met AWS Backup Vault Lock (WORM). Dit voorkomt dat zelfs beheerders de retentieperiode kunnen verkorten, wat voldoet aan SEC 17a-4 en vergelijkbare mandaten. Kopiëren naar een andere regio (Cross-Region copy) is voor regionale DR; kopiëren naar een ander account (cross-account copy) pakt ransomware- en insider-threat-scenario’s aan door back-ups te isoleren van de ‘blast radius’ van het productieaccount.

Keuzehulp

← Serverless · Alle domeinen · Dataoverdracht →

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

Blader door Amazon →