Amazon SAA-C03: Contentlevering, Edge & Prestatieoptimalisatie — 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.

Amazon CloudFront: Wat het is en waarom het helpt

Amazon CloudFront is een wereldwijd gedistribueerd content delivery network, gebouwd op meer dan 600 points of presence. De taak ervan is om de TLS-verbinding van de gebruiker te beëindigen op de dichtstbijzijnde edge-locatie en ofwel direct gecachte antwoorden te serveren, ofwel cache misses via de private backbone van AWS naar de origin te proxyen. Het prestatievoordeel is tweeledig: cache hits reduceren de round-trip time tot enkele milliseconden en ontlasten de origin volledig, terwijl cache misses nog steeds profiteren van geoptimaliseerde TLS/TCP-beëindiging aan de edge, ondersteuning voor HTTP/2 en HTTP/3, hergebruik van keep-alive-verbindingen naar de origin, en backbone-transport dat het rumoerige publieke internet vermijdt.

Een veelvoorkomend misverstand is dat CloudFront alleen statische assets versnelt. Het plaatsen van een ALB achter CloudFront met een CachingDisabled-policy verbetert nog steeds de prestaties van dynamische API’s, omdat de handshake van de gebruiker wordt voltooid op de lokale PoP in plaats van het internet over te steken naar de origin-Region. Combineer dat met een gemengde workload — bijvoorbeeld /static/* geserveerd vanuit S3 en /api/* vanuit een ALB — en één distributie kan beide aan:

Distribution:
  Aliases: [www.example.com]
  ViewerCertificate: ACM cert in us-east-1
  Origins:
    - Id: s3-static
      DomainName: static-assets.s3.us-east-1.amazonaws.com
      S3OriginConfig:
        OriginAccessControlId: !Ref OAC
    - Id: alb-dynamic
      DomainName: alb-1234.us-east-1.elb.amazonaws.com
      CustomOriginConfig: { OriginProtocolPolicy: https-only }
  DefaultCacheBehavior:
      TargetOriginId: alb-dynamic
      CachePolicyId: CachingDisabled
      OriginRequestPolicyId: AllViewer
  CacheBehaviors:
    - PathPattern: /static/*
      TargetOriginId: s3-static
      CachePolicyId: CachingOptimized
    - PathPattern: /api/*
      TargetOriginId: alb-dynamic
      CachePolicyId: !Ref ShortTtlPolicy

Route 53 alias records verwijzen vervolgens www.example.com naar de d123.cloudfront.net van de distributie — alias records zijn gratis en worden direct omgezet naar de anycast-IP’s van CloudFront.

Certificaten bevinden zich in us-east-1

Voor elke CloudFront-distributie die op een custom domein wordt geserveerd, moet het viewer-facing TLS-certificaat in AWS Certificate Manager zijn uitgegeven in us-east-1 (N. Virginia), ongeacht waar de origin bucket, ALB of gebruikers zich bevinden. CloudFront is een wereldwijde service waarvan het controlepaneel is verankerd in us-east-1; edge-locaties halen het certificaat uit die Region. Het aanvragen van een ACM-certificaat in eu-west-1 omdat je S3-bucket zich daar toevallig bevindt, is een gebroken patroon — de distributie zal het nooit zien.

aws acm request-certificate \
  --domain-name media.example.com \
  --validation-method DNS \
  --region us-east-1

Als je TLS een tweede keer beëindigt tussen CloudFront en een ALB-origin, bevindt dat origin-facing certificaat zich in de Region van de ALB. Alleen het certificaat voor de viewer is gebonden aan us-east-1. Dezelfde regel is van toepassing op API Gateway edge-optimized custom domeinen (die intern een door AWS beheerde CloudFront-distributie gebruiken): het certificaat moet in us-east-1 staan. Regionale API Gateway-eindpunten daarentegen gebruiken een certificaat uit de eigen Region van de API.

Origin Access Control voor S3 Origins

Een S3-bucket achter CloudFront plaatsen terwijl de bucket openbaar blijft, ondermijnt het doel: gebruikers omzeilen CloudFront door rechtstreeks het S3 REST-eindpunt aan te spreken, waardoor WAF, geo-restricties, signed URL’s en cachevoordelen worden overgeslagen — en mogelijk data wordt blootgesteld.

De moderne oplossing is Origin Access Control (OAC), die de verouderde Origin Access Identity (OAI) vervangt. OAC gebruikt SigV4-ondertekening, ondersteunt SSE-KMS, werkt in elke S3-Region (inclusief degene die na 2022 zijn gelanceerd) en ondersteunt dynamische verzoeken. Block Public Access blijft ingeschakeld, er zijn geen ACL’s nodig, en de bucket policy verleent alleen leestoegang aan de CloudFront service principal, verder beperkt door de specifieke ARN van de distributie:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipal",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::media-example-com/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF"
      }
    }
  }]
}

OAI functioneert nog steeds, maar moet als verouderd worden beschouwd — kies altijd OAC voor nieuw werk.

Correctheid van de cache

De effectiviteit van de cache hangt af van de Cache-Control- en Expires-headers die de origin retourneert, gecombineerd met de min/default/max TTL’s van de CloudFront-cachepolicy. Onveranderlijke assets met een vingerafdruk moeten agressief worden gecachet; HTML-shells die ernaar verwijzen, moeten een korte levensduur hebben zodat implementaties zich verspreiden; geauthenticeerde JSON mag helemaal niet worden gecachet op het gedeelde CDN:

Cache-Control: public, max-age=31536000, immutable   # fingerprinted assets
Cache-Control: public, max-age=60, s-maxage=300      # HTML that changes
Cache-Control: private, no-store                      # authenticated JSON

Twee symmetrische valkuilen komen vaak voor. Ten eerste, als de origin geen cache-headers meestuurt, valt CloudFront terug op de standaard TTL van de distributie en kan het ongemerkt dynamische antwoorden urenlang cachen. Ten tweede, een algemene Cache-Control: no-cache op assets die wel gecachet zouden moeten worden, dwingt elk verzoek terug naar de origin en ondermijnt het CDN.

De gevaarlijkste valkuil is het cachen van gepersonaliseerde antwoorden zonder de juiste headers. Als /account/dashboard HTML retourneert die specifiek is voor gebruiker A, maar de origin laat no-store weg en de cachepolicy neemt geen auth-header of cookie op in de cachesleutel, dan zal de edge met plezier de pagina van gebruiker A aan gebruiker B serveren. Markeer dergelijke antwoorden ofwel als private, no-store, of neem de sessie-identifier op in de cachesleutel en accepteer de lagere hit ratio.

Voor een kostenoptimalisatiescenario waarbij een Auto Scaling-groep van EC2 On-Demand instances statische content serveert, is het correcte herontwerp om de assets naar S3 te verplaatsen, CloudFront ervoor te plaatsen met OAC, en de ASG te elimineren of te verkleinen. Dit verschuift de kosten van per-uur-compute naar per-verzoek-levering, wat voor statische workloads ordes van grootte goedkoper is.

Signed URL’s, Signed Cookies en Geo-Restriction

CloudFront ondersteunt signed URL’s (tijdsgebonden, optioneel IP-beperkte toegang tot een enkel object — een gekochte videodownload, een eenmalige PDF-link) en signed cookies (toegang tot meerdere objecten die overeenkomen met een padpatroon — een geauthenticeerde abonnee die door een catalogus bladert). Beide gebruiken een trusted key group waarvan de publieke sleutel wordt geüpload naar CloudFront; de private sleutel ondertekent een policy die de vervaldatum, het bron-IP-bereik of het URL-patroon specificeert.

https://d123.cloudfront.net/premium/movie.mp4
  ?Expires=1735689600
  &Signature=...
  &Key-Pair-Id=APKAI...

Dit is iets anders dan een S3 presigned URL, die CloudFront omzeilt en directe toegang tot de bucket verleent. Koppel CloudFront signed URL’s met OAC en de bucket blijft van begin tot eind privé.

Geo-restriction dwingt op distributieniveau allow-lists of block-lists op landniveau af, voordat verzoeken de cache of de origin bereiken. Het gebruikt de door CloudFront onderhouden GeoIP-database en is het goedkope, cache-bypass-bestendige mechanisme voor het afdwingen van licentie-embargo’s. Voor fijnmazigere logica (op staatsniveau, combinaties van headers), gebruik je een CloudFront Function of Lambda@Edge; voor een volledige regelengine gebruik je WAF.

AWS Global Accelerator

Global Accelerator is geen CDN en doet geen caching. Het provisioneert twee statische anycast IPv4-adressen (of BYOIP) die wereldwijd vanaf AWS edge-locaties worden geadverteerd. TCP- of UDP-verbindingen van clients komen de AWS-backbone binnen bij de dichtstbijzijnde edge en worden over het privénetwerk van AWS gerouteerd naar het meest ‘healthy’ eindpunt (ALB, NLB, EC2 of Elastic IP) in een of meer regio’s. Deze eindpunten zijn gegroepeerd in eindpuntgroepen met traffic dials en weights.

De statische IP’s bieden drie concrete voordelen: clients en firewall-allowlists hoeven nooit te veranderen, zelfs als de backend opnieuw wordt ontworpen; regionale failover is binnen enkele seconden voltooid door verkeer te verschuiven tussen eindpuntgroepen op basis van health-check-wijzigingen, waarbij de propagatie van DNS TTL volledig wordt omzeild; en de TCP-handshake eindigt bij de edge, terwijl het langeafstandstraject over de backbone van AWS loopt.

Kies Global Accelerator wanneer:

• Het protocol niet-HTTP is: UDP voor gaming of VoIP, MQTT, SIP, SFTP, custom TCP.
• U statische IP’s nodig heeft voor enterprise-allowlisting of mobiele apps die adressen hardcoderen.
• U regionale failover in minder dan een minuut nodig heeft voor stateful active-active implementaties.
• De workload dynamisch en niet-cachebaar is, waardoor een CDN weinig waarde biedt.

Kies CloudFront wanneer:

• Content cachebaar is (afbeeldingen, videosegmenten, statische HTML, API-responsen met TTL’s).
• U edge compute wilt via Lambda@Edge of CloudFront Functions.
• U WAF, signed URL’s/cookies of field-level encryption op de edge nodig heeft.

Twee valkuilen om te vermijden. CloudFront kiezen om “onze gaming-servers wereldwijd sneller te maken” werkt niet, omdat gaming UDP en niet-cachebaar is — Global Accelerator is vereist. Omgekeerd is het kiezen van Global Accelerator voor een statische website duur (vaste kosten per uur plus per GB) en verliest het de voordelen van caching — CloudFront zou de origin egress drastisch verlagen. Voor een wereldwijd gedistribueerde maar single-region HTTP API waar gebruikers de latency tolereren, kan eenvoudige Route 53 latency-based routing mogelijk voldoende en goedkoper zijn dan beide.

Route 53 Routingbeleid voor Wereldwijd Verkeer

Route 53 kiest naar welk eindpunt een client resolvet; CloudFront of Global Accelerator handelt vervolgens de verbinding af. Drie beleidsregels domineren wereldwijde architecturen.

Latency-based routing meet de daadwerkelijke netwerklatency vanaf de locatie van de resolver naar elke regio en retourneert de snelste. Gebruik dit voor identieke stacks in meerdere regio’s waarbij u wilt dat gebruikers naar de regio worden geleid die op dat moment het snelst is.

Geoproximity routing is gebaseerd op coördinaten in plaats van op latency: u geeft de locatie (of AWS-regio) van elk eindpunt op, en Route 53 stuurt gebruikers naar de geografisch dichtstbijzijnde. Het onderscheidende kenmerk is een bias-waarde (−99 tot +99) die het effectieve servicegebied vergroot of verkleint — handig voor het geleidelijk verschuiven van verkeer tijdens een regionale lancering of het leeg laten lopen van een regio voor onderhoud. Geoproximity vereist Route 53 traffic flow (traffic policies) en wordt doorgaans gekoppeld aan een regionale NLB of ALB in elke regio.

RecordSets:
  - Region: eu-west-1
    Endpoint: nlb-eu.example.internal
    Bias: +30       # expand EU service area during launch
  - Region: us-east-1
    Endpoint: nlb-us.example.internal
    Bias: 0
  - Region: ap-southeast-1
    Endpoint: nlb-ap.example.internal
    Bias: 0

Failover routing gebruikt een primair/secundair paar gekoppeld aan health checks. Dit is failover op DNS-niveau, onderhevig aan TTL en resolver-caching, dus het is langzamer dan de data-plane failover van Global Accelerator — kies failover routing voor eenvoudige active-passive waarbij een minuut DNS-propagatie acceptabel is, en Global Accelerator wanneer u seconden nodig heeft.

Dit beleid kan worden gecombineerd. Een veelvoorkomend wereldwijd patroon: Route 53 latency- of geoproximity-records verwijzen naar Global Accelerator (voor TCP/UDP) of CloudFront (voor cachebare HTTPS), met daaronder failover-records met health checks als vangnet. De gelaagdheid is bewust: Route 53 kiest de regio, Global Accelerator of CloudFront kiest de edge en het pad over de backbone, en een regionale load balancer kiest het doelwit binnen de regio.

API Gateway Eindpunttypes en Custom Domains

API Gateway biedt drie eindpunttypes met verschillende topologieën:

Edge-optimized eindpunten verpakken de API in een door AWS beheerde CloudFront-distributie die u niet rechtstreeks kunt configureren. Dat is handig voor snel wereldwijd bereik, maar beperkend als u uw eigen cache behaviors, WAF-regels of origin request policies wilt. Het idiomatische patroon voor maximale controle is een Regional endpoint waar een door de klant beheerde CloudFront-distributie voor is geplaatst.

De plaatsing van certificaten volgt de regel van CloudFront: edge-optimized custom domains vereisen een ACM-certificaat in us-east-1; Regional endpoints vereisen het certificaat in dezelfde regio als de API. HTTP API’s dwingen een minimum van TLS 1.2 af; REST API’s ondersteunen security policies tot TLS 1.3.

ACM-certificaten: Uitgegeven, Gavalideerd, Geïmporteerd

ACM geeft kosteloos publieke TLS-certificaten uit en vernieuwt deze automatisch, en integreert rechtstreeks met CloudFront, API Gateway, ALB, NLB en andere AWS-services. Validatie gebeurt via DNS-validatie (ACM geeft je een CNAME om in Route 53 of een andere DNS-provider te plaatsen; zolang dit record bestaat, vernieuwt ACM het certificaat automatisch en voor onbepaalde tijd) of e-mailvalidatie (handmatige doorklikactie bij elke verlenging, kwetsbaar voor automatisering). DNS-validatie is de correcte standaardkeuze voor elke productieomgeving.

Door ACM uitgegeven certificaten kunnen niet worden geëxporteerd en kunnen niet buiten de geïntegreerde AWS-services worden gebruikt. Wanneer een regelgevende of zakelijke eis een specifieke externe CA voorschrijft — bijvoorbeeld een REST API die moet ‘chainen’ naar een specifieke commerciële uitgever en TLS 1.3 moet afdwingen — kun je geen door ACM uitgegeven certificaat gebruiken. Verkrijg het certificaat van de vereiste CA en importeer het in ACM, koppel het vervolgens aan een Regional API Gateway custom domain met een TLS 1.3 security policy.

De valkuil bij importeren is tweeledig: geïmporteerde certificaten worden niet automatisch vernieuwd (herimporteer vóór de vervaldatum, anders faalt het endpoint hard), en ACM valideert de chain niet bij het importeren — een gebroken intermediate certificaat wordt pas zichtbaar tijdens de handshake met echte clients. Test de volledige chain tegen een strikte client vóór de uitrol.

S3 Transfer Acceleration vs. CloudFront

CloudFront optimaliseert downloads; S3 Transfer Acceleration optimaliseert uploads. Transfer Acceleration gebruikt hetzelfde CloudFront edge-netwerk in omgekeerde richting: PUT-requests komen binnen bij de dichtstbijzijnde edge location en gebruiken de AWS-backbone naar de regio van de doel-bucket. Het blinkt uit wanneer een wereldwijd verspreide groep gebruikers omvangrijke objecten uploadt naar een bucket in één enkele regio — bijvoorbeeld buitendiensttechnici die wereldwijd tekeningen van meerdere gigabytes uploaden naar us-east-1.

De twee features kunnen naast elkaar bestaan op dezelfde bucket: schakel Transfer Acceleration in en stel een CloudFront-distributie met OAC in voor downloads. Voor kleine objecten of clients die zich al dicht bij de regio van de bucket bevinden, voegt Transfer Acceleration kosten toe zonder voordeel — gebruik de S3 Transfer Acceleration speed comparison tool om te meten voordat je je vastlegt. Clients moeten het s3-accelerate endpoint gebruiken om de versnelling te activeren.

AWS WAF voor Layer 7-bescherming

AWS WAF inspecteert HTTP(S)-requests voordat ze de beschermde resource bereiken. Het wordt gekoppeld aan CloudFront-distributies, ALB’s, API Gateway stages, AppSync API’s, Cognito user pools, App Runner services en Verified Access instances. Een web ACL bevat regels die matchen op URI, headers, query strings, body (standaard tot 8 KB, uitbreidbaar tot 64 KB op ALB/API Gateway), IP-sets en geolocatie.

De meest gebruikte bouwstenen zijn AWS Managed Rules: AWSManagedRulesCommonRuleSet en AWSManagedRulesKnownBadInputsRuleSet dekken de belangrijkste OWASP-exploits; AWSManagedRulesSQLiRuleSet en XSS match statements pakken injectie-aanvallen aan. Custom rules voegen geo-matching (allowlists/blocklists van landen voor compliance), IP-set matches en rate-based rules toe — die het aantal requests per bron-IP tellen over een doorlopend venster van vijf minuten en blokkeren zodra een drempel wordt overschreden. Rate-based rules zijn de eerste verdedigingslinie tegen HTTP-floods en credential stuffing:

{
  "Name": "LoginRateLimit",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 500,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/login",
          "FieldToMatch": {"UriPath": {}},
          "PositionalConstraint": "STARTS_WITH",
          "TextTransformations": [{"Priority":0,"Type":"NONE"}]
        }
      }
    }
  },
  "Action": {"Block": {}}
}

Regioregels zijn belangrijk. Web ACL’s voor CloudFront zijn globaal en moeten worden aangemaakt in us-east-1. Web ACL’s voor regionale resources (ALB, API Gateway, etc.) worden aangemaakt in de regio van de resource zelf.

Om een statische site op S3 te beschermen, kun je WAF niet aan de bucket koppelen — S3 is geen door WAF ondersteunde resource. Het correcte patroon is CloudFront + OAC voor de bucket, met de web ACL gekoppeld aan de distributie. Het feit dat de bucket alleen via CloudFront bereikbaar is, zorgt ervoor dat al het verkeer daadwerkelijk wordt geïnspecteerd.

Firewall Manager voor Multi-Account WAF Governance

WAF per account beheren is niet schaalbaar. Binnen een Organization start een team een nieuwe ALB op zonder de bedrijfsbaseline te koppelen, en de compliancepositie verslechtert ongemerkt. AWS Firewall Manager lost dit op met organisatiebrede policies die worden afgedwongen op accounts en resources die binnen de scope vallen.

Vereisten: AWS Organizations met alle features ingeschakeld, een aangewezen Firewall Manager-beheerdersaccount, en AWS Config ingeschakeld in elk member-account. Policy-typen omvatten AWS WAF, AWS Shield Advanced, security groups (audit en gebruik), Network Firewall, Route 53 Resolver DNS Firewall en firewalls van derden.

Een WAF-policy kan een “first” rule group (geëvalueerd vóór de regels van de applicatie-eigenaar), een “last” rule group (erna), of de web ACL volledig vervangen. Nieuwe ALB’s of CloudFront-distributies die overeenkomen met de resource-scope, ontvangen automatisch de bedrijfsregels, en niet-conforme resources worden gemarkeerd en — afhankelijk van de herstelinstellingen — automatisch gecorrigeerd. Wanneer een scenario spreekt over “meerdere accounts”, “centraal beheren” of “consistente WAF-regels binnen de hele organisatie”, is Firewall Manager het antwoord, niet WAF per account.

Shield Standard vs. Shield Advanced

Het is een cruciale fout om aan te nemen dat WAF alleen DDoS-aanvallen stopt. WAF opereert op verzoeken die het bereiken — het is uitstekend tegen application-layer floods, credential stuffing en bekende exploit-signatures — maar grote volumetrische aanvallen op Lagen 3/4 (SYN-floods, UDP-reflection) worden opgevangen door AWS Shield.

Shield Standard is standaard en zonder extra kosten ingeschakeld. Het beschermt automatisch tegen veelvoorkomende L3/L4-aanvallen en is van toepassing op CloudFront, Route 53 en Global Accelerator, met basisbescherming voor ELB, EC2 en andere resources. Het biedt geen aanvalsspecifieke zichtbaarheid, inschakeling van het Shield Response Team of kostenbescherming.

Shield Advanced ($3.000/maand per organisatie, eenjarige verbintenis) voegt toe:

Aannemen dat Shield Standard voldoende is voor “grootschalige DDoS met kostenbescherming en deskundige respons” is onjuist, precies omdat Standard geen zichtbaarheid, kostenbescherming en toegang tot het SRT biedt. Wanneer de origin een EC2-instance achter een ELB is en DNS bij een derde partij is ondergebracht (waardoor Route 53 alias-trucs geen optie zijn), is het aanbevolen patroon om Shield Advanced in te schakelen op de ELB en de applicatie te voorzien van een CloudFront-distributie (ook beschermd met Shield Advanced). Hiermee wordt de mitigatieperimeter naar de edge verplaatst en het aanvalsoppervlak dat de Region bereikt, verkleind.

De correcte gelaagde beveiligingshouding is: Shield voor L3/L4-volumetrie, WAF voor L7-filtering, CloudFront of Global Accelerator als het edge-toegangspunt waaraan beide services gekoppeld zijn, en Firewall Manager om het beleid in elk account af te dwingen.

← Netwerken · Alle domeinen · Databases →

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

Blader door Amazon →