Amazon SOA-C02: Compute en Auto Scaling — Studiegids

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Onderdeel van de AWS SysOps Administrator Associate SOA-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Dit domein behandelt het beheer van EC2-instances en Auto Scaling om betrouwbare, kosteneffectieve rekenkracht te leveren. Het richt zich op de levenscyclusoperaties van instances, schaalstrategieën, load-balancer-integratie, plaatsing voor prestaties en veerkracht, en onderhouds- en beëindigingsgedrag dat de beschikbaarheid en status beïnvloedt. Operationeel meesterschap betekent het kiezen van de juiste instance types, patronen voor startconfiguraties, schaalbeleid en health-check-integratie om aan SLA’s te voldoen en tegelijkertijd de kosten te beheersen.

Levenscyclus en beheer van EC2-instances

Het beheer van de EC2-levenscyclus begint bij de startconfiguratie: gebruik Launch Templates (aws ec2 create-launch-template / console) om AMI, instance type, IAM instance profile, user-data, netwerkinterfaces, EBS-mapping en metadata-opties vast te leggen; templates ondersteunen versioning, wat immutable deploys eenvoudig maakt. Immutable deploys gebruiken een nieuwe launch-template-versie (of een nieuwe launch template) en maken ofwel een nieuwe Auto Scaling group aan, of gebruiken ASG instance refresh om instances te vervangen; vermijd in-place upgrades van draaiende instances wanneer wijzigingen het opstartgedrag of patches op AMI-niveau beïnvloeden.

Operationele CLI/console-patronen omvatten

undefined

voor eenmalige launches en

undefined

voor door ASG aangestuurde launches. Maak een keuze tussen het ‘bakken’ van AMI’s (Packer/CodeBuild) en het gebruik van user-data opstartscripts op basis van de opstarttijd: bak zware afhankelijkheden in AMI’s om de opstartduur te verkorten; gebruik user-data voor omgevingsspecifieke configuratie. Voor efemere opslag, onthoud dat instance-store volumes verloren gaan bij beëindiging; configureer root- en datavolumes met DeleteOnTermination=false als je persistentie van EBS vereist na beëindiging van de instance.

Auto Scaling Groups, beleid en lifecycle hooks

Auto Scaling Groups (ASG’s) worden geconfigureerd met een launch template of launch configuration en beheren de gewenste/minimale/maximale capaciteit over meerdere Availability Zones. Kies een launch template + MixedInstancesPolicy voor kosten-geoptimaliseerde fleets die On-Demand en Spot combineren met een lijst van instance types; gebruik instance weighting en op capaciteit geoptimaliseerde toewijzingsstrategieën voor voorspelbare capaciteit. Geef voor deployments de voorkeur aan immutable patronen: maak een nieuwe launch-template-versie aan en voer een ASG instance refresh of een blue/green swap uit in plaats van bestaande instances te herconfigureren.

Schaalbeleid wordt uitgedrukt als:

Target tracking (PolicyType=TargetTrackingScaling): stel een vooraf gedefinieerde metric in, zoals ALB RequestCountPerTarget of de gemiddelde CPU van de ASG, en een doelwaarde; de ASG handelt aanpassingen automatisch af.
Step scaling (PolicyType=StepScaling): definieer CloudWatch-alarmen die specifieke aanpassingsstappen (bijv. +2, +4) activeren op basis van de ernst van de overschrijding; nuttig voor workloads met pieken.
Simple scaling (legacy): aanpassingen in één stap met een cooldown; over het algemeen vervangen door target tracking of step scaling.

Gebruik lifecycle hooks (

undefined

) om de beëindiging/start van een instance te pauzeren. Lifecycle hooks stellen je in staat om verbindingen te ‘drainen’, de status te repliceren (naar S3/RDS), of orkestratiesystemen te informeren via SNS/SQS/Lambda vóór voltooiing; stel altijd een HeartbeatTimeout en een standaardactie in om vastgelopen statussen te voorkomen.

Elastic Load Balancing-types en health checks

Kies het type load balancer op basis van het verkeerspatroon: Application Load Balancer (ALB) voor HTTP/HTTPS met op content gebaseerde routing en host/path-regels; Network Load Balancer (NLB) voor extreme prestaties en statische IP’s voor TCP/UDP; Classic Load Balancer (CLB) alleen voor legacy-stacks. Maak ALB’s en target groups aan met

undefined

; registreer ASG-targets door de target group-associatie van de ASG te gebruiken voor automatische integratie van de levenscyclusstatus.

Integratie van health checks vereist het op elkaar afstemmen van de health checks van de ASG en de ELB: stel de HealthCheckType van de ASG in op ELB (

undefined

) zodat een instance pas als ‘healthy’ wordt beschouwd nadat de load balancer zijn target als ‘healthy’ heeft gemarkeerd. Typen health checks en hun implicaties:

ALB/NLB target group health check: ondersteunt HTTP/HTTPS/TCP en meet de gereedheid op applicatieniveau; aanbevolen voor webapplicaties.
Alleen ASG health checks: gebruik voor eenvoudige controles op hostniveau (bijv. EC2-statuscontroles).
HealthCheckGracePeriod: geef nieuwe instances de tijd om op te starten, user-data uit te voeren en de controles op applicatieniveau te doorstaan.

Implicaties van stickiness: stickiness van een ALB target group gebruikt affiniteit op basis van applicatiecookies (duur-gebaseerd), wat de sessieaffiniteit kan verbeteren maar een gelijkmatige verdeling vermindert en rolling updates compliceert. NLB ondersteunt affiniteit op basis van client-IP; gebruik stickiness alleen wanneer de sessiestatus niet geëxternaliseerd kan worden.

Plaatsing van instances, capaciteitsplanning en schalingsstatistieken

Plaatsingsbeslissingen beïnvloeden latentie en storingsdomeinen: placement groups bieden strategieën voor cluster (netwerk met lage latentie), spread (één instance per rack voor kritieke instances) en partition (fout-geïsoleerde partities). ASG’s verdelen instances standaard over AZ’s; geef de voorkeur aan AZ-bewuste capaciteitsplanning om hotspots in één AZ te vermijden. Voor de CLI: aws ec2 create-placement-group –strategy cluster|spread|partition.

Capaciteitsplanning houdt rekening met instancetypes, aankoopopties en statistieken:

Instancetypes: kies CPU/geheugen/netwerk-geoptimaliseerde families (M/C/R/T/D/I) op basis van de workload; meet met representatieve belastingstests.
Aankoop: On-Demand voor voorspelbaarheid, Reserved of Savings Plans voor kostenreducties bij een stabiele staat, Spot voor kostenefficiëntie bij tijdelijke workloads; gebruik een MixedInstancesPolicy om types en aankoopopties te combineren.
Schalingsstatistieken: standaard ASG-statistieken gebruiken de gemiddelde CPU over de groep; geef de voorkeur aan statistieken op applicatieniveau zoals ALB RequestCountPerTarget of aangepaste CloudWatch-statistieken (bijv. wachtrijdiepte) voor target tracking. Veelvoorkomende patronen:
Gebruik target tracking met ALB/request-count-per-target wanneer je een stabiel aantal verzoeken per instance nodig hebt.
Gebruik step scaling voor plotselinge, grote pieken met gedefinieerde herstelstappen.
Overweeg Predictive Scaling voor dagelijkse cyclische workloads.

Herstel van instances, beëindigingsgedrag en onderhoud

Plan voor storingen en onderhoud van instances door automatisch herstel in te schakelen voor hardwareproblemen (CloudWatch-alarm met EC2 Recover-actie) en om te gaan met geplande gebeurtenissen (describe-instance-status). Configureer de instance-initiated-shutdown-behavior- en EBS DeleteOnTermination-vlaggen om de levenscyclus van volumes te beheren; gebruik aws ec2 modify-instance-attribute --instance-id i-xxx --block-device-mappings om aanpassingen te doen.

Beëindigingsgedrag in ASG’s: Het beëindigingsbeleid van een ASG bepaalt welke instance als eerste wordt beëindigd (Standaard: oudste launch configuration of heuristieken op basis van de status van de instance en AZ-balancering). Belangrijke operationele details:

Lokale staat is efemeer: instance-store-volumes en in-memory caches gaan verloren bij beëindiging. Ga er niet van uit dat de vervangende instance de lokale staat behoudt; persisteer kritieke data naar EBS (met de juiste snapshot/back-up), S3 of een externe cache (ElastiCache).
Gebruik lifecycle hooks om verkeer af te voeren en de staat te offloaden vóór beëindiging.
Gebruik instance refresh of blue/green voor onderhoud om instances veilig te vervangen; aws autoscaling start-instance-refresh –auto-scaling-group-name my-asg –preferences file://prefs.json.

Veelvoorkomende valkuilen en beslissingscriteria

Vertrouwen op standaard cooldowns en alleen CPU-statistieken: kies statistieken die aansluiten bij het gedrag van de applicatie (ALB RequestCountPerTarget, wachtrijdiepte); stel cooldowns in om rekening te houden met de opstarttijd en stel HealthCheckGracePeriod in om oscillatie te voorkomen.
Geen lifecycle hooks gebruiken voor een graceful beëindiging: zonder hooks gaan in-flight verzoeken en lokale caches verloren; implementeer hooks met SNS/SQS/Lambda om de staat af te voeren en te persisteren.
Aannemen dat de vervangende instance de lokale staat behoudt: lokale instance-store en in-memory caches zijn efemeer; ontwerp voor stateless instances of repliceer de staat naar duurzame opslag.
Overmatig gebruik van stickiness: stickiness verhoogt een ongelijke lastenverdeling en bemoeilijkt schalen en updates; geef de voorkeur aan externe sessie-opslag (ElastiCache, DynamoDB) voor scale-out.
Negeren van AZ-balancering en placement groups: te veel instances in één AZ of cluster group plaatsen kan single points of failure creëren; gebruik de multi-AZ-distributie van ASG en de juiste strategieën voor placement groups.
Foutief configureren van de health-check-integratie: het health-check-type van de ASG moet overeenkomen met de health checks van de ELB/target-group en de HealthCheckGracePeriod moet lang genoeg zijn voor de initialisatie van de app, anders worden gezonde instances beëindigd.

Praktijkprobleem: Gebruikersscenario

StreamingCo beheert een API voor video-thumbnails die dagelijkse verkeerspieken ervaart en gebruikt lokale schijfcaches op EC2-instances; recentelijk is het opschalen traag en verliezen beëindigde instances hun cache, wat leidt tot slechte responstijden.

Migreer de launch configuration naar een Launch Template en ‘bak’ een lichtgewicht AMI met runtime-afhankelijkheden; gebruik aws ec2 create-launch-template en versioning voor immutable deploys.
Configureer een ASG met een MixedInstancesPolicy die meerdere instancetypes en een Spot + On-Demand-allocatie bevat om kosten en capaciteit in evenwicht te brengen.
Koppel een ALB en gebruik TargetTrackingScaling op de ALB RequestCountPerTarget-statistiek met een HealthCheckGracePeriod die is ingesteld op de opstarttijd van de applicatie.
Implementeer lifecycle hooks voor ASG-beëindigingen om verbindingen af te voeren en een Lambda/SNS-flow uit te voeren om de benodigde cache-sleutels te persisteren naar ElastiCache of S3 vóór de beëindiging.
Externaliseer de sessie- en cache-staat naar ElastiCache of S3 en gebruik placement groups/AZ-distributie om te voldoen aan de vereisten voor latentie en storingsdomeinen.

Rationale: Het gebruik van launch templates en immutable deploys vermindert de variabiliteit bij het opstarten; op ALB gerichte target tracking koppelt schaling aan de verzoekbelasting in plaats van aan de CPU; lifecycle hooks voorkomen dataverlies bij beëindiging; het externaliseren van de cache elimineert de afhankelijkheid van efemere lokale staat, wat snel en veilig schalen mogelijk maakt tegen lagere kosten door gemengde instance- en aankoopstrategieën.

← Opslag en Databeheer · Alle domeinen · Databases en Caching →

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