Amazon SAA-C03: Netwerken & Connectiviteit — 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.

VPC-ontwerp en CIDR-planning

Elke VPC begint met een CIDR-blok, en de keuze die bij het aanmaken wordt gemaakt, heeft gevolgen voor peering, Transit Gateway-attachments en hybride connectiviteit. Het primaire CIDR-blok moet tussen /16 en /28 liggen, gekozen uit de RFC 1918-adresruimte, en mag niet overlappen met netwerken waarmee u van plan bent te peeren, te routeren via een Transit Gateway, of te bereiken via Direct Connect of VPN. Overlappende CIDR’s zijn de meest voorkomende oorzaak van defecte hybride ontwerpen, omdat AWS niet kan routeren tussen twee netwerken die dezelfde adresruimte delen — Transit Gateway accepteert de attachment wel, maar de propagatie zal mislukken of het verkeer wordt stilzwijgend ‘geblackholed’.

Wanneer een VPC geen adresruimte meer heeft, hoeft u deze niet opnieuw op te bouwen. Er kunnen maximaal vier secundaire IPv4 CIDR-blokken worden gekoppeld (en extra reeksen uit een bredere pool voor een standaard totaal van vijf, uitbreidbaar via een quotumverhoging). Secundaire blokken kunnen afkomstig zijn uit dezelfde RFC 1918-reeks of uit de 100.64.0.0/10 gedeelde adresruimte, wat handig is wanneer 10.0.0.0/8 is uitgeput of wanneer carrier-grade NAT-ruimte nodig is. Met secundaire CIDR’s kunt u nieuwe subnetten uitsnijden voor uitbreiding — EKS pod-networking, een nieuwe tier — zonder bestaande workloads opnieuw te hoeven nummeren.

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

Een robuust ontwerp reserveert een /17 of /18 voor toekomstige groei, lijnt subnetgrenzen uit met Availability Zones (een /20 per AZ per tier is een veelvoorkomend patroon), en laat speelruimte over voor de ENI’s die worden verbruikt door interface-endpoints, NAT gateways en load balancers.

Een VPC is een regionaal construct, opgedeeld in subnetten die elk aan één enkele AZ zijn gekoppeld. Het onderscheid tussen “public” en “private” is puur een routeringsbeslissing: een public subnet heeft een route 0.0.0.0/0 → igw-xxxx die naar een Internet Gateway wijst, terwijl een private subnet ofwel geen default route heeft, of 0.0.0.0/0 naar een NAT-apparaat laat wijzen. Instances in een public subnet hebben ook een public of Elastic IP nodig om inkomend bereikbaar te zijn; de IGW voert 1:1 NAT uit tussen het private en het public IP-adres.

NAT Gateways, NAT Instances en IPv6 Egress

Voor uitsluitend uitgaande IPv4-internettoegang vanuit private subnetten zijn NAT gateways de juiste primitieve. Een beheerde NAT gateway schaalt automatisch naar 45–100 Gbps, ondersteunt 55.000 gelijktijdige verbindingen per unieke bestemming, wordt door AWS gepatcht en is hoog beschikbaar binnen zijn AZ. NAT gateways worden gefactureerd per uur en per verwerkte GB.

NAT instances — zelfbeheerde EC2-instances waarbij de source/destination check is uitgeschakeld — zijn verouderd. Ze worden beperkt door de doorvoersnelheid van een enkele instance, moeten worden gescript voor failover en worden een bottleneck onder aanhoudende belasting. Ze zijn alleen geschikt voor atypische behoeften zoals aangepaste filtering, en zelfs dan heeft een Gateway Load Balancer-appliance meestal de voorkeur.

Het canonieke, hoog beschikbare patroon is één NAT gateway per AZ, elk in het public subnet van die AZ, met een afzonderlijke private route table per AZ waarvan de default route naar de lokale NAT gateway wijst:

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

Het implementeren van een enkele NAT gateway die over meerdere AZ’s wordt gedeeld, is om twee redenen een valkuil. Ten eerste is het een single point of failure: een storing in een AZ legt de uitgaande verbindingen voor elk private subnet plat. Ten tweede doorkruist elk pakket van instances in andere AZ’s een AZ-grens, wat cross-AZ data transfer-kosten met zich meebrengt (momenteel $0,01/GB per richting), bovenop de verwerkingskosten van de NAT gateway. Bij workloads met honderden TB’s aan uitgaand verkeer, vallen de kosten van de extra NAT gateways hierbij in het niet. Een tweede veelvoorkomende misconfiguratie is het plaatsen van de NAT gateway zelf in een private subnet — deze heeft dan geen pad naar de IGW en functioneert niet.

Voor IPv6 is NAT niet nodig en ook niet beschikbaar, omdat elk IPv6-adres wereldwijd routeerbaar is. Om uitsluitend uitgaand IPv6-verkeer toe te staan en tegelijkertijd ongevraagd inkomend verkeer te blokkeren, koppelt u een egress-only internet gateway en routeert u ::/0 ernaartoe vanuit de private subnetten. Een reguliere IGW is bidirectioneel en zou instances blootstellen.

VPC Endpoints: Gateway versus Interface

VPC-endpoints zorgen ervoor dat verkeer tussen uw VPC en AWS-services op de AWS-backbone blijft, waardoor het internet, NAT-gateways en internetgateways volledig worden vermeden. Er zijn twee fundamenteel verschillende implementaties, en deze door elkaar halen is een van de meest voorkomende architecturale fouten.

Gateway-endpoints bestaan alleen voor Amazon S3 en DynamoDB. Ze zijn een item in een routetabel — een prefixlijst (bijvoorbeeld pl-63a5400a voor S3 in us-east-1) die naar het endpoint zelf verwijst. Er is geen ENI, geen DNS-wijziging, geen kosten per uur en geen security group (toegang wordt beheerd door de routetabel plus de endpoint policy). Omdat ze op routes gebaseerd zijn, werken ze alleen voor resources binnen de VPC — on-premises netwerken die S3 bereiken via Direct Connect kunnen er geen gebruik van maken.

Interface-endpoints (AWS PrivateLink) zijn ENI’s met privé-IP’s die in uw subnets worden geplaatst, en worden per uur per AZ plus per GB gefactureerd. Ze werken voor bijna elke andere service — SQS, KMS, Secrets Manager, ECR, STS, SSM, SNS, en honderden meer — evenals voor services van derden die als endpoint services worden gepubliceerd. Interface-endpoints ondersteunen private DNS, wat de publieke service-hostname overschrijft om naar het privé-IP van het endpoint te resolven, zodat SDK’s en CLI’s geen codewijzigingen vereisen. Omdat ze door een ENI worden ondersteund, zijn security groups van toepassing.

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

De kostenlogica is belangrijk: al het verkeer dat een privé-subnet verlaat naar een publieke AWS-service, gaat standaard via een NAT-gateway tegen ongeveer $0,045/GB. Voor een gecontaineriseerde workload die 1 TB per dag naar S3 pusht, is het verschil tussen een NAT-gateway-pad en een gateway-endpoint duizenden dollars per maand. Interface-endpoints zijn de moeite waard wanneer ze NAT-egress op grote schaal vervangen of wanneer compliance internetrouting verbiedt.

Valkuilen: een security group koppelen aan een gateway-endpoint (deze hebben geen ENI); aannemen dat een gateway-endpoint bereikbaar is vanaf on-premises (dat is niet zo — gebruik een interface-endpoint of het hybride patroon EC2 → S3 gateway-endpoint → apart DX-pad); private DNS uitschakelen op een interface-endpoint en verwachten dat ongewijzigde SDK-aanroepen werken (deze zullen het publieke endpoint via het internet benaderen, waardoor het endpoint volledig nutteloos wordt); een gateway-endpoint aanmaken maar vergeten de routetabel van het privé-subnet te koppelen (verkeer blijft stilzwijgend het publieke pad gebruiken); proberen een gateway-endpoint te gebruiken voor een service die geen gateway-endpoint heeft (bijvoorbeeld KMS) — alleen S3 en DynamoDB komen in aanmerking.

Connectiviteit tussen VPC’s: Peering versus Transit Gateway

VPC-peering is een één-op-één, niet-transitieve Layer 3-verbinding tussen twee VPC’s, in hetzelfde of een ander account, in dezelfde of een andere regio. Verkeer loopt via de AWS-backbone, er is geen bandbreedteknelpunt en er zijn geen kosten per uur — u betaalt alleen voor dataoverdracht tussen AZ’s of regio’s. Twee eigenschappen beperken peering: (1) het is niet-transitief — als A peert met B en B peert met C, kan A C niet bereiken via B; en (2) CIDR-ranges mogen niet overlappen. Het verbinden van N VPC’s in een full-mesh vereist N(N-1)/2 peerings met aanpassingen in de routetabellen in beide richtingen van elke peering; bij 30 VPC’s zijn dat 435 peerings. Verwachten dat peering kan schalen naar honderden VPC’s is een valkuil.

Transit Gateway (TGW) is een regionale cloudrouter. Elke VPC, VPN of Direct Connect-gateway is een attachment, en TGW-routetabellen bepalen welke attachment welke prefix kan bereiken. Dit zet een O(n²) mesh om in O(n) attachments en maakt hub-and-spoke-topologieën mogelijk waarbij een security-VPC firewalls host die al het verkeer tussen VPC’s inspecteren. TGW ondersteunt transitieve routing, beëindigt native VPN- en Direct Connect-gateway-associaties, en kan worden gedeeld binnen AWS Organizations via Resource Access Manager, zodat centrale netwerkteams de routing beheren terwijl workload-accounts eigenaar zijn van de VPC’s. TGW voegt een kost per uur per attachment toe en ongeveer $0,02/GB aan verwerkte data.

Voor connectiviteit tussen regio’s verbindt TGW-peering TGW’s in verschillende regio’s via de wereldwijde AWS-backbone met versleuteld verkeer — één TGW per regio, gepeerd in een mesh- of hub-ontwerp. Dit vermijdt het N-kwadraatprobleem tussen regio’s dat VPC-peering tussen regio’s opnieuw introduceert.

Hygiëne van routetabellen is hier de stille doder. Het aanmaken van een peering-verbinding of een TGW-attachment doet niets totdat expliciete CIDR-routes worden toegevoegd in de subnet-routetabellen van beide VPC’s die verwijzen naar het pcx- of tgw- doel, en security groups het verkeer toestaan. Stille connectiviteitsfouten zijn bijna altijd terug te voeren op een ontbrekende route of een impliciete ‘deny’ in een security group die naar de verkeerde bron-CIDR verwijst.

Hybride Connectiviteit: Site-to-Site VPN vs. Direct Connect

De keuze tussen Site-to-Site VPN en Direct Connect is een afweging tussen enerzijds snelle implementatie en ingebouwde encryptie, en anderzijds consistente lage latency, toegewezen bandbreedte en voorspelbare doorvoersnelheid.

Site-to-Site VPN zet twee IPsec-tunnels op tussen een customer gateway (on-premise router) en een Virtual Private Gateway of een Transit Gateway. Elke tunnel heeft een maximum van ongeveer 1,25 Gbps. Het verkeer wordt versleuteld op de netwerklaag, wat in combinatie met TLS voldoet aan de eisen voor encryptie op de netwerk- en sessielagen. Het loopt over het publieke internet, dus latency en jitter zijn variabel, maar het is binnen enkele minuten beschikbaar en kost centen per uur. Gebruik het wanneer connectiviteit onmiddellijk nodig is, wanneer de bandbreedte bescheiden is, of als een back-up pad.

Direct Connect (DX) biedt een toegewijde glasvezelverbinding (1, 10 of 100 Gbps) van een on-premise router naar een AWS Direct Connect-locatie. Het vermijdt het publieke internet, wat resulteert in consistente latency en een hogere doorvoersnelheid. De egress-kosten van DX zijn aanzienlijk lager dan die van internet-egress, wat van belang is bij het verplaatsen van honderden gigabytes per dag. Provisioning duurt weken — cross-connects, LOA’s, BGP-configuratie.

Twee valkuilen domineren hier. Ten eerste, Direct Connect versleutelt het verkeer op zichzelf niet. Een privécircuit is geen cryptografisch beschermd kanaal. Om aan een encryptie-eis over DX te voldoen, leg er een Site-to-Site VPN overheen, of gebruik MACsec voor Laag-2-encryptie op ondersteunde dedicated poorten. Ten tweede, een kale DX-verbinding routeert op zichzelf niet naar meerdere VPC’s. Een private VIF verbindt met één enkele Virtual Private Gateway die aan één enkele VPC is gekoppeld. Om vele VPC’s te bereiken — vooral over accounts en Regions heen — gebruik je een Direct Connect Gateway die is geassocieerd met een Transit Gateway via een transit VIF, en koppel je elke VPC aan de TGW:

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

Het canonieke productiepatroon gebruikt twee DX-verbindingen op twee DX-locaties die eindigen op afzonderlijke customer routers, met Site-to-Site VPN als automatische BGP-failover — BGP AS-path prepending of MED stuurt het verkeer naar DX zolang deze up is; als deze uitvalt, trekt BGP de DX-routes in en neemt de VPN het over.

Load Balancers: ALB, NLB en GWLB

ALB is Laag 7 en begrijpt HTTP-semantiek — host- en path-routing, WebSockets, redirects, op cookies gebaseerde sticky sessions. Het is het verkeerde hulpmiddel voor alles wat geen HTTP is: MQTT, raw TCP, syslog over UDP, SMTP. ALB gebruikt DNS-gebaseerde adressering met IP’s die in de loop van de tijd veranderen; er kunnen geen Elastic IPs aan worden toegewezen. Wanneer clients bestemmings-IP’s whitelisten, is een ALB alleen ongeschikt — gebruik een NLB met EIP’s, of zet Global Accelerator’s twee statische anycast-IP’s voor de ALB. “Gewoon de ALB DNS eenmalig resolven en de IP’s vastpinnen in firewallregels” is een valkuil: AWS wijzigt ze zonder kennisgeving.

NLB is Laag 4 en schaalt naar miljoenen flows per seconde. Het behoudt standaard het echte bron-IP van de client (targets zien de echte client), ondersteunt het toewijzen van een statische Elastic IP per AZ, en verwerkt TCP/UDP-workloads met hoge doorvoersnelheid. Historisch gezien ondersteunde NLB geen security groups op de load balancer zelf — client-CIDR’s moesten rechtstreeks worden toegestaan op de SG van de target. AWS heeft in 2023 optionele NLB security groups toegevoegd, maar veel ontwerpen gaan nog steeds uit van het klassieke gedrag.

Het canonieke publiekgerichte patroon is:

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

Het verwijzen naar de security group van de ALB als de bron op de backend — in plaats van een CIDR — is het ’least-privilege’-patroon en dekt automatisch het health check-verkeer, dat afkomstig is van de ENI’s van de ALB. De ALB zelf bevindt zich in publieke subnets in ten minste twee AZ’s (routes naar IGW); targets bevinden zich in private subnets. Een internet-facing ALB in een private subnet plaatsen is een klassieke misconfiguratie — registratie van de target slaagt, maar clients kunnen deze niet bereiken.

Gateway Load Balancer (GWLB) is speciaal gebouwd voor de transparante invoeging van virtuele appliances van derden (firewalls, IDS/IPS, DPI). Het werkt op Laag 3 en stuurt alle IP-protocollen door met behulp van GENEVE-inkapseling op UDP 6081. Verkeer bereikt de GWLB via een GWLB endpoint (GWLBe) — een interface-endpoint dat zich in een subnet bevindt en in routetabellen verschijnt als een target:

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

Het endpoint stuurt pakketten via PrivateLink door naar de GWLB, die het verkeer verdeelt over de vloot van appliances met behulp van ‘flow stickiness’, zodat beide richtingen van een flow dezelfde appliance raken. In een hub-and-spoke inspectieontwerp koppelen spoke-VPC’s aan een TGW waarvan de routetabellen het oost-west verkeer door de inspectie-VPC (die de GWLB en appliances bevat) dwingen voordat het de bestemmings-VPC’s bereikt. Ingress-inspectie gebruikt ’edge route tables’ die het verkeer van IGW-naar-web-tier eerst via de GWLBe omleiden:

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

Dit is het juiste antwoord voor gecentraliseerde, cross-account inspectie — zelfgebouwde oplossingen met EC2, aangepaste ‘route table hacks’ en failover-scripts vinden opnieuw uit wat GWLB standaard biedt.

PrivateLink voor services van consument naar provider

Naast het mogelijk maken van interface-eindpunten voor AWS-services, biedt PrivateLink private connectiviteit met services die door derden of andere AWS-accounts worden gepubliceerd. De provider plaatst zijn service achter een NLB en creëert een VPC endpoint service. Consumenten creëren interface endpoints in hun eigen VPC’s die hierop gericht zijn.

De kritieke directionaliteitsregel is: de verbinding wordt altijd geïnitieerd vanuit de consument naar de provider. De provider kan geen verbindingen initiëren naar de VPC van de consument. Het verkeer komt nooit op het internet, alleen de specifieke doelservice is bereikbaar (niet de hele provider-VPC, zoals bij peering), en er ontstaan geen problemen met overlappende CIDR-blokken omdat aan elke kant alleen eindpunt-IP’s worden blootgesteld. Dit is de geijkte oplossing voor een SaaS- of leveranciersdatabase-toegangspatroon waarbij de consument-VPC geen IGW, geen VPN en geen Direct Connect heeft. VPC-peering stelt volledige CIDR-ranges bloot en vereist niet-overlappende IP’s; een TGW-attachment routeert breed; een publieke API via het internet is niet privaat.

Global Accelerator en Route 53

AWS Global Accelerator wijst twee statische anycast IPv4-adressen toe die wereldwijd vanuit AWS edge locations worden geadverteerd. Clientverkeer komt binnen via de dichtstbijzijnde edge en reist over de AWS-backbone naar het dichtstbijzijnde gezonde regionale eindpunt (ALB, NLB, EIP of EC2). Dit lost twee problemen tegelijk op: statische IP’s voor ALBs (waarmee het probleem van whitelisting wordt opgelost), en verminderde jitter/latency voor wereldwijd verspreide gebruikers door een kortere route te nemen dan het openbare internet. Het versnelt niet-cachebaar TCP/UDP-verkeer naar origins waar CloudFront (dat content cachet) niet van toepassing is.

Route 53 lost een ander probleem op: verkeerssturing op DNS-niveau. Global Accelerator beïnvloedt het datavlak zelf; Route 53 beïnvloedt alleen de DNS-resolutie, waarna de TCP-verbinding gaat naar waar het opgevraagde IP-adres zich bevindt. De twee worden vaak gecombineerd: een Route 53 alias record verwijst naar een Global Accelerator die voor regionale ALBs staat.

Route 53 routing policies:

Latency en geolocation worden vaak door elkaar gehaald: latency minimaliseert de door de gebruiker waargenomen RTT; geolocation dwingt dataresidentie af, ongeacht de latency. Multi-Region failover vereist health checks op de primaire resource. Alias records zijn AWS-specifiek, resolven direct naar ALB-, NLB-, CloudFront-, S3-website- en API Gateway-eindpunten zonder querykosten, en werken – in tegenstelling tot CNAMEs – op de zone apex.

Route 53 Resolver beantwoordt DNS-queries binnen een VPC via het .2-adres (VPC CIDR-basis + 2). Voor hybride DNS laten inbound endpoints on-premises resolvers private hosted zones in AWS bevragen; outbound endpoints met forwarding rules laten VPC-resources on-premises namen resolven. Zonder deze kunnen EC2-instances corp.internal niet resolven en kunnen on-prem servers db.prod.internal niet resolven — een subtiel probleem dat pas aan het licht komt wanneer applicaties cross-environment lookups beginnen uit te voeren. Interface-eindpunten vereisen Enable Private DNS zodat SDK-calls de ENI van het eindpunt bereiken; zonder dit bereiken de calls nog steeds het publieke eindpunt via het internet, wat het doel tenietdoet.

Security Groups, NACL’s en het principe van de minste privileges

Security groups zijn stateful — terugkerend verkeer wordt automatisch toegestaan — en opereren op ENI-niveau. NACL’s zijn stateless en opereren op de subnetgrens. Elke TCP-regel in een NACL vereist een expliciete inkomende en uitgaande regel; omdat clients een bronpoort kiezen uit de ephemeral range, moet de regel voor het terugkerende verkeer poorten 1024–65535 toestaan (Linux gebruikt standaard 32768–60999; het bredere bereik dekt Windows en andere stacks). Het vergeten van de ephemeral return rule is een klassieke oorzaak van verbindingen die de SYN-stap voltooien maar vastlopen bij het wachten op een antwoord.

Voor het toepassen van het principe van de minste privileges tussen lagen, moeten security group-regels verwijzen naar andere security group-ID’s, niet naar CIDR’s. Dit schaalt mee met Auto Scaling en voorkomt breekbare IP-whitelists:

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

NACL’s zijn een grove maatregel om de ‘blast radius’ te beperken, geen vervanging voor security groups. Het aanscherpen van NACL’s “voor gelaagde verdediging” zonder overeenkomstige wijzigingen in security groups, breekt vaak uitgaand geïnitieerde stromen zoals yum/apt-updates via een NAT-gateway, omdat het stateless terugkerende verkeer stilzwijgend wordt verwijderd. Route tables bepalen uiteindelijk de bereikbaarheid: zelfs een permissieve security group kan geen verkeer afleveren als de route table geen route naar de bestemming heeft, en omgekeerd is een gateway-eindpunt alleen effectief als de S3 prefix list-route daadwerkelijk is geïnstalleerd in de route tables van de subnets die de workload hosten.

Beslissingsreferentie

← Dataoverdracht · Alle domeinen · Contentlevering →

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

Blader door Amazon →