Amazon SAA-C03: Beheer, Operations, Observeerbaarheid & Kosten — 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.

CloudWatch: Metrics, Namespaces, Dashboards en Alarmen

CloudWatch is het standaard telemetrieplatform voor AWS-services, maar het nut ervan hangt volledig af van de kennis in welke namespace een service publiceert. Een namespace is een container voor metrics die conflicten tussen services voorkomt — AWS/Lambda bevat Invocations, Errors en Throttles voor functies, terwijl AWS/Events Invocations, FailedInvocations, TriggeredRules en MatchedEvents bevat voor EventBridge-regels. Dit onderscheid is belangrijk bij het diagnosticeren van event-driven pipelines. Als een EventBridge-regel een API van een derde partij aanroept via een API-bestemming en er geen verkeer downstream aankomt, ligt het antwoord niet in AWS/Lambda; het ligt in AWS/Events. Het controleren van TriggeredRules vertelt je of het regelpatroon daadwerkelijk overeenkwam, en Invocations/FailedInvocations vertellen je of de target zelf werd aangeroepen en of die aanroep succesvol was. Het doorzoeken van Lambda-metrics omdat Lambda de bekendere service is, negeert het feit dat de regel mogelijk nooit een inkomend event heeft gematcht.

De resolutie van metrics is een instelling per resource met kostenimplicaties. Standaard monitoring zendt elke vijf minuten metrics uit zonder extra kosten, wat voldoende is voor langlopende steady-state workloads, maar veel te grof voor autoscaling-reacties, piekdetectie of SLO-berekeningen die een resolutie per minuut vereisen. Gedetailleerde monitoring verlaagt dat naar één minuut (en naar één seconde voor custom high-resolution metrics), wat je inschakelt wanneer scaling groups snel moeten reageren. Het is een betaalde feature — daarom staat het niet standaard aan.

Elke service zendt standaard een set metrics uit, maar de hypervisor kan niet in het gastbesturingssysteem kijken. CPUUtilization, NetworkIn en DiskReadOps zijn zonder moeite zichtbaar voor EC2; geheugengebruik en gebruikspercentages van het bestandssysteem vereisen de CloudWatch agent, wat de enige manier is om deze te verkrijgen. Custom applicatiemetrics komen ook binnen via de agent of via PutMetricData.

Alarmen moeten signaal van ruis onderscheiden. Een enkel alarm op CPU > 50% gaat constant af tijdens normale pieken en leert operators om het te negeren. Samengestelde alarmen combineren de statussen van onderliggende alarmen met een booleaanse regelexpressie, zodat operators alleen worden gealarmeerd wanneer er een daadwerkelijk actiegerichte situatie is. Voor een workload waar tijdelijke CPU-pieken onschadelijk zijn, maar aanhoudende CPU-druk in combinatie met verhoogde disk read IOPS een echt probleem aangeeft:

HighCPUAlarm:
  MetricName: CPUUtilization
  Threshold: 50
  EvaluationPeriods: 3
  Period: 60
  ComparisonOperator: GreaterThanThreshold

HighDiskReadAlarm:
  MetricName: DiskReadOps
  Threshold: 1000
  EvaluationPeriods: 3
  Period: 60

CompositeAlarm:
  AlarmRule: >
    ALARM("HighCPUAlarm") AND ALARM("HighDiskReadAlarm")
  AlarmActions:
    - arn:aws:sns:us-east-1:111122223333:ops-pager

Onderliggende alarmen kunnen intern nog steeds overgaan naar de ALARM-status, maar alleen het samengestelde alarm triggert SNS. Twee onafhankelijke alarmen die beide on-call pagen, creëren opnieuw het ruisprobleem; een enkel alarm op een hogere drempel mist de correlatie.

Dashboards aggregeren metric widgets, log widgets en tekst. Er bestaan twee patronen voor delen en het verwarren hiervan is een veelvoorkomende valkuil. Als een gebruiker al een AWS-account heeft, geef hem dan een IAM-identiteit (of een rol via cross-account observability) met cloudwatch:GetDashboard en cloudwatch:GetMetricData. Als de gebruiker geen AWS-account heeft — een productmanager, een stakeholder van de klant — gebruik dan de ingebouwde deelfunctie voor dashboards, die een deelbare link produceert die wordt beschermd door een enkel e-mailadres/wachtwoord, een Cognito user pool, of een openbare URL (zelden gepast). Screenshots e-mailen is geen observability, en een IAM-gebruiker met consoletoegang aanmaken voor een niet-AWS-gebruiker is geen least-privilege.

Cross-Account Observability met OAM

Wisselen tussen tientallen accounts om metrics te bekijken is onhoudbaar. CloudWatch cross-account observability wijst een monitoring-account aan als een centrale sink en een willekeurig aantal bronaccounts die metrics, logs en traces ermee delen via sink- en link-resources. De snelste uitrol op schaal is om de CloudWatch-console in het monitoring-account te openen, een sink te creëren en de gegenereerde CloudFormation StackSet-template over de organisatie uit te rollen om AWS::Oam::Link-resources in elk bronaccount aan te maken:

Resources:
  ObservabilityLink:
    Type: AWS::Oam::Link
    Properties:
      LabelTemplate: "$AccountName"
      ResourceTypes:
        - AWS::CloudWatch::Metric
        - AWS::Logs::LogGroup
        - AWS::XRay::Trace
      SinkIdentifier: arn:aws:oam:us-east-1:111122223333:sink/abc-123

Dit oplossen met cross-account IAM-rollen en handmatige queries is technisch mogelijk, maar geeft je geen uniforme dashboards, cross-account Metrics Insights-queries of de automatische verrijking met accountnaam-labels die OAM-links bieden.

Container Insights en Distributed Tracing

Voor gecontaineriseerde workloads is Container Insights de standaard CloudWatch-feature. Op EKS implementeert het de CloudWatch agent (of de ADOT collector) als een DaemonSet plus Fluent Bit voor log forwarding. De agent haalt cAdvisor- en kubelet-metrics op en zendt deze uit naar de ECS/ContainerInsights- en ContainerInsights-namespaces (CPU/geheugen per pod, node, namespace en cluster), terwijl Fluent Bit stdout/stderr naar loggroepen zoals /aws/containerinsights/<cluster>/application, /dataplane en /host stuurt. Je eigen Prometheus/Grafana-stack opzetten is mogelijk; het beheerde patroon is Container Insights plus Logs Insights:

fields @timestamp, kubernetes.pod_name, log
| filter kubernetes.namespace_name = "payments"
| filter log like /ERROR/
| stats count() by kubernetes.pod_name

Metrics vertellen je dat iets traag is; traces vertellen je waar. X-Ray instrumenteert elke service in een request-pad, propageert een trace-ID via de X-Amzn-Trace-Id-header en zendt segmenten en subsegmenten naar de X-Ray daemon of ADOT collector. De service map visualiseert nodes en edges met latency-, error- en fault-percentages. Zonder X-Ray verschijnt een p99-piek als een CloudWatch-metric zonder toewijzing.

from aws_xray_sdk.core import xray_recorder, patch_all
patch_all()  # instruments boto3, requests, sqlalchemy, etc.

@xray_recorder.capture('checkout')
def checkout(order_id): ...

Container Insights plus X-Ray plus CloudWatch Logs vormen de drie pijlers voor de observability van microservices.

De Drie Logstromen: CloudTrail, VPC Flow Logs, CloudWatch Logs

Elke observability-strategie in AWS onderscheidt drie afzonderlijke logstromen: API-activiteit op het management-plane (CloudTrail), netwerkactiviteit op het data-plane (VPC Flow Logs), en applicatie- en OS-output (CloudWatch Logs). Elk beantwoordt een andere forensische vraag, en het door elkaar halen hiervan is een veelvoorkomende ontwerpfout.

CloudTrail registreert elke AWS API-aanroep — wie deze heeft aangeroepen (userIdentity), vanaf welk IP-adres, tegen welke resource, met welke parameters, en of de aanroep succesvol was. Het is de enige service die een mutatie betrouwbaar koppelt aan een specifieke IAM principal. Een veelvoorkomend misverstand is dat CloudWatch Logs de juiste plek is om te zoeken naar API-activiteit; CloudWatch Logs legt applicatie- en systeemoutput vast, geen auditgegevens op principal-niveau. CloudTrail kan zijn events afleveren bij CloudWatch Logs voor real-time metric filtering, maar het onderliggende auditrecord is afkomstig uit CloudTrail.

In een AWS Organizations-omgeving is het correcte patroon een organization trail die wordt aangemaakt vanuit het management- (of delegated administrator-)account. Deze schrijft automatisch nieuwe member-accounts in en streamt events naar één enkele S3-bucket in een toegewijd log-archive-account:

CentralTrail:
  Type: AWS::CloudTrail::Trail
  Properties:
    IsOrganizationTrail: true
    IsMultiRegionTrail: true
    IncludeGlobalServiceEvents: true
    EnableLogFileValidation: true       # SHA-256 digest chain
    S3BucketName: org-cloudtrail-logs
    KMSKeyId: !Ref TrailKmsKey

De doel-bucket vereist versioning, een bucket policy die s3:PutObject beperkt tot de CloudTrail service principal, SSE-KMS-encryptie, cross-account read-only toegang voor auditors, en idealiter S3 Object Lock in compliance mode voor WORM-garanties. Log file validation produceert ondertekende digest-bestanden zodat manipulatie detecteerbaar is. Management events zijn standaard 90 dagen ingeschakeld; voor langere retentie is een trail vereist. Data events (S3 object-level, Lambda invoke, DynamoDB item-level) zijn opt-in vanwege het volume en de kosten. Voor ad-hoc historische queries kunt u met CloudTrail Lake of Athena tegen de trail-bucket SQL-queries uitvoeren:

SELECT userIdentity.arn, eventTime, requestParameters
FROM cloudtrail_logs
WHERE eventName = 'AuthorizeSecurityGroupIngress'
  AND eventTime BETWEEN '2024-01-08' AND '2024-01-12';

VPC Flow Logs leggen metadata vast over IP-verkeer — de 5-tuple, bytes, packets, action (ACCEPT/REJECT) en logstatus — voor een VPC, subnet of ENI. Ze leggen geen payloads vast. Afleverdoelen zijn CloudWatch Logs, S3 of Kinesis Data Firehose. Kies S3 voor archivering; kies CloudWatch Logs als u metric filters nodig heeft om alarmen te activeren op basis van verdachte verkeerspatronen; kies Firehose als de vereiste near-real-time analytics is. De canonieke near-real-time pipeline voor een VPC met NLB’s, ASG’s en databases:

ENIs → VPC Flow Logs (delivery: Kinesis Data Firehose)
      → Firehose delivery stream (optional Lambda transform)
      → Amazon OpenSearch Service (index: vpc-flow-*)
      → OpenSearch Dashboards

Het alternatieve pad CloudWatch Logs → subscription filter → Firehose → OpenSearch werkt ook, maar voegt een extra stap en kosten toe. S3 is de verkeerde keuze als de vereiste “near real time” is. Het helemaal niet inschakelen van Flow Logs is de meest schadelijke valkuil: wanneer een beveiligingsincident plaatsvindt, is er geen registratie van bron/bestemming/poort en geen inzicht in ACCEPT versus REJECT. Dezelfde redenering is van toepassing op ALB access logs — opt-in, afgeleverd bij S3, en zonder deze logs is er geen registratie op request-niveau van client-IP’s, response codes, target latencies of user agents. Samen vormen Flow Logs (L3/L4) en ALB access logs (L7) de basis voor verkeersforensisch onderzoek.

CloudWatch Logs ontvangt applicatie-, Lambda- en OS-logs via de CloudWatch agent. De kracht ervan komt van metric filters: patroonexpressies die inkomende events scannen en bij een match een custom metric verhogen, die vervolgens een alarm aanstuurt:

# Metric filter detecting inbound SSH sessions from Flow Logs
[version, account, eni, source, dest, srcport, destport=22,
 protocol=6, packets, bytes, start, end, action=ACCEPT, status]

Een parallel filter op poort 3389 dekt RDP af. Log-ingestie zonder alarmering levert forensische data op na een incident, geen preventie.

Voor grote fleets is de standaard om logs uit te waaieren (fan-out) naar een verwerkingspipeline via een subscription filter op een log group, waarbij overeenkomende events in near real time worden gestreamd naar een Kinesis Data Stream, Firehose of Lambda:

{
  "filterPattern": "",
  "destinationArn": "arn:aws:firehose:us-east-1:111122223333:deliverystream/logs-to-os"
}

De valkuil is het versturen van onbewerkte logs naar opslag zonder een verwerkingspipeline: het dumpen naar S3 zonder Glue catalog, zonder OpenSearch index en zonder Athena workgroup betekent dat logs wel bestaan, maar dat er tijdens een incident geen actie op kan worden ondernomen. Observability vereist een query-oppervlak, niet alleen duurzaam opgeslagen bytes. Log groups hebben ook expliciete retention policies nodig — de standaard is “nooit verlopen”, wat stilletjes geld kost — en kunnen worden geëxporteerd naar S3 voor langetermijnarchivering onder lifecycle rules.

Detectie van Events op API-Niveau met de Minste Overhead

Voor waardevolle control-plane-events — CreateImage, AuthorizeSecurityGroupIngress, StopLogging, ConsoleLogin zonder MFA — is het patroon met de laagste overhead CloudTrail → EventBridge rule → SNS. EventBridge ontvangt native elk CloudTrail management event, en een rule met een event pattern heeft geen Lambda-lijmcode nodig:

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["CreateImage"]
  }
}

CloudTrail naar CloudWatch Logs sturen en een metric filter toepassen werkt ook, maar voegt een log group, filter, alarm en kosten toe, en verliest het dus op operationele overhead wanneer de eis simpelweg “alarmeer bij API X” is.

AWS Config: Continue Configuratie en Drift

Config en CloudTrail worden vaak door elkaar gehaald, maar beantwoorden fundamenteel verschillende vragen. CloudTrail legt vast wie wat aanriep; Config legt vast hoe de resource er nu uitziet en hoe deze in de loop van de tijd is veranderd. Verwachten dat Config API-aanroepen logt, is een klassiek fout antwoord — Config weet niet dat een gebruiker PutBucketAcl heeft aangeroepen; het weet dat om 14:03:22 de ACL van de bucket veranderde van staat A naar staat B. Om de principal te identificeren, correleer je de Config-wijzigingsrecord met de CloudTrail-gebeurtenis op hetzelfde tijdstip (Config linkt hier diep naar in de console).

Config-regels evalueren resources ten opzichte van een gewenste staat. Beheerde regels (managed rules) dekken veelvoorkomende controles (restricted-ssh, s3-bucket-public-read-prohibited, required-tags, ec2-instance-no-public-ip, s3-bucket-versioning-enabled, desired-instance-type), en aangepaste regels (custom rules) draaien als Lambda-functies of gebruiken CloudFormation Guard. Regels worden geëvalueerd bij configuratiewijzigingen en op een schema, markeren resources als COMPLIANT of NON_COMPLIANT, en kunnen automatisch herstel activeren via SSM Automation-documenten. Dit is het antwoord met lage operationele overhead op vragen als “detecteer open SSH” of “detecteer te grote instance types” — de regels bestaan al en integreren native met SNS en Security Hub. Het voorstellen van periodieke handmatige audits, geplande scans of zelfgebouwde scanners vereist dat je code bouwt en onderhoudt die Config al standaard levert.

Config publiceert evaluatieresultaten naar SNS. Om herstel te automatiseren, koppel je een EventBridge-regel aan de compliance-wijzigingsgebeurtenis en roep je een SSM Automation-document of Lambda aan:

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

Aggregators consolideren compliance binnen een hele organisatie; conformance packs bundelen regels voor raamwerken zoals PCI-DSS of HIPAA. Workload Discovery on AWS (voorheen AWS Perspective) is een oplossing gebouwd op Config die relaties tussen resources visualiseert en architectuurdiagrammen genereert — het canonieke antwoord wanneer een vraag vraagt om een inventarisatietool die een bestaande omgeving in kaart kan brengen. Config is een vereiste.

Security Hub, GuardDuty en Control Tower

Security Hub is het aggregatieplatform voor beveiligingsbevindingen. Het ontvangt data van GuardDuty (dreigingsdetectie op basis van VPC Flow Logs, DNS en CloudTrail), Inspector (kwetsbaarheidsbevindingen), Macie, IAM Access Analyzer en Config, en normaliseert alles naar het AWS Security Finding Format (ASFF). Het inschakelen van Security Hub activeert ook beveiligingsstandaarden, met name de AWS Foundational Security Best Practices (FSBP)-standaard — tientallen automatische controles (root MFA, publieke S3, niet-versleutelde EBS, multi-region CloudTrail) die onder de motorkap zijn gekoppeld aan Config-regels.

Op organisatieschaal, wijs een gedelegeerd beheerdersaccount (delegated administrator account) aan voor Security Hub (en voor GuardDuty en Config), schakel de service en de FSBP-standaard in voor de hele organisatie met de “auto-enable new accounts”-schakelaar, en routeer bevindingen via EventBridge naar SNS door Security Hub Findings - Imported te matchen, gefilterd op de FSBP-standaard-ARN met Compliance.Status = FAILED. Het zelf bouwen van een Lambda die CloudTrail parset of dashboards per account voegt operationele last toe die Security Hub al op zich neemt.

Een cruciale conceptuele scheiding: Security Hub is detectief en aggregatief, niet preventief. Het voorkomen van drift is de taak van AWS Control Tower, dat een goed ontworpen multi-account landing zone orkestreert. Account Factory provisioneert nieuwe accounts met een basislijn voor netwerken, logging en IAM. Governance wordt uitgedrukt via ‘guardrails’ in drie smaken:

Proactieve controles evalueren CloudFormation-templates voordat een stack wordt geïmplementeerd en weigeren bijvoorbeeld een niet-versleutelde RDS-instance aan te maken. Security Hub zou je pas vertellen dat de niet-versleutelde instance bestaat nadat deze draait. Als een vereiste “voorkomen” zegt, denk dan aan Control Tower. Als het “detecteren, melden of aggregeren” zegt, denk dan aan Security Hub of Config.

Macie: Ontdekking van Gevoelige Data

Macie gebruikt ML en patroonherkenning om gevoelige data — PII, financiële gegevens, credentials — binnen S3-objecten te identificeren. De kritieke valkuil is aannemen dat Macie data beschermt. Dat doet het niet. Macie ontdekt en rapporteert. Correct gebruik:

1. Schakel Macie in voor het doelaccount/de doelregio.
2. Configureer een sensitive data discovery job, gericht op buckets/prefixes/tags volgens een schema.
3. Routeer bevindingen via EventBridge (source: aws.macie) naar SNS voor notificaties, Lambda voor herstel (quarantaine, aanscherpen van bucket policy), of naar Security Hub.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

Zonder de discovery job produceert Macie niets. Zonder de EventBridge → SNS-koppeling blijven bevindingen onopgemerkt in de Macie-console.

Organizations, SCP’s en Tag Policies

AWS Organizations biedt drie beleidstypes die hier relevant zijn. Tag policies definiëren toegestane tag-sleutels, hoofdlettergebruik en waarden — ze rapporteren non-compliance en kunnen, in combinatie met aws:ResourceTag/aws:RequestTag-condities, worden afgedwongen. Service Control Policies (SCPs) definiëren de maximale permissies die beschikbaar zijn voor principals in lid-accounts. Backup policies en AI opt-out policies maken de set compleet.

Een cruciaal mentaal model: SCPs verlenen nooit permissies. Ze zijn een filter over wat IAM (identity policies, resource policies, permissions boundaries) anders zou kunnen toestaan. Een principal moet een IAM Allow hebben en de SCP mag de actie niet weigeren met een Deny (of moet de actie opnemen in zijn Allow-lijst). “Koppel gewoon een SCP” is nooit een volledig antwoord op een permissievraagstuk — zonder een IAM Allow wordt de principal standaard de toegang geweigerd, ongeacht de inhoud van de SCP.

Om tags te vereisen bij het aanmaken van resources, combineer je tag policies met een SCP zoals:

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Resource": "*",
  "Condition": {
    "Null": { "aws:RequestTag/CostCenter": "true" }
  }
}

De tag policy declareert het schema; de SCP weigert het aanmaken zonder de tag; de IAM policy verleent de create-actie. Alle drie zijn nodig. De required-tags-regel van AWS Config detecteert en herstelt bestaande niet-conforme resources.

Systems Manager Automation en Patching

Systems Manager (SSM) is de operationele ruggengraat voor lifecycle-activiteiten voor groepen EC2- en hybride nodes. Twee constructies zijn het belangrijkst voor patching: Automation documents (declaratieve YAML/JSON-runbooks die AWS API’s of scripts aanroepen) en Maintenance Windows (die deze runbooks inplannen voor op tags gebaseerde targets of resourcegroepen binnen een change window met concurrency- en foutdrempels).

De canonieke patching-flow is AWS-RunPatchBaseline (een Command document) die wordt uitgevoerd op instances geselecteerd door een Patch Group-tag, met behulp van een Patch Baseline die goedkeuringsregels per OS definieert. Voor instances achter load balancers verbreekt het direct uitvoeren van AWS-RunPatchBaseline de verbindingen midden in het patch-proces, omdat de instances InService blijven in de target group. Het correcte patroon is AWSEC2-PatchLoadBalancerInstance, dat:

1. De instance deregistreert uit zijn CLB- of ALB-target group.
2. Wacht op connection draining / de deregistration delay.
3. Roept de scan- en installatiestappen van de patch baseline aan.
4. Herstart de instance als de baseline dit vereist.
5. Registreert de instance opnieuw en wacht tot de target health-status healthy teruggeeft.

Twee voorwaarden veroorzaken de “produces errors”-foutmodus. Ten eerste moet de IAM-rol die wordt doorgegeven als AutomationAssumeRole de permissies elasticloadbalancing:DeregisterTargets, RegisterTargets en DescribeTargetHealth bevatten, naast de standaard SSM-patchingpermissies. Ten tweede moet de instance een managed node zijn — wat betekent dat de SSM Agent draait en het instance profile AmazonSSMManagedInstanceCore bevat. Zonder deze voorwaarden mislukken de deregistration-aanroepen of kan SSM de instance niet zien.

schemaVersion: '0.3'
description: Patch instance behind ALB
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  InstanceId: { type: String }
  TargetGroupArn: { type: String }
  AutomationAssumeRole: { type: String }
mainSteps:
  - name: deregister
    action: aws:executeAwsApi
    inputs:
      Service: elbv2
      Api: DeregisterTargets
      TargetGroupArn: '{{ TargetGroupArn }}'

← Beveiliging · Alle domeinen · Hoge beschikbaarheid →

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

Blader door Amazon →