Amazon SAA-C03: Containers & Orchestratie — 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.

Kiezen tussen ECS en EKS, en tussen EC2 en Fargate

De eerste architecturale beslissing voor elke container-workload op AWS is het kiezen van de orchestrator en de compute-modus. Amazon ECS is een AWS-eigen orchestrator met een nauwe integratie met IAM, ALB/NLB, CloudWatch, Service Discovery en VPC-networking. Er zijn geen kosten voor het control plane en het is de snelste weg naar productie voor teams die geen Kubernetes-specifieke tooling nodig hebben. Tasks zijn eenheden van een of meer containers die een levenscyclus delen; services zijn langlopende, beheerde sets van tasks die worden aangestuurd door een scheduler. Amazon EKS draait upstream-conforme Kubernetes voor een vast bedrag van $0,10/uur per cluster, en het is de juiste keuze wanneer workloads overdraagbaar moeten blijven, de Kubernetes API moeten gebruiken, of gebruikmaken van het CNCF-ecosysteem (Helm, CRD’s, Operators). Het control plane — API-server, etcd, controller manager, scheduler — wordt door AWS gepatcht, geback-upt en hoog beschikbaar gemaakt over drie AZ’s.

Beide orchestrators accepteren twee compute-modi. AWS Fargate voert elke task of pod uit op geïsoleerde Firecracker microVM’s; er zijn geen AMI’s om te patchen, geen Auto Scaling Group capacity providers om af te stellen, geen bin-packing beslissingen, geen via SSH toegankelijke hosts. Je betaalt per vCPU-seconde en GB-seconde van de task. EC2 launch type / managed node groups betekent dat je eigenaar bent van de instances, met de flexibiliteit en operationele last die dat met zich meebrengt.

Fargate is de juiste standaardkeuze wanneer een scenario de nadruk legt op “serverless”, “minimale operationele overhead”, of “geen infrastructuur om te beheren”, op voorwaarde dat de workload binnen de beperkingen past: maximaal 16 vCPU / 120 GB geheugen per task, geen GPU, geen privileged containers, geen DaemonSets, geen HostPort/HostNetwork, geen Windows-aanpassingen op hostniveau. Kies voor managed node groups of EC2 launch type wanneer je GPU’s, DaemonSets die host-toegang vereisen, custom AMI’s, Windows Server-containers met GMSA, sub-seconde bin-packing efficiëntie, of agressieve, op Spot gebaseerde kostenoptimalisatie nodig hebt.

De klassieke valkuil is het kiezen van EC2-nodes omdat ze “goedkoper aanvoelen”. Voor workloads met pieken of lage benutting is Fargate vaak goedkoper als je rekening houdt met ongebruikte capaciteit plus de engineeringtijd voor het patchen van AMI’s, het drainen van nodes en de configuratie van de cluster autoscaler — allemaal zaken die Fargate wegneemt.

Task Definitions, Placement en Capacity Providers

Een canonieke ECS Fargate task definition bevat de essentie — CPU/geheugen-sizing, een execution role voor het pullen van images en het schrijven van logs, awsvpc netwerkmodus, en de koppeling met CloudWatch Logs:

family: checkout-service
requiresCompatibilities: [FARGATE]
networkMode: awsvpc
cpu: "1024"
memory: "2048"
executionRoleArn: arn:aws:iam::111122223333:role/ecsTaskExecutionRole
containerDefinitions:
  - name: checkout
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/checkout:1.4.2
    portMappings: [{ containerPort: 8080 }]
    logConfiguration:
      logDriver: awslogs
      options:
        awslogs-group: /ecs/checkout
        awslogs-region: us-east-1

Op ECS met EC2 bepalen task placement strategies hoe tasks over instances worden verdeeld. Ze worden in volgorde toegepast:

Placement constraints zoals distinctInstance of memberOf met behulp van de cluster query language beperken de kandidaten verder.

Capacity providers ontkoppelen services van de onderliggende Auto Scaling Groups. FARGATE en FARGATE_SPOT zijn managed providers; custom providers omvatten een ASG en maken managed scaling mogelijk, zodat ECS het gewenste aantal (desired count) van de ASG aanpast op basis van het aantal geprovisioneerde tasks. Een capacity provider strategy verdeelt tasks op basis van gewicht (weight) en basis (base) — bijvoorbeeld, het garanderen van twee on-demand Fargate-tasks en de rest 1:4 verdelen met Fargate Spot voor workloads die onderbrekingen kunnen verdragen:

capacityProviderStrategy:
  - capacityProvider: FARGATE
    base: 2
    weight: 1
  - capacityProvider: FARGATE_SPOT
    weight: 4

Autoscaling: Pods, Tasks en Nodes

Fargate neemt het node-beheer weg, maar het schaalt niet automatisch het aantal tasks of pods. Dit onderscheid is de meest voorkomende misvatting over Fargate: serverless is van toepassing op de host-laag, nooit op de ‘desired count’ van je service. Je bent nog steeds zelf verantwoordelijk voor autoscaling op serviceniveau.

Gebruik voor ECS Application Auto Scaling. Target tracking is de idiomatische standaard omdat het automatisch de scale-out en scale-in CloudWatch-alarms aanmaakt en rekening houdt met cooldowns. Zinnige metrics zijn ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization en ALBRequestCountPerTarget:

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 --max-capacity 30

aws application-autoscaling put-scaling-policy \
  --policy-name cpu-target-50 \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
    '{"TargetValue":50.0,"PredefinedMetricSpecification":{"PredefinedMetricType":"ECSServiceAverageCPUUtilization"}}'

Step scaling en scheduled scaling blijven beschikbaar voor niet-lineaire responscurves of bekende verkeersperioden.

Voor EKS op EC2-nodes wordt de pod-dimensie afgehandeld door de Horizontal Pod Autoscaler (HPA), die het aantal replica’s aanpast op basis van CPU, geheugen of custom metrics. HPA alleen kan geen nodes toevoegen — het zal met plezier het aantal replica’s verhogen tot voorbij de clustercapaciteit, waarna nieuwe pods de status Pending krijgen met FailedScheduling-events. Daarom moet HPA op EC2 altijd worden gecombineerd met ofwel de Kubernetes Cluster Autoscaler of Karpenter. Het vergeten van deze combinatie is een veelvoorkomende ontwerpfout: HPA meldt “geschaald naar 20 replica’s” terwijl de helft ervan vastzit in de pending-status. Een minimale configuratie van de Cluster Autoscaler ontdekt node groups via ASG-tags:

- --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/prod-eks
- --balance-similar-node-groups
- --skip-nodes-with-system-pods=false

Met Fargate-profielen verdwijnt dit probleem — elke pod wordt zijn eigen microVM, waardoor de node-scaling dimensie volledig wordt geëlimineerd. Dit is precies waarom Fargate de juiste keuze is voor piekbelastingen met onvoorspelbare aantallen pods.

Fargate-profielen en hun feature-beperkingen

Een Fargate-profiel in EKS is een selector — een namespace plus optionele pod-labels — die EKS instrueert om overeenkomende pods op Fargate te schedulen in plaats van op een node:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata: { name: microservices, region: us-east-1 }
fargateProfiles:
  - name: fp-app
    selectors:
      - namespace: app
        labels: { compute: fargate }

De kritieke kanttekening is dat EKS op Fargate niet het volledige Kubernetes-featureoppervlak ondersteunt:

• DaemonSets worden niet uitgevoerd. Zonder een node om op te draaien, moeten log shippers zoals fluentd DaemonSets vervangen worden door sidecars of de ingebouwde Fluent Bit log router.
• Privileged containers, HostPort en HostNetwork zijn niet beschikbaar.
• Persistente opslag is beperkt tot EFS via de CSI-driver. EBS wordt niet ondersteund omdat EBS-volumes aan een specifieke EC2-instance gekoppeld moeten worden.
• GPU-workloads worden niet ondersteund.
• NodePort-services en service meshes die afhankelijk zijn van privileged init containers werken niet.

Uitgaan van feature-pariteit leidt tot mislukte migraties van StatefulSets die EBS nodig hebben, ingress controllers die hostPort gebruiken, of GPU-inferentieworkloads.

Ingress: ALB vs NLB via de AWS Load Balancer Controller

De AWS Load Balancer Controller is een Kubernetes-controller die Ingress- en Service-objecten vertaalt naar echte ALB’s en NLB’s. Voor HTTP/HTTPS-microservices met path- of host-gebaseerde routing, maak je een enkele Ingress van de klasse alb aan. Eén ALB die meerdere services bedient (via alb.ingress.kubernetes.io/group.name) is drastisch goedkoper dan één ALB per service en is het canonieke kosteneffectieve patroon:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: shop
spec:
  rules:
  - http:
      paths:
      - path: /customers
        pathType: Prefix
        backend: { service: { name: customers, port: { number: 80 }}}
      - path: /orders
        pathType: Prefix
        backend: { service: { name: orders, port: { number: 80 }}}

Gebruik een NLB (Service van het type LoadBalancer met service.beta.kubernetes.io/aws-load-balancer-type: external en target type nlb-ip) voor TCP, UDP, TLS pass-through, vereisten voor statische IP’s, of extreme Layer 4-doorvoer. Een gRPC-over-HTTP/2 of een plain-TCP database proxy achter een ALB plaatsen is alleen prima voor gRPC (ALB ondersteunt HTTP/2 en gRPC); ALB kan geen willekeurige TCP of UDP termineren. Proberen om UDP-gameverkeer via een ALB te serveren is een protocol-mismatch die tijdens de ontwerpfase moet worden opgemerkt.

IAM op Pod-niveau met IRSA

IAM Roles for Service Accounts (IRSA) is het correcte mechanisme om individuele pods AWS API-permissies te verlenen. Het koppelen van het instance profile van de node om pods S3-toegang te geven is verkeerd, omdat elke pod op de node die permissies erft, wat het ’least privilege’-principe schendt. IRSA werkt door de OIDC provider van het cluster te federeren met IAM: maak de OIDC provider eenmalig aan, en maak vervolgens een IAM-rol aan waarvan het trust policy die provider vertrouwt voor een specifiek namespace:serviceaccount-subject.

eksctl utils associate-iam-oidc-provider --cluster prod --approve

eksctl create iamserviceaccount \
  --cluster prod --namespace payments --name orders-sa \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess \
  --approve

Het service account wordt geannoteerd met eks.amazonaws.com/role-arn: arn:aws:iam::...:role/orders-role, en pods die dit mounten ontvangen kortstondige STS-credentials via een geprojecteerde token. Het overslaan van de OIDC provider-associatie of het weglaten van de annotatie valt stilzwijgend terug op de node-rol — een subtiele beveiligingsregressie die gemakkelijk over het hoofd wordt gezien bij een review.

De VPC CNI plugin vult dit aan door elke pod een routeerbaar ENI/IP-adres in het VPC-subnet toe te wijzen. Pods kunnen dan rechtstreeks communiceren met RDS, ElastiCache of VPC-eindpunten via security groups, en CloudTrail ziet het daadwerkelijke IP-adres van de pod voor auditing.

Persistente en Ephemeral Opslag

De keuze voor opslag hangt af van de access mode, duurzaamheid en het launch type.

EBS (via de EBS CSI-driver op EKS, of task-attached EBS op ECS) levert ReadWriteOnce block volumes voor stateful workloads met één pod, zoals een Postgres primary. EFS levert ReadWriteMany NFS-opslag die regionaal, multi-AZ en door vele pods tegelijk te mounten is — de juiste keuze wanneer de vereiste “highly available, fault tolerant, shared among multiple containers” of gedeelde ML-artefacten vermeldt. FSx for Lustre is voor high-throughput HPC; FSx for NetApp ONTAP en FSx for Windows File Server zijn voor enterprise NFS/SMB.

Fargate-tasks ontvangen standaard 20 GB aan ephemeral storage, configureerbaar tot 200 GB via ephemeralStorage.sizeInGiB op platform 1.4.0+. Aannemen dat Fargate altijd “genoeg scratch space” heeft, is een valkuil: een vendor-container die 50 GB aan tijdelijke bestanden schrijft, past misschien op uitgebreide ephemeral storage, maar als de vereiste 50 GB aan gedeelde of duurzame opslag is over task-restarts of tussen tasks heen, is ephemeral verkeerd omdat het wordt vernietigd wanneer de task stopt en nooit wordt gedeeld. Fargate ondersteunt geen EBS. Als een Fargate-workload persistente of gedeelde opslag nodig heeft, is EFS in wezen de enige ondersteunde optie.

Voor ECS, mount EFS rechtstreeks in de task definition; access points dwingen POSIX UID/GID en een root directory per task af, wat veilige multi-tenancy op één bestandssysteem biedt, en IAM-autorisatie beperkt elasticfilesystem:ClientMount:

"volumes": [{
  "name": "scratch",
  "efsVolumeConfiguration": {
    "fileSystemId": "fs-0abc123",
    "transitEncryption": "ENABLED",
    "authorizationConfig": {
      "accessPointId": "fsap-0def456",
      "iam": "ENABLED"
    }
  }
}],
"containerDefinitions": [{
  "name": "app",
  "mountPoints": [{
    "sourceVolume": "scratch",
    "containerPath": "/data"
  }]
}]

Voor EKS, koppel EFS via een StorageClass:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: efs-sc }
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-0123456789abcdef0
  directoryPerms: "700"

Een terugkerende valkuil: Fargate selecteren voor een stateful workload en vergeten de EFS CSI-driver en StorageClass te installeren — pods starten wel, maar PersistentVolumeClaims blijven voor altijd Pending. Omgekeerd is het kiezen van EC2-nodes puur om EBS te koppelen wanneer de vereiste gedeelde multi-writer opslag is, ook verkeerd; EBS io2 gekoppeld aan één node kan niet worden gedeeld over AZ’s.

ECR Image Scanning en Lifecycle

Amazon ECR biedt twee scanmodi. Basic scanning gebruikt de open-source Clair-database en wordt uitgevoerd bij een push (of on demand) zonder extra kosten. Enhanced scanning integreert Amazon Inspector, monitort continu op zowel OS- als taal-package CVE’s, en rapporteert bevindingen in Security Hub. Voor “scan op CVE’s, scan nieuwe images bij aanmaak, met zo min mogelijk wijzigingen aan workloads,” is de juiste actie het inschakelen van scan on push op repository-niveau — er is geen wijziging in de pipeline nodig omdat de push-gebeurtenis de scan triggert:

aws ecr put-image-scanning-configuration \
  --repository-name payments-api \
  --image-scanning-configuration scanOnPush=true

CI/CD roept vervolgens describe-image-scan-findings aan en laat builds falen bij CRITICAL of HIGH tellingen. Scannen overslaan betekent dat ongepatchte Log4j, OpenSSL of glibc CVE’s in productie draaien; de mitigatiekosten van niet scannen zijn vele malen hoger dan de bijna-nul kosten om het in te schakelen.

Lifecycle policies beperken de opslagkosten en dwingen tag-hygiëne af:

{
  "rules": [{
    "rulePriority": 1,
    "selection": {
      "tagStatus": "untagged",
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 14
    },
    "action": { "type": "expire" }
  }]
}

Kubernetes + MongoDB Workloads Migreren

Bij het overzetten van een zelf-gehoste Kubernetes + MongoDB-stack naar AWS, onder de voorwaarden “geen wijzigingen aan de applicatiecode” en “minimale operationele overhead”, zijn er twee logische keuzes. Ten eerste wordt de compute-laag verplaatst naar EKS, omdat de compatibiliteit met de Kubernetes API betekent dat manifests en Helm-charts ongewijzigd kunnen worden overgezet. Gebruik Fargate-profielen voor de stateless services om het beheer van nodes te elimineren.

Ten tweede moet MongoDB zelf niet opnieuw worden gehost op zelfbeheerde EC2 of StatefulSets. Dat zou operationele lasten zoals back-ups, sharding, failover en patching opnieuw introduceren. Gebruik Amazon DocumentDB (with MongoDB compatibility), dat het MongoDB 3.6/4.0/5.0 wire-protocol spreekt, zodat bestaande drivers en connection strings met minimale aanpassingen werken.

De compatibiliteits-kanttekening is belangrijk. DocumentDB emuleert het API-oppervlak van MongoDB, maar het is geen MongoDB. Bepaalde aggregation operators, specifieke indextypes, de semantiek van change streams en features die in nieuwere MongoDB-versies zijn geïntroduceerd, kunnen falen. De juiste stap vóór de migratie is het uitvoeren van de DocumentDB-compatibiliteitstool (compat.py) tegen de applicatie om te bevestigen dat elke operatie wordt ondersteund. De keuze voor DynamoDB zou een herschrijving van het datamodel forceren; de keuze voor RDS zou het documentmodel volledig doorbreken. Beide schenden de voorwaarde “geen codewijzigingen”.

Hybride Opties: ECS Anywhere en EKS Anywhere

ECS Anywhere registreert on-premises servers (of VM’s van andere clouds) als externe instances in een ECS-cluster. De control plane blijft in AWS; de SSM Agent en ECS Agent op de externe instance maken een uitgaande verbinding. Eén deployment-pipeline, één task definition en één set IAM-rollen dekken zowel cloud- als on-prem workloads.

EKS Anywhere installeert een conforme Kubernetes-distributie op je eigen hardware (meestal vSphere of bare metal), optioneel met inzicht via de EKS Connector in de AWS-console. Kies ECS Anywhere voor een lichtgewicht, op task definitions gebaseerde hybride oplossing; kies EKS Anywhere wanneer regelgevings- of latency-eisen vereisen dat Kubernetes lokaal draait met dezelfde tooling als EKS in de cloud. Beide houden de orkestratie consistent — de fundamentele waarde is dat teams het onderhouden van twee CI/CD-systemen of twee mentale modellen vermijden.

Zichtbaarheid over Meerdere Clusters met de EKS Connector

Organisaties draaien vaak een mix van EKS-clusters, zelfbeheerde Kubernetes op EC2 en on-premises clusters. De Amazon EKS Connector registreert elk conform Kubernetes-cluster in de EKS-console, wat een “single pane of glass” biedt voor nodes, workloads en cluster-metadata. Het is in wezen een lichtgewicht agent plus een SSM-kanaal — de oplossing met lage overhead voor een “centraal overzicht van alle clusters”. Het bouwen van vergelijkbare zichtbaarheid met zelf-gehoste Rancher, Anthos of een aangepaste Prometheus/Grafana-federatie is haalbaar, maar operationeel veel duurder en integreert niet met IAM of console-gebaseerde toegang.

EKS Connector is strikt een zichtbaarheidslaag; het beheert of upgradet het externe cluster niet, wat precies is wat “centraal overzicht met de minste overhead” impliceert.

De Patronen Samenvoegen

Voor een e-commerce workload met een load-balanced front-end, een gecontaineriseerde middle tier en een relationele database, waarbij “zo min mogelijk handmatige interventie” het criterium is, is de canonieke stack ALB → ECS on Fargate → Aurora Serverless v2. Elke laag elimineert het beheer op instance-niveau: de ALB is volledig managed, Fargate verwijdert hosts en Aurora Serverless v2 schaalt in ACU’s zonder dat je instances hoeft te dimensioneren.

Voor een microservices-platform waarbij het team “geen extra infrastructuur kan beheren”, is de juiste combinatie ECS of EKS met Fargate, plus een volledig beheerde datadienst. Het selecteren van het EC2 launch type of zelfbeheerde node groups is in tegenspraak met de randvoorwaarde, ook al zou de workload technisch gezien wel draaien.

Voor een lift-and-shift van Kubernetes + MongoDB komt de oplossing neer op EKS + DocumentDB: de Kubernetes API behoudt de deployment-methoden, DocumentDB behoudt de driver-compatibiliteit en Fargate-profielen zorgen voor minimale operationele last — op voorwaarde dat het gebruik van Kubernetes-features en het MongoDB-commando-oppervlak van de workload binnen de hierboven beschreven ondersteunde kaders vallen.

← Compute · Alle domeinen · Serverless →

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

Blader door Amazon →