Amazon SAP-C02: Compute & Auto Scaling — Studiegids

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Onderdeel van de AWS Solutions Architect Professional SAP-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

EC2 instance design, opslag en netwerken

Het ontwerpen van EC2-instances begint met het afstemmen van workload-kenmerken op instance-families, waarbij een balans wordt gezocht tussen vCPU, geheugen, netwerk en lokale opslag. Kies op basis van profilering voor rekenkracht-geoptimaliseerde (C), geheugen-geoptimaliseerde (R/X), opslag-geoptimaliseerde (I/D) of GPU (P/G) types. Maak gebruik van op Nitro gebaseerde instances en ENA/SR-IOV voor hoge netwerkdoorvoer en lage latentie. Overweeg voor latentiegevoelige of tijdelijke data met hoge IOPS een instance store (ephemeral) op I3/I4 of Nitro SSD’s; gebruik voor duurzame blokopslag EBS met Provisioned IOPS (io2/io2 Block Express) en schakel EBS-encryptie in met KMS voor sleutelbeheer. Wanneer instances zich in VPC’s achter Application Load Balancers bevinden, zorg er dan voor dat internetgerichte ALB’s in publieke subnets worden geplaatst en de targets in private subnets; het verkeerd plaatsen van ALB’s of het onjuist configureren van security groups is een veelvoorkomende valkuil. Gebruik Placement Groups (cluster voor HPC met lage latentie, partition voor grootschalige gedistribueerde stateful systemen, spread voor foutisolatie) om de plaatsing te beïnvloeden, maar accepteer de compromissen: cluster geeft de beste prestaties maar vermindert de fouttolerantie op AZ-niveau. Gebruik voor versleutelde data-in-transit TLS-terminatie op de ALB of end-to-end TLS met NLB-passthrough. Beslissingscriteria wegen kosten af tegen prestaties: dichtere instance types verlagen de kosten, maar kunnen de ‘blast radius’ en licentiekosten verhogen; geef de voorkeur aan right-sizing op basis van CloudWatch, AWS Compute Optimizer en loadtests in plaats van vuistregels.

Auto Scaling groups, beleid en lifecycle management

Auto Scaling Groups (ASG’s) moeten worden ontworpen voor elasticiteit, veerkracht en kostenefficiëntie met een combinatie van launch templates, mixed-instances policies, lifecycle hooks en schaalbeleid. Gebruik launch templates voor het versioneren van AMI’s, instance type overrides, EBS-configuraties en user-data; mixed-instances met een capacity-optimized Spot-allocatie of een gediversificeerde strategie vermindert het risico op onderbrekingen en verlaagt de kosten. Geef voor schaalgedrag de voorkeur aan target-tracking policies voor voorspelbare metrics (CPU, aantal verzoeken per target) en step-scaling wanneer drempelgestuurde, meertrapsacties nodig zijn; predictive scaling kan capaciteit vooraf provisioneren voor bekende dag-en-nachtpatronen. Implementeer lifecycle hooks om aangepaste initialisatie- of ‘drain’-taken uit te voeren vóór beëindiging; combineer warm pools om de ’time-to-serve’ te verkorten en scheduled scaling voor basiscapaciteit tijdens kantooruren. Health checks moeten ELB- en EC2-health checks integreren om vroegtijdige vervanging te voorkomen. Pas op voor valkuilen zoals ‘scale-in churn’ veroorzaakt door agressieve cooldowns, onjuiste instance-weging in gemengde ASG’s en het niet meerekenen van de opwarmtijd van de applicatie. Vermijd bij stateful services snelle scale-in die in-memory caches verloren laat gaan; voor kosten versus veerkracht biedt door Spot ondersteunde capaciteit met On-Demand als fallback besparingen, maar vereist het afhandelen van onderbrekingen, terwijl 100% On-Demand de voorspelbaarheid maximaliseert tegen hogere kosten.

Containers en orkestratie: keuzes tussen ECS, EKS en Fargate

De keuze tussen Amazon ECS, EKS en Fargate hangt af van het operationele model, de behoefte aan controle en de workload-patronen. Fargate neemt het node-beheer weg en is ideaal voor teams die operationele eenvoud prioriteren, maar het heeft een hogere prijs per vCPU en limieten voor ephemeral storage; het ondersteunt Fargate Spot voor kostenbesparingen. ECS biedt een strakke AWS-integratie en eenvoud voor klanten die containerorkestratie willen zonder de complexiteit van Kubernetes. EKS is geschikt wanneer het Kubernetes-ecosysteem, portabiliteit of geavanceerde scheduling vereist is; overweeg managed node groups of Self-Managed + Karpenter voor dynamische right-sizing. Netwerklimieten (ENI/pod-dichtheid) en CNI-gedrag beïnvloeden de pod-dichtheid en de grootte van de nodes; op EKS verminderen IAM Roles for Service Accounts en de EBS CSI voor persistente volumes de wildgroei van credentials en maken ze opslag per pod mogelijk. Gebruik voor gedeelde bestandssystemen EFS (NFS) of FSx (Lustre), afhankelijk van de doorvoer- en latentiebehoeften; vermijd containers met NFS-backend voor operaties met veel metadata—geef de voorkeur aan EFS met doorvoermodi die zijn afgestemd op de workload. Implementeer de cluster autoscaler of Karpenter voor node-scaling en service auto scaling met ALB/ECS service metrics. Veelvoorkomende valkuilen zijn het negeren van pod disruption budgets, het onderschatten van de Kubernetes control plane-quota en het overprovisioneren van nodes in plaats van het gebruik van ‘bin-pack’-strategieën—de afwegingen tussen controle, kosten en operationele overhead moeten de keuze bepalen.

Serverless compute-patronen, Lambda-beperkingen en event-driven design

Serverless vermindert de operationele overhead, maar vereist architectuurpatronen die rekening houden met concurrency, state en de limieten van downstream systemen. Lambda is uitstekend geschikt voor kortstondige, event-driven taken, API-backends via API Gateway of een ALB, en asynchrone verwerking met SQS of SNS. Gebruik Step Functions voor het orkestreren van langlopende workflows en DynamoDB of RDS Proxy voor databasetoegang om ‘connection storms’ te voorkomen. Houd rekening met de VPC cold-start overhead van Lambda die wordt veroorzaakt door het aanmaken van ENI’s; beperk dit met ‘provisioned concurrency’ voor latency-gevoelige endpoints of gebruik VPC-endpoints en RDS Proxy om het aantal verbindingen te limiteren. Implementeer fan-out/fan-in via SNS + SQS, of Kinesis/MKS voor geordende streamverwerking; gebruik SQS dead-letter queues en idempotente handlers om retries en duplicaten te beheren. Concurrency-limieten, ‘reserved concurrency’ en ’throttling’ moeten worden gepland om trapsgewijze storingen (cascading failures) te voorkomen; ontwerp voor tegendruk (backpressure) met behulp van throttles, retries met jitter en circuit breakers (API Gateway of custom). De afwegingen tussen kosten en prestaties zijn duidelijk: Lambda is kosteneffectief voor piekbelastingen en kortdurend werk, terwijl Fargate of EC2 beter zijn voor langdurige taken met een aanhoudend hoge CPU-belasting. Veelvoorkomende valkuilen zijn het vertrouwen op synchrone retries die downstream systemen overbelasten, het opslaan van state in de lokale /tmp-map in de veronderstelling dat dit persistent is, en het niet provisioneren voor cold starts in latency-kritieke flows.

Praktijkprobleem: Migratie van het contactcenter van NovaTel Enterprise

Scenario: NovaTel Enterprise beheert een hybride contactcenter met on-premises call routing en een Direct Connect naar AWS. Ze draaien session brokers op EC2 in twee Availability Zones en willen migreren naar een door AWS beheerd contactcenter met hoge beschikbaarheid en voorspelbare latency tussen de on-premises PBX en de clouddiensten.

Uitdaging: Ze hebben een low-latency verbinding nodig voor SIP-verkeer, een schaalbare compute-laag voor spraakverwerking die onderbrekingen van Spot Instances tolereert, en een DR-strategie over meerdere Regions zonder de operationele complexiteit te verhogen.

Aanbevolen Aanpak:

Provisioneer Amazon Connect voor de contactcenterfunctionaliteit en gebruik een Site-to-Site VPN of Direct Connect met een AWS Transit Gateway voor low-latency SIP-trunking, die termineert op een NLB met TLS passthrough voor de session brokers.
Draai de componenten voor sessieverwerking als een gemengde Auto Scaling Group met launch templates die gebruikmaken van ‘capacity-optimized’ Spot Instances met een On-Demand fallback, en gebruik Placement Groups (spread) voor foutisolatie van kritieke brokers.
Gebruik voor stateful call media die efemere low-latency opslag vereist, instances met instance stores (Nitro) voor mediabuffering en repliceer sessiemetadata naar DynamoDB of ElastiCache met multi-AZ-replicatie; zet RDS (Multi-AZ) of Aurora Global DB in voor persistente data met cross-Region read replica’s voor DR.
Implementeer lifecycle hooks en warm pools om de cold-start van brokers te minimaliseren, Route 53 weighted failover voor cross-Region DR, en CloudWatch + SNS/SQS voor alarmering en geautomatiseerde failover-runbooks.

Redenering: Het gebruik van beheerde contactcenterdiensten vermindert de operationele last, terwijl gemengde ASG’s met Spot de kosten optimaliseren; het isoleren van efemere media op instance stores behoudt de prestaties, en duurzame replicatie van state naar DynamoDB/ElastiCache plus multi-AZ RDS/Aurora biedt veerkracht en snelle failover, in lijn met de best practices voor professionele architectuur.

← Beveiliging · Alle domeinen · Opslag →

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