Amazon SAA-C03: Compute, Auto Scaling & Instancebeheer — 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.

EC2 Instance Types en AMI’s

Het selecteren van de juiste EC2-instancefamilie is de basis van een goed ontworpen compute-laag, omdat familie, generatie en grootte samen de CPU-architectuur, de geheugen-naar-vCPU-ratio, de netwerkbandbreedte en de beschikbare accelerators bepalen. General purpose (M6i, M7g, T-series) is geschikt voor gebalanceerde web-tiers en gemengde workloads. Compute-optimized (C7i, C7gn) is geschikt voor CPU-intensieve simulaties, encoding, batchverwerking en web-front-ends. Memory-optimized (R7i, X2idn) is gericht op in-memory databases en caches. Storage-optimized (I4i, D3) is gericht op NoSQL, HDFS en data warehousing. Accelerated (P5, G5, Trn1, Inf) levert GPU’s of ML-silicon. Graviton-instances (g-suffix) leveren doorgaans 20-40% betere prijs-prestatieverhouding voor scale-out workloads die zonder problemen compileren naar ARM64.

De T-familie is ‘burstable’ en gebruikt standaard de standard mode, waarbij CPU-credits worden opgebouwd tijdens inactiviteit en verbruikt tijdens pieken; wanneer de credits op zijn, wordt de performance beperkt tot de baseline. Voor workloads met onvoorspelbare pieken — kleine web-tiers, dev/test-omgevingen, of Elastic Beanstalk-omgevingen die een piekerige front-end ondersteunen — laten T-instances in unlimited mode de instance credits lenen en wordt een kleine toeslag per vCPU-uur overschrijding in rekening gebracht, waardoor voor de gebruiker zichtbare ’throttling’ wordt vermeden. Dit is waarom Beanstalk-omgevingen met korte CPU-saturatie meestal worden opgelost door de unlimited mode in te schakelen in plaats van te upgraden naar een duurdere compute-optimized familie. Het is belangrijk om de T-serie te reserveren voor echt piekerige workloads met een laag gemiddeld verbruik: een aanhoudend hoog CPU-gebruik in de standard mode verbruikt alle credits binnen enkele minuten.

Verticale schaalvergroting (overstappen naar een grotere omvang binnen dezelfde familie) wordt beperkt door de grootst beschikbare instance, vereist downtime voor de wijziging, introduceert een ‘single point of failure’ en kan de workload niet spreiden over meerdere Availability Zones. Wanneer de belasting aanzienlijk varieert, is horizontale schaalvergroting met een Auto Scaling group het juiste antwoord.

Golden AMI’s ‘bakken’ de applicatiecode, runtime en afhankelijkheden in de root snapshot, wat resulteert in snelle, deterministische launches — cruciaal wanneer Auto Scaling reageert op een piek. Bootstrappen via user-data bij elke launch voegt minuten aan latentie toe op precies het verkeerde moment.

Opslagkeuzes: Instance Store vs EBS, Snapshots en Fast Snapshot Restore

Instances bieden twee soorten opslag: instance store (kortstondige NVMe gekoppeld aan de fysieke host) en Amazon EBS (via het netwerk gekoppelde blokopslag). Instance store levert de laagst mogelijke latentie, maar de data wordt vernietigd bij een stop, hibernate, terminate of hardwarefout. Het behandelen als duurzame opslag is een veelgemaakte en gevaarlijke fout — het is alleen geschikt voor tijdelijke opslag (‘scratch space’), buffers, caches of gerepliceerde data zoals een HDFS-datanode waarvan de replica’s op andere nodes bestaan. Duurzame data hoort thuis op EBS, ondersteund door snapshots die zijn opgeslagen in S3.

Snapshots zijn incrementeel en onafhankelijk zodra ze zijn aangemaakt, dus het herstellen van een snapshot naar een nieuw volume heeft nooit invloed op de bron. De canonieke manier om een grote productiedataset te dupliceren naar een testomgeving is door een snapshot te maken van het bronvolume en nieuwe volumes aan te maken vanuit dat snapshot. Echter, volumes die hersteld zijn vanuit snapshots laden blokken via ’lazy-loading’ vanuit S3 bij de eerste leestoegang, wat aanzienlijke I/O-latentie veroorzaakt totdat elk blok is ‘gehydrateerd’. Hetzelfde ’lazy-loading’-effect treedt op bij nieuwe instances die worden gestart vanaf AMI’s met grote root snapshots — ze voelen traag aan gedurende enkele minuten na de launch.

EBS Fast Snapshot Restore (FSR) elimineert deze ‘penalty’. Schakel FSR in op de snapshot voor de AZ’s waar de ASG instances lanceert, en volumes die ervan worden aangemaakt, leveren onmiddellijk de volledige ‘provisioned’ performance:

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

Dit is essentieel wanneer scale-out-gebeurtenissen capaciteit moeten toevoegen in seconden in plaats van minuten.

Enhanced Networking met ENA en EFA

De geadverteerde netwerkdoorvoer schaalt mee met de grootte van de instance, maar is alleen haalbaar als de Elastic Network Adapter (ENA)-driver aanwezig is. ENA biedt ’enhanced networking’ op basis van SR-IOV en ondersteunt tot 200 Gbps op nieuwere instances. Moderne AMI’s (Amazon Linux 2, recente Ubuntu, Windows) worden geleverd met ENA ingeschakeld; verifieer dit met:

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].EnaSupport'

modinfo ena | grep version
ethtool -i eth0

Zonder ENA vallen instances stilzwijgend terug op een lagere doorvoer en hogere jitter, wat elk low-latency-ontwerp ondermijnt, ongeacht de gekozen placement group.

Voor collectieve bewerkingen op microseconde-schaal — CFD, weermodellering, moleculaire dynamica, training van grote modellen — voeg Elastic Fabric Adapter (EFA) toe. EFA stelt een OS-bypass transport (Libfabric) beschikbaar aan MPI en NCCL, waardoor de netwerkstack van de kernel volledig wordt vermeden. EFA levert zijn voordeel alleen binnen een cluster placement group op ondersteunde instance-types (c7gn, hpc7a, p5), en vereist de EFA-driver plus een compatibele MPI (Open MPI, Intel MPI) of NCCL-build.

aws ec2 create-placement-group --group-name hpc-cg --strategy cluster
aws ec2 run-instances --instance-type hpc7a.96xlarge \
  --placement GroupName=hpc-cg \
  --network-interfaces InterfaceType=efa,DeviceIndex=0,SubnetId=subnet-abc

Plaatsingsgroepen

Plaatsingsgroepen (placement groups) bepalen de fysieke topologie van instances:

Een verkeerde keuze verspilt de functionaliteit. Een clustergroep kan geen AZ’s overspannen — deze is per definitie intra-AZ. Spread kan geen honderd webservers hosten vanwege het plafond van zeven per AZ. Partition placement, niet spread, is de juiste tool voor een Kafka-cluster van 40 nodes, omdat het de plaatsing van replica’s afstemt op foutdomeinen. Voor algemene hoge beschikbaarheid, beperk een ASG niet tot één plaatsingsgroep in één AZ — spreid de ASG uit over meerdere AZ’s.

Voor streaming analytics of MPI-workloads die minimale node-to-node latency vereisen, is de juiste combinatie een cluster placement group plus ENA-enabled instances; cluster minimaliseert het aantal hops en ENA levert de packets-per-second-capaciteit die nodig is om dat latency-voordeel te realiseren.

Auto Scaling Groups en Launch Templates

Een Auto Scaling group (ASG) is de runtime-eenheid die een gewenst aantal EC2-instances handhaaft over een of meer AZ’s, gedefinieerd door drie gehele getallen — MinSize, DesiredCapacity, MaxSize — en een lijst van subnets. De ASG zelf beschrijft niet wat er gestart moet worden; dat is de verantwoordelijkheid van een launch template, de moderne vervanging voor launch configurations. Launch templates ondersteunen versioning, mixed instance policies, het mixen van Spot/On-Demand, IMDSv2-handhaving, capacity reservations en T-instances in unlimited-mode. Een launch template verwijst naar een AMI, instance type(s), security groups, IAM instance profile, user data en block device mappings.

Het canonieke stateless-webpatroon is AMI + Launch Template + ASG + ALB. De AMI zorgt voor snel opstarten; de ALB (of NLB voor TCP/UDP) verdeelt het verkeer en voert health checks uit; de ASG registreert automatisch nieuwe instances in de target group en beëindigt ongezonde instances. Een multi-AZ-implementatie (minimaal twee AZ’s, drie voor quorumsystemen) is verplicht — een ASG die aan één subnet is gekoppeld, kan een AZ-storing niet overleven omdat de ASG zelf geen vervangingen kan starten terwijl de AZ is aangetast.

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    DesiredCapacity: 4
    VPCZoneIdentifier: [subnet-a, subnet-b]
    TargetGroupARNs: [!Ref AppTargetGroup]
    LaunchTemplate:
      LaunchTemplateId: !Ref AppLT
      Version: !GetAtt AppLT.LatestVersionNumber
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120

Schalingsbeleid: Target Tracking, Step, Scheduled, Predictive

ASG-schaling heeft vier modi, die elk een ander probleem oplossen:

• Target tracking pikt een metriek op en houdt deze rond een ingestelde waarde (bijv. ASGAverageCPUUtilization = 50%, ALBRequestCountPerTarget = 1000). Het is zelfsturend — AWS beheert de alarms en past de snelheid aan naarmate de metriek afwijkt. Dit zou de standaardkeuze moeten zijn.
• Step scaling voegt capaciteit toe of verwijdert deze in graduele stappen, gebaseerd op hoe ver een metriek buiten het bereik is. Dit is nuttig wanneer de reactiegrootte moet meeschalen met de ernst van het alarm.
• Simple scaling is verouderd: één aanpassing per alarm, blokkeert tijdens de cooldown-periode en moet niet worden gekozen voor nieuwe ontwerpen.
• Scheduled scaling past MinSize/DesiredCapacity/MaxSize aan op cron-tijden.
• Predictive scaling gebruikt machine learning op tot 14 dagen aan geschiedenis om de komende 48 uur te voorspellen, en provisioneert capaciteit voordat de piek optreedt.

Dynamische schaling loopt inherent achter — het reageert pas nadat een metriek een drempel overschrijdt, en nieuwe instances hebben dan minuten nodig om op te starten, te registreren en op te warmen. Voor een bedrijfsapplicatie waar gebruikers allemaal om 09:00 uur arriveren en 2-3 uur traagheid ervaren terwijl de ASG probeert bij te benen, is alleen dynamische schaling het verkeerde antwoord. Voeg scheduled actions toe vóór de piek om MinSize en DesiredCapacity te verhogen voordat de vraag arriveert:

ScheduledAction:
  AutoScalingGroupName: web-asg
  ScheduledActionName: pre-sale-warmup
  Recurrence: "0 8 * * *"
  MinSize: 20
  DesiredCapacity: 30
  MaxSize: 200

Laat vervolgens target tracking de resterende variabiliteit opvangen. Predictive scaling is de juiste keuze wanneer de vorm van de piek stabiel is, maar de exacte timing van dag tot dag varieert. Voor voorspelbare non-productie shutdowns (ontwikkelomgevingen uit tijdens nachten en weekenden), is een scheduled action om desired=0, min=0 in te stellen op vrijdagavond en weer op te schalen op maandagochtend de oplossing met de minste overhead — de ASG zelf fungeert als de schedule engine, er is geen Lambda of EventBridge-lijmcode nodig.

De keuze van de metriek is net zo belangrijk als de keuze van het beleid. CPU werkt voor CPU-gebonden web-workloads, maar voor backlog-gedreven workers die uit SQS putten, moet je schalen op de wachtrijdiepte, niet op CPU: een worker die geblokkeerd is op I/O kan 10% CPU-gebruik tonen terwijl miljoenen berichten zich opstapelen. Gebruik ApproximateNumberOfMessagesVisible per instance, beschikbaar gemaakt als een custom metric of via de ingebouwde SQSQueueBacklogPerInstance target:

backlog_per_instance = messages_visible / running_instances
target = acceptable_latency_seconds / avg_processing_seconds_per_msg

TargetTrackingConfiguration:
  CustomizedMetricSpecification:
    MetricName: BacklogPerInstance
    Namespace: MyApp/Scaling
    Statistic: Average
  TargetValue: 100

Op dezelfde manier moeten latency-gevoelige HTTP-lagen TargetResponseTime of RequestCountPerTarget volgen; apps die beperkt worden door geheugen, schijf of downstream-latency moeten een custom metric publiceren die de echte bottleneck weerspiegelt. Schalen op CPU wanneer CPU niet de beperkende factor is, leidt precies tot het faalscenario waarbij instances nooit uitschalen, wachtrijen onbeperkt groeien en de ALB 5xx-foutmeldingen retourneert.

Health Checks en Lifecycle Hooks

ASG’s gebruiken standaard EC2-statuscontroles, die hypervisor-storingen detecteren, maar geen applicatiestoringen. Het inschakelen van ELB-healthchecks op de ASG delegeert de beslissing tot vervanging aan de applicatieniveau-probe van de load balancer, wat essentieel is wanneer het besturingssysteem in orde is, maar het proces is vastgelopen. Stel HealthCheckGracePeriod lang genoeg in zodat user data kan voltooien, anders worden nieuwe instances midden in het bootstrap-proces beëindigd in een lus.

De keuze van de load balancer beïnvloedt de betekenis van “healthy”:

Een HTTP-applicatie achter een NLB die alleen TCP-healthchecks uitvoert, blijft verkeer ontvangen van een instance die verbindingen accepteert maar 500-fouten retourneert. Schakel over naar een ALB — of configureer HTTP-healthchecks op de NLB — om betekenisvolle signalering te herstellen.

Lifecycle hooks pauzeren instances in de status Pending:Wait of Terminating:Wait zodat externe automatisering kan ingrijpen. Bij het opstarten stelt een hook je in staat om te registreren bij een configuratiemanagementsysteem, caches op te warmen of secrets op te halen voordat de ALB verkeer doorstuurt. Bij beëindiging stelt een hook je in staat om sessies af te bouwen (drainen), logs weg te schrijven en de registratie bij een service mesh ongedaan te maken. Hooks zenden EventBridge-events uit; handlers moeten CompleteLifecycleAction aanroepen, anders verloopt de hook door een time-out naar zijn standaardactie (CONTINUE of ABANDON).

Warm Pools en Hibernation

De opstarttijd vanuit een koude start (‘cold-launch’) is een reëel probleem voor applicaties die grote modellen laden, caches opwarmen of JIT-compileren voordat ze verzoeken kunnen verwerken. Een warm pool is een vooraf geïnitialiseerde reserve die aan de ASG is gekoppeld: instances starten op, voeren de bootstrap uit en worden vervolgens gestopt, draaiend gehouden of in hibernation geplaatst, en in de pool bewaard totdat de ASG uitschaalt. Het gebruiken van een instance uit de pool slaat minuten aan opstarttijd over.

Hibernation pauzeert het besturingssysteem naar het versleutelde EBS-rootvolume, zodat de JVM-heap, ML-gewichten en de OS-page-cache terugkeren bij het hervatten. Vereisten: een versleuteld rootvolume dat groot genoeg is voor het RAM, instance-RAM ≤ 150 GB op een ondersteunde family, en HibernationOptions.Configured = true bij het opstarten. Een warm pool met PoolState: Hibernated combineert beide — instances kosten niets voor compute terwijl ze gestopt zijn en hervatten binnen seconden met een gevuld geheugen. Dit is het juiste patroon wanneer een applicatie “veel tijd nodig heeft om geheugen te laden voordat deze productief is.”

Auto-Recovery voor niet-schaalbare workloads

Niet elke workload schaalt horizontaal. Legacy-applicaties met licenties die aan een MAC-adres zijn gekoppeld, bestandsgebaseerde locks, of in-memory sessiestatus zonder een gedeelde opslag kunnen niet op meer dan één instance draaien — het opstarten van extra nodes veroorzaakt datacorruptie of licentieschendingen. Voor deze workloads komt veerkracht van automatisch herstel (automatic recovery), niet van uitschalen.

Twee patronen werken hiervoor. Een CloudWatch-alarm op StatusCheckFailed_System in combinatie met de EC2-herstelactie behoudt de instance-ID, het privé-IP, de Elastic IP en EBS-koppelingen bij een storing van de onderliggende host. Nog eenvoudiger: een ASG met MinSize=MaxSize=1 die meerdere AZ’s omspant, vervangt een falende instance en kan, in tegenstelling tot de herstelactie, een AZ-storing overleven — op voorwaarde dat de status buiten het rootvolume is opgeslagen of de AMI opnieuw kan worden opgebouwd.

Load Balancers en Subnet-plaatsing

ALB werkt op L7, termineert HTTP/HTTPS en biedt routing op basis van host/pad/header, HTTP/2, WebSockets en integratie met WAF/Cognito/OIDC. NLB werkt op L4, behoudt het client-IP, ondersteunt statische IP’s en TLS-passthrough, PrivateLink, en kan miljoenen verbindingen per seconde aan. Gateway Load Balancer voegt appliances van derden (zoals firewalls, IDS) in het verkeerspad in.

De plaatsing van subnets is waar architecturen het vaakst misgaan. Een internet-facing ALB moet gekoppeld zijn aan publieke subnets — subnets met een 0.0.0.0/0-route naar een Internet Gateway — één per AZ waar de targets zich bevinden. De targets zelf blijven in private subnets. Als de ALB in private subnets wordt geplaatst, of als de “publieke” subnets geen default route naar een IGW hebben, krijgen clients te maken met connection timeouts. Voor de bereikbaarheid van de targets moet de security group van de target inkomend verkeer van de security group van de ALB op de target-poort toestaan; er is geen NAT nodig tussen de ALB en targets in dezelfde VPC.

Client → IGW → ALB (public subnets, SG: allow 443 from 0.0.0.0/0)
              → Targets (private subnets, SG: allow 8080 from ALB-SG)

Schakel ELB-healthchecks in op de ASG zodat ongezonde targets worden vervangen en niet alleen gederegistreerd. Cross-zone load balancing (standaard op ALB, opt-in op NLB) verdeelt de verzoeken gelijkmatig, ongeacht het aantal instances per AZ. Route 53 moet naar de ALB verwijzen via een alias record (of een weighted/latency policy over meerdere ALB’s) — verwijs Route 53 nooit naar individuele EC2 IP-adressen, omdat een falende instance verkeer blijft ontvangen totdat de TTL verloopt en de vervangende instance van de ASG een ander IP-adres heeft.

Aankoopmodellen en Gemengde Instance-vloten

De keuze van het aankoopmodel is de belangrijkste hefboom om de uitgaven aan EC2 te verminderen, onafhankelijk van het architectuurpatroon.

De rationele strategie: basislast op Reserved Instances of een Savings Plan, pieken op On-Demand, fouttolerant werk op Spot. In een ASG wordt dit uitgedrukt als een mixed-instances policy:

MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-0abc123
      Version: $Latest
    Overrides:
      - InstanceType: m5.large
      - InstanceType: m5a.large
      - InstanceType: m6i.large
      - InstanceType: m6a.large
  InstancesDistribution:
    OnDemandBaseCapacity: 4          # covered by Savings Plan
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: price-capacity-optimized

Het diversifiëren van instance types verdiept de Spot-pool en vermindert gecorreleerde onderbrekingen. price-capacity-optimized (of capacity-optimized) balanceert prijs met pooldiepte, zodat instances minder waarschijnlijk worden teruggevorderd.

Spot is geschikt voor stateless, checkpointable, opnieuw-probeerbare of horizontaal redundante workloads: web workers achter een ALB, Batch-jobs met automatische retry, Spark executors, CI runners. Het is niet geschikt als de enige capaciteit voor kritieke, altijd-actieve services, stateful primaire databases of leader-nodes zonder herstelpad — een melding van twee minuten kan geen veilige shutdown garanderen, en een gecorreleerde, vlootbrede terugvordering van een specifiek instance type is een reële faalmodus. Wanneer de eis “mag niet worden onderbroken” is, valt Spot af.

De omgekeerde valkuil is het toepassen van RIs of Savings Plans op werkelijk variabele workloads: je betaalt de uurlijkse verbintenis, of je die nu gebruikt of niet. Een workload die 40 uur per week draait onder een 168-uurs verbintenis, verspilt dus 76% van de reservering. Wanneer capaciteit zelf — niet de prijs — de zorg is (event-driven piek, disaster recovery), gebruik dan een On-Demand Capacity Reservation: een pure, op AZ-gescoopte garantie tegen On-Demand-tarieven, combineerbaar met een Savings Plan voor de korting.

Serverless Compute: Lambda en Fargate

Serverless verschuift het capaciteitsbeheer naar het platform. Lambda is geschikt voor event-driven, kortstondig werk: S3 ObjectCreated-triggers, DynamoDB Streams, SQS-consumers met laag volume, API Gateway-backends, ‘glue logic’. Geheugen (128 MB – 10.240 MB) wijst CPU proportioneel toe, dus het verhogen van het geheugen verlaagt vaak de kosten door de duur te verkorten. Harde limieten bepalen de scope: maximale executietijd van 15 minuten, 10 GB geheugen, 10 GB /tmp, 250 MB ongezipte deployment (of 10 GB via een container image), 6 MB synchrone payload. Lambda gebruiken voor een videotranscodering van 30 minuten, een ETL van meerdere uren of GPU-training is architectonisch verkeerd — de functie krijgt een time-out halverwege het werk en de retry-logica vermenigvuldigt de verspilling alleen maar. Voor latentiegevoelige paden, vermijd cold starts en de initialisatietijd van aan VPC gekoppelde ENI’s met Provisioned Concurrency.

Fargate draait containers zonder EC2-hosts te beheren. Het is de juiste keuze wanneer taken langer dan 15 minuten duren, aangepaste runtimes nodig hebben, of passen binnen ECS/EKS-orkestratie maar het team geen capaciteit wil beheren. Fargate is duurder per vCPU-uur dan EC2 Spot, dus wanneer het steady-state gebruik hoog en voorspelbaar is, is een mixed-instance ASG met Spot op ECS goedkoper. Voor piekbelasting of onvoorspelbaar verkeer wint de facturering per seconde van Fargate.

Voor orkestratie over vele Lambda’s is Step Functions te verkiezen boven het koppelen via SNS/SQS, omdat het een visuele executiegeschiedenis, retry-semantiek, gecentraliseerde foutafhandeling en duurzame state biedt. Standard workflows factureren per state-transitie en kunnen tot een jaar draaien; Express workflows optimaliseren voor eventverwerking met hoog volume en korte duur.

Voor de fan-out van duizenden geparametriseerde, gecontaineriseerde jobs — genomics, Monte Carlo, ETL — handelt AWS Batch wachtrijen, afhankelijkheidsresolutie, retries en provisioning af over beheerde EC2, Spot of Fargate. Jobs verwijzen naar een jobdefinitie (container + vCPU/geheugen + IAM-rol) en Batch ‘bin-packt’ ze op instances van de juiste grootte. Step Functions orkestreert vaak Batch, Lambda en ECS binnen één state machine.

Elastic Beanstalk

Beanstalk is een beheerde PaaS die de ALB, ASG, EC2-instances en optioneel RDS provisioneert vanuit een applicatiebundel. Het ondersteunt rolling, rolling-with-additional-batch, immutable en blue/green deployments met CloudWatch-integratie. Schaalbeleid wordt blootgesteld als omgevingsopties (metric, drempelwaarden, min/max). Omdat Beanstalk standaard burstable instance types gebruikt, is het inschakelen van de T-unlimited modus de eenvoudige oplossing voor korte CPU-saturatie. Geplande schaalacties worden gekoppeld aan de door Beanstalk beheerde ASG, net als elke andere. Kies Beanstalk wanneer het team een standaard web-app-topologie wil zonder handmatig CloudFormation te schrijven en wanneer rolling updates en geversioneerde bundels overeenkomen met de release-cadans.

Fleetbeheer met Systems Manager

SSH- en bastion-patronen zijn fragiel en duur om te beveiligen. AWS Systems Manager vervangt deze. De SSM Agent (vooraf geïnstalleerd op Amazon Linux 2, Ubuntu, Windows) plus een instance profile dat AmazonSSMManagedInstanceCore verleent, is alles wat nodig is.

• Run Command voert shell/PowerShell uit over getagde fleets met geconsolideerde output.
• Session Manager opent interactieve shells via de AWS API — geen inkomend poort 22-verkeer, geen bastion, volledige IAM-authenticatie, en sessies worden gelogd naar S3 of CloudWatch Logs.
• Patch Manager past OS-patches toe volgens schema’s met behulp van maintenance windows.

aws ssm send-command \
  --targets Key=tag:Env,Values=prod \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["yum -y update"]'

Geplande Start/Stop-automatisering

Voor niet-productie EC2 en RDS die buiten kantooruren uit moeten staan, is het onderhoudsarme patroon EventBridge Scheduler → Lambda. Een cron-regel (cron(0 19 ? * MON-FRI *)) roept een Lambda aan die getagde resources stopt; een tweede regel om 07:00 start ze weer.

import boto3
ec2 = boto3.client('ec2'); rds = boto3.client('rds')

def handler(event, _):
    action = event['action']  # 'start' or 'stop'
    ids = [i['InstanceId'] for r in ec2.describe_instances(
        Filters=[{'Name':'tag:AutoStop','Values':['true']}]
    )['Reservations'] for i in r['Instances']]
    getattr(ec2, f'{action}_instances')(InstanceIds=ids)
    for db in rds.describe_db_instances()['DBInstances']:
        if any(t['Key']=='AutoStop' and t['Value']=='true' for t in db['TagList']):
            getattr(rds, f'{action}_db_instance')(DBInstanceIdentifier=db['DBInstanceIdentifier'])

Dit is serverless, heeft geen fleet om te patchen en schaalt op basis van tags. De AWS Instance Scheduler-oplossing werkt op een gelijkwaardige manier. Een belangrijk detail: een gestopte RDS-instance start na zeven dagen automatisch op, dus het stopschema moet herhaald worden om deze opnieuw te stoppen. In combinatie met ASG’s waarvan de geplande acties de capaciteit in het weekend naar nul brengen, naderen de kosten voor inactieve uren nul.

Netwerkvalkuilen bij Geschaalde Compute

Plaatsing van NAT Gateway. Een NAT gateway bevindt zich in één AZ. Een fleet die drie AZ’s omspant en al het uitgaande verkeer via één enkele NAT in us-east-1a routeert, betaalt voor inter-AZ-overdracht voor elk pakket vanuit us-east-1b/us-east-1c, en verliest de uitgaande connectiviteit volledig wanneer us-east-1a uitvalt. Het correcte patroon is één NAT gateway per AZ, waarbij de route table van elk private subnet verwijst naar de NAT in zijn eigen AZ. Dit lokaliseert het verkeer en elimineert de single-AZ failure mode.

NAT-instances. Een enkele, op EC2 gebaseerde NAT wordt een bandbreedte- en PPS-bottleneck naarmate de fleet groeit, en is een SPOF. Beheerde NAT Gateways schalen tot 100 Gbps per gateway. Voor verkeer naar AWS-services omzeilen VPC endpoints (Gateway voor S3/DynamoDB, Interface voor andere) NAT volledig, wat kosten bespaart en het risico op verzadiging tijdens schaalgebeurtenissen elimineert.

Terugkerende Ontwerpvalkuilen

• Single-AZ ASG’s kunnen een AZ-storing niet overleven — koppel altijd subnets uit minstens twee AZ’s (drie voor quorumsystemen), en houd MinSize ≥ 2 aan.
• Ervan uitgaan dat elke workload horizontaal schaalt. Stateful, single-writer, of niet-clusterbare licentie-apps presteren slechter onder een ASG. Gebruik eerst auto-recovery of refactor de applicatie.
• Reactief schalen voor voorspelbare pieken veroorzaakt het symptoom ’traag gedurende de eerste 2-3 uur’. Gebruik scheduled of predictive scaling om vooraf op te warmen.
• Schalen op basis van CPU wanneer CPU niet de beperkende factor is. Publiceer een metric die de werkelijke bottleneck weerspiegelt — wachtrijdiepte, responstijd, aantal verbindingen.
• Simple scaling en launch configurations zijn verouderd — geef de voorkeur aan target tracking en launch templates.
• Alleen TCP-healthchecks op HTTP-apps laten defecte instances in de rotatie. Gebruik HTTP-checks (via een ALB, of NLB-checks in HTTP-modus).
• Spot gebruiken voor stateful workloads of workloads die niet onderbroken mogen worden — Spot vereist workers die checkpointable en vervangbaar zijn.
• Reserved Instances of Savings Plans gebruiken voor echt variabele workloads — de ongebruikte toezegging is pure verspilling; verlaag in plaats daarvan de kosten met right-sizing en Spot.
• Route 53 laten verwijzen naar individuele EC2 IP-adressen — routeer naar de ALB-alias zodat DNS de veranderingen in de fleet weerspiegelt.
• Instance store als duurzaam beschouwen — data verdwijnt bij een stop, terminate of host-storing.
• De lazy-load-latentie negeren na een snapshot-herstel of AMI-lancering — activeer Fast Snapshot Restore in de doel-AZ’s.

Alle domeinen · Containers →

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

Blader door Amazon →