Amazon SAA-C03: Management, Betrieb, Beobachtbarkeit & Kosten — Lernleitfaden

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Teil des AWS SAA-C03 — Vollständiger Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

CloudWatch: Metriken, Namespaces, Dashboards und Alarme

CloudWatch ist die Standard-Telemetrie-Ebene für AWS-Services, aber ihr Nutzen hängt vollständig davon ab, zu wissen, in welchen Namespace ein Service publiziert. Ein Namespace ist ein Container für Metriken, der Kollisionen zwischen Services verhindert – AWS/Lambda enthält Invocations, Errors und Throttles für Funktionen, während AWS/Events Invocations, FailedInvocations, TriggeredRules und MatchedEvents für EventBridge-Regeln enthält. Diese Unterscheidung ist bei der Diagnose von ereignisgesteuerten Pipelines von entscheidender Bedeutung. Wenn eine EventBridge-Regel eine Drittanbieter-API über ein API-Ziel aufruft und kein Traffic nachgelagert ankommt, liegt die Antwort nicht in AWS/Lambda, sondern in AWS/Events. Die Überprüfung von TriggeredRules zeigt Ihnen, ob das Regel-Pattern tatsächlich übereingestimmt hat, und Invocations/FailedInvocations zeigen, ob das Ziel selbst aufgerufen wurde und ob der Aufruf erfolgreich war. Die Suche in Lambda-Metriken, weil Lambda der vertrautere Service ist, übersieht die Tatsache, dass die Regel möglicherweise nie auf ein eingehendes Ereignis gepasst hat.

Die Metrik-Auflösung ist eine Einstellung pro Ressource, die Auswirkungen auf die Kosten hat. Die Basisüberwachung (Basic Monitoring) sendet Metriken alle fünf Minuten ohne zusätzliche Kosten, was für langlebige, gleichbleibende Workloads ausreicht, aber für Autoscaling-Reaktionen, die Erkennung von Lastspitzen oder SLO-Berechnungen, die eine minütliche Auflösung erfordern, viel zu grob ist. Die detaillierte Überwachung (Detailed Monitoring) reduziert dies auf eine Minute (und auf eine Sekunde für benutzerdefinierte hochauflösende Metriken), was man aktiviert, wenn Skalierungsgruppen schnell reagieren müssen. Es ist eine kostenpflichtige Funktion – weshalb sie nicht standardmäßig aktiviert ist.

Jeder Service sendet nativ einen Standardsatz von Metriken, aber der Hypervisor kann nicht in das Gastbetriebssystem hineinsehen. CPUUtilization, NetworkIn und DiskReadOps sind für EC2 ohne Aufwand sichtbar; die Speicherauslastung und die prozentuale Nutzung des Dateisystems erfordern den CloudWatch Agent, was die einzige Möglichkeit ist, sie zu erhalten. Benutzerdefinierte Anwendungsmetriken kommen ebenfalls über den Agenten oder über PutMetricData an.

Alarme sollten zwischen Signal und Rauschen unterscheiden. Ein einzelner Alarm bei CPU > 50 % wird bei normalen Lastspitzen ständig ausgelöst und trainiert die Operatoren darauf, ihn zu ignorieren. Zusammengesetzte Alarme (Composite Alarms) kombinieren die Zustände von untergeordneten Alarmen mit einem booleschen Regelausdruck, sodass Operatoren nur dann benachrichtigt werden, wenn eine wirklich handlungsrelevante Bedingung vorliegt. Für einen Workload, bei dem vorübergehende CPU-Spitzen unbedenklich sind, aber anhaltender CPU-Druck in Kombination mit erhöhten Lese-IOPS auf der Festplatte auf ein echtes Problem hinweist:

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

Untergeordnete Alarme können intern immer noch in den ALARM-Zustand übergehen, aber nur der zusammengesetzte Alarm löst SNS aus. Zwei unabhängige Alarme, die beide den Bereitschaftsdienst alarmieren, erzeugen das Rauschproblem erneut; ein einzelner Alarm mit einem höheren Schwellenwert übersieht die Korrelation.

Dashboards fassen Metrik-Widgets, Protokoll-Widgets und Text zusammen. Es gibt zwei Muster für die Freigabe, und deren Verwechslung ist eine häufige Falle. Wenn ein Betrachter bereits ein AWS-Konto hat, gewähren Sie ihm eine IAM-Identität (oder eine Rolle über kontoübergreifende Observability) mit den Berechtigungen cloudwatch:GetDashboard und cloudwatch:GetMetricData. Wenn der Betrachter kein AWS-Konto hat – ein Produktmanager, ein Stakeholder des Kunden – verwenden Sie die integrierte Dashboard-Freigabefunktion, die einen teilbaren Link erzeugt, der durch eine einzelne E-Mail/Passwort, einen Cognito User Pool oder eine öffentliche URL (selten angebracht) geschützt ist. Das Versenden von Screenshots per E-Mail ist keine Observability, und das Erstellen eines IAM-Benutzers mit Konsolenzugriff für einen Nicht-AWS-Betrachter entspricht nicht dem Prinzip der geringsten Rechte (Least Privilege).

Kontoübergreifende Observability mit OAM

Der Wechsel zwischen Dutzenden von Konten zur Ansicht von Metriken ist nicht praktikabel. Die kontoübergreifende Observability von CloudWatch legt ein Überwachungskonto (Monitoring Account) als zentralen Sink und eine beliebige Anzahl von Quellkonten (Source Accounts) fest, die Metriken, Protokolle und Traces über Sink- und Link-Ressourcen mit ihm teilen. Der schnellste Rollout in großem Maßstab besteht darin, die CloudWatch-Konsole im Überwachungskonto zu öffnen, einen Sink zu erstellen und die generierte CloudFormation StackSet-Vorlage in der gesamten Organisation bereitzustellen, um AWS::Oam::Link-Ressourcen in jedem Quellkonto zu erstellen:

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

Dies mit kontoübergreifenden IAM-Rollen und manuellen Abfragen zu lösen, ist technisch möglich, bietet Ihnen aber keine einheitlichen Dashboards, kontoübergreifende Metrics Insights-Abfragen oder die automatische Anreicherung mit Account-Namen-Labels, die OAM-Links bereitstellen.

Container Insights und verteiltes Tracing

Für containerisierte Workloads ist Container Insights die kanonische CloudWatch-Funktion. Auf EKS wird der CloudWatch Agent (oder der ADOT Collector) als DaemonSet sowie Fluent Bit für die Protokollweiterleitung bereitgestellt. Der Agent sammelt cAdvisor- und Kubelet-Metriken und sendet sie in die Namespaces ECS/ContainerInsights und ContainerInsights (CPU/Speicher pro Pod, Node, Namespace und Cluster), während Fluent Bit stdout/stderr in Protokollgruppen wie /aws/containerinsights/<cluster>/application, /dataplane und /host liefert. Es ist möglich, einen eigenen Prometheus/Grafana-Stack zu betreiben; das verwaltete Muster ist 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

Metriken sagen Ihnen, dass etwas langsam ist; Traces sagen Ihnen, wo. X-Ray instrumentiert jeden Service in einem Anfragepfad, indem es eine Trace-ID über den X-Amzn-Trace-Id-Header propagiert und Segmente sowie Subsegmente an den X-Ray-Daemon oder den ADOT Collector sendet. Die Service Map visualisiert Knoten und Kanten mit Latenz-, Fehler- und Ausfallprozentsätzen. Ohne X-Ray erscheint eine p99-Spitze als CloudWatch-Metrik ohne Zuordnung.

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 sind die drei Säulen der Observability für Microservices.

Die drei Protokollströme: CloudTrail, VPC Flow Logs, CloudWatch Logs

Jede Observability-Strategie in AWS unterscheidet drei verschiedene Protokollströme: API-Aktivitäten der Verwaltungsebene (CloudTrail), Netzwerkaktivitäten der Datenebene (VPC Flow Logs) und Anwendungs-/Betriebssystem-Ausgaben (CloudWatch Logs). Jeder Strom beantwortet eine andere forensische Fragestellung, und ihre Verwechslung ist ein häufiger Designfehler.

CloudTrail zeichnet jeden AWS-API-Aufruf auf – wer ihn aufgerufen hat (userIdentity), von welcher IP-Adresse, für welche Ressource, mit welchen Parametern und ob er erfolgreich war. Es ist der einzige Service, der eine Änderung zuverlässig einem bestimmten IAM-Prinzipal zuordnen kann. Ein weit verbreitetes Missverständnis ist, dass CloudWatch Logs der richtige Ort für die Suche nach API-Aktivitäten sei; CloudWatch Logs erfasst Anwendungs-/Systemausgaben, nicht aber Audit-Daten auf Prinzipal-Ebene. CloudTrail kann seine Ereignisse zur Echtzeit-Filterung von Metriken an CloudWatch Logs übermitteln, aber der zugrunde liegende Audit-Datensatz stammt aus CloudTrail.

In einer AWS Organizations-Umgebung ist das korrekte Muster ein Organization-Trail, der vom Verwaltungs- (oder einem delegierten Administrator-) Konto aus erstellt wird. Dieser nimmt neue Mitgliedskonten automatisch auf und streamt Ereignisse in einen einzigen S3-Bucket in einem dedizierten Log-Archiv-Konto:

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

Der Ziel-Bucket benötigt Versionierung, eine Bucket-Richtlinie, die s3:PutObject auf den CloudTrail Service-Prinzipal beschränkt, SSE-KMS-Verschlüsselung, kontoübergreifenden Lesezugriff für Auditoren und idealerweise S3 Object Lock im Compliance-Modus für WORM-Garantien. Die Protokolldatei-Validierung erzeugt signierte Digest-Dateien, sodass Manipulationen erkennbar sind. Verwaltungsereignisse sind standardmäßig für 90 Tage aktiviert; eine längere Aufbewahrung erfordert einen Trail. Datenereignisse (S3-Objektebene, Lambda-Aufrufe, DynamoDB-Elementebene) sind aufgrund des Volumens und der Kosten optional (Opt-in). Für Ad-hoc-Abfragen historischer Daten können Sie mit CloudTrail Lake oder Athena auf den Trail-Bucket SQL-Abfragen ausführen:

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

VPC Flow Logs erfassen Metadaten über den IP-Datenverkehr – das 5-Tupel, Bytes, Pakete, die Aktion (ACCEPT/REJECT) und den Protokollstatus – für eine VPC, ein Subnetz oder ein ENI. Sie erfassen keine Payloads (Nutzdaten). Ziele für die Bereitstellung sind CloudWatch Logs, S3 oder Kinesis Data Firehose. Wählen Sie S3 für die Archivierung, CloudWatch Logs, wenn Sie Metrikfilter benötigen, um Alarme bei verdächtigen Verkehrsmustern auszulösen, und Firehose, wenn die Anforderung Nahezu-Echtzeit-Analysen sind. Die kanonische Nahezu-Echtzeit-Pipeline für eine VPC mit NLBs, ASGs und Datenbanken:

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

Der alternative Pfad CloudWatch Logs → Abonnementfilter → Firehose → OpenSearch funktioniert ebenfalls, fügt aber einen zusätzlichen Schritt und Kosten hinzu. S3 ist die falsche Wahl, wenn die Anforderung „Nahezu-Echtzeit“ lautet. Die schädlichste Falle ist, Flow Logs gar nicht zu aktivieren: Bei einem Sicherheitsvorfall gibt es keine Aufzeichnungen über Quelle/Ziel/Port und keine Sichtbarkeit von ACCEPT vs. REJECT. Dasselbe gilt für ALB-Zugriffsprotokolle – sie sind optional, werden an S3 geliefert, und ohne sie gibt es keine Aufzeichnungen auf Anfrageebene über Client-IPs, Antwortcodes, Ziel-Latenzen oder User-Agents. Zusammen bilden Flow Logs (L3/L4) und ALB-Zugriffsprotokolle (L7) die Grundlage für die forensische Analyse des Datenverkehrs.

CloudWatch Logs empfängt Anwendungs-, Lambda- und Betriebssystemprotokolle über den CloudWatch Agent. Seine Stärke liegt in den Metrikfiltern: Musterausdrücke, die eingehende Ereignisse scannen und bei einer Übereinstimmung eine benutzerdefinierte Metrik erhöhen, die dann einen Alarm auslöst:

# 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]

Ein paralleler Filter für Port 3389 deckt RDP ab. Die reine Protokollaufnahme ohne Alarmierung führt zu nachträglicher Forensik, aber nicht zur Prävention.

Bei großen Flotten ist es Standard, Protokolle über einen Abonnementfilter für eine Protokollgruppe in eine Verarbeitungspipeline zu verteilen (Fan-Out), die passende Ereignisse in Nahezu-Echtzeit an einen Kinesis Data Stream, Firehose oder eine Lambda-Funktion streamt:

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

Die Falle besteht darin, Rohprotokolle ohne eine Verarbeitungspipeline zu speichern: Das Ablegen in S3 ohne Glue-Katalog, OpenSearch-Index oder Athena-Arbeitsgruppe bedeutet, dass die Protokolle zwar existieren, aber während eines Vorfalls nicht ausgewertet werden können. Observability erfordert eine Abfrageoberfläche, nicht nur dauerhaft gespeicherte Bytes. Protokollgruppen benötigen außerdem explizite Aufbewahrungsrichtlinien – die Standardeinstellung ist „Niemals ablaufen“, was still und leise Geld kostet – und können zur Langzeitarchivierung mittels Lebenszyklusregeln nach S3 exportiert werden.

API-Ereigniserkennung mit minimalem Overhead

Für hochwertige Control-Plane-Ereignisse – CreateImage, AuthorizeSecurityGroupIngress, StopLogging, ConsoleLogin ohne MFA – ist das Muster mit dem geringsten Overhead CloudTrail → EventBridge-Regel → SNS. EventBridge empfängt nativ jedes CloudTrail-Verwaltungsereignis, und eine Regel mit einem Event Pattern benötigt keinen verbindenden Lambda-Code:

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

CloudTrail-Ereignisse an CloudWatch Logs zu senden und einen Metrikfilter anzuwenden, funktioniert ebenfalls, fügt aber eine Protokollgruppe, einen Filter, einen Alarm und Kosten hinzu. Dieser Ansatz verliert also beim Betriebsaufwand, wenn die Anforderung lediglich lautet: „Bei API X alarmieren“.

AWS Config: Kontinuierliche Konfiguration und Drift

Config und CloudTrail werden oft verwechselt, beantworten aber grundlegend unterschiedliche Fragen. CloudTrail zeichnet auf, wer was aufgerufen hat; Config zeichnet auf, wie die Ressource jetzt aussieht und wie sie sich im Laufe der Zeit verändert hat. Zu erwarten, dass Config API-Aufrufe protokolliert, ist eine klassische falsche Antwort – Config weiß nicht, dass ein Benutzer PutBucketAcl aufgerufen hat; es weiß, dass sich um 14:03:22 die ACL des Buckets von Zustand A zu Zustand B geändert hat. Um den Prinzipal zu identifizieren, korrelieren Sie den Config-Änderungsdatensatz mit dem CloudTrail-Ereignis mit demselben Zeitstempel (Config verlinkt in der Konsole direkt darauf).

Config-Regeln bewerten Ressourcen anhand eines Soll-Zustands. Verwaltete Regeln (Managed Rules) decken gängige Prüfungen ab (restricted-ssh, s3-bucket-public-read-prohibited, required-tags, ec2-instance-no-public-ip, s3-bucket-versioning-enabled, desired-instance-type), und benutzerdefinierte Regeln werden als Lambda-Funktionen ausgeführt oder verwenden CloudFormation Guard. Regeln werden bei Konfigurationsänderungen und nach einem Zeitplan ausgewertet, markieren Ressourcen als COMPLIANT oder NON_COMPLIANT und können eine automatische Behebung über SSM Automation-Dokumente auslösen. Dies ist die Antwort mit geringem Betriebsaufwand auf die Frage nach der „Erkennung von offenem SSH“ oder der „Erkennung von überdimensionierten Instanztypen“ – die Regeln existieren bereits und lassen sich nativ in SNS und Security Hub integrieren. Das Vorschlagen von regelmäßigen manuellen Audits, geplanten Scans oder selbstentwickelten Scannern erfordert, dass Sie Code erstellen und warten, den Config bereits mitliefert.

Config veröffentlicht die Auswertungsergebnisse in SNS. Um die Behebung zu automatisieren, verknüpfen Sie eine EventBridge-Regel mit dem Compliance-Änderungsereignis und rufen Sie ein SSM Automation-Dokument oder eine Lambda-Funktion auf:

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

Aggregatoren konsolidieren die Compliance über eine gesamte Organisation; Konformitätspakete (Conformance Packs) bündeln Regeln für Frameworks wie PCI-DSS oder HIPAA. Workload Discovery on AWS (ehemals AWS Perspective) ist eine auf Config aufbauende Lösung, die Ressourcenbeziehungen visualisiert und Architekturdiagramme generiert – die Standardantwort, wenn eine Frage nach einem Inventarisierungstool fragt, das eine bestehende Umgebung grafisch darstellen kann. Config ist eine Voraussetzung dafür.

Security Hub, GuardDuty und Control Tower

Security Hub ist die Aggregationsebene für Sicherheitsbefunde. Er nimmt Daten von GuardDuty (Bedrohungserkennung basierend auf VPC Flow Logs, DNS und CloudTrail), Inspector (Schwachstellenbefunde), Macie, IAM Access Analyzer und Config auf und normalisiert alles in das AWS Security Finding Format (ASFF). Die Aktivierung von Security Hub aktiviert auch Sicherheitsstandards, insbesondere den AWS Foundational Security Best Practices (FSBP)-Standard – Dutzende von automatischen Prüfungen (Root-MFA, öffentliche S3-Buckets, unverschlüsselte EBS-Volumes, Multi-Region-CloudTrail), die intern auf Config-Regeln abgebildet sind.

Auf Organisationsebene bestimmen Sie ein delegiertes Administratorkonto für Security Hub (sowie für GuardDuty und Config), aktivieren den Dienst und den FSBP-Standard für die gesamte Organisation mit der Option „neue Konten automatisch aktivieren“ und leiten Befunde über EventBridge an SNS weiter, indem Sie Security Hub Findings - Imported filtern nach der FSBP-Standard-ARN mit Compliance.Status = FAILED. Die Entwicklung eigener Lambda-Funktionen zum Parsen von CloudTrail oder kontoübergreifender Dashboards verursacht zusätzlichen Betriebsaufwand, den Security Hub bereits übernimmt.

Eine entscheidende konzeptionelle Trennung: Security Hub ist detektivisch und aggregierend, nicht präventiv. Die Verhinderung von Drift ist die Aufgabe von AWS Control Tower, der eine gut architekturierte Multi-Account-Landing-Zone orchestriert. Account Factory provisioniert neue Konten mit einer grundlegenden Netzwerkkonfiguration, Protokollierung und IAM. Governance wird durch Guardrails in drei Ausprägungen umgesetzt:

Proaktive Kontrollen bewerten CloudFormation-Templates, bevor ein Stack bereitgestellt wird, und verweigern beispielsweise die Erstellung einer unverschlüsselten RDS-Instanz. Security Hub würde Ihnen nur mitteilen, dass die unverschlüsselte Instanz existiert, nachdem sie bereits läuft. Wenn eine Anforderung „verhindern“ lautet, denken Sie an Control Tower. Wenn sie „erkennen, benachrichtigen oder aggregieren“ lautet, denken Sie an Security Hub oder Config.

Macie: Erkennung sensibler Daten

Macie verwendet ML und Mustererkennung, um sensible Daten – PII, Finanzdaten, Anmeldeinformationen – in S3-Objekten zu identifizieren. Die entscheidende Falle ist die Annahme, dass Macie Daten schützt. Das tut es nicht. Macie entdeckt und berichtet. Korrekte Verwendung:

1. Aktivieren Sie Macie im Zielkonto/in der Zielregion.
2. Konfigurieren Sie einen Job zur Erkennung sensibler Daten (Sensitive Data Discovery Job), der nach einem Zeitplan auf Buckets/Präfixe/Tags abzielt.
3. Leiten Sie Befunde über EventBridge (source: aws.macie) an SNS für Benachrichtigungen, an Lambda zur Behebung (Quarantäne, Verschärfung der Bucket-Richtlinie) oder an Security Hub weiter.

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

Ohne den Erkennungsjob liefert Macie keine Ergebnisse. Ohne die Verdrahtung von EventBridge zu SNS bleiben die Befunde unbemerkt in der Macie-Konsole.

Organizations, SCPs und Tag-Richtlinien

AWS Organizations stellt drei hier relevante Richtlinientypen bereit. Tag-Richtlinien definieren erlaubte Tag-Schlüssel, deren Groß-/Kleinschreibung und Werte – sie melden Nichtkonformität und können in Kombination mit aws:ResourceTag/aws:RequestTag-Bedingungen erzwungen werden. Service Control Policies (SCPs) definieren die maximalen Berechtigungen, die für Prinzipale in Mitgliedskonten verfügbar sind. Backup-Richtlinien und AI-Opt-Out-Richtlinien runden das Set ab.

Ein entscheidendes Konzept: SCPs erteilen niemals Berechtigungen. Sie sind ein Filter für das, was IAM (Identitätsrichtlinien, Ressourcenrichtlinien, Berechtigungsgrenzen) ansonsten erlauben könnte. Ein Prinzipal muss ein IAM-Allow haben und die SCP darf die Aktion nicht mit Deny verweigern (oder muss die Aktion in ihrer Allow-Liste aufführen). „Hängen Sie einfach eine SCP an“ ist niemals eine vollständige Antwort auf eine Berechtigungsfrage – ohne ein IAM-Allow wird dem Prinzipal der Zugriff standardmäßig verweigert, unabhängig vom Inhalt der SCP.

Um Tags bei der Erstellung zu erzwingen, kombinieren Sie Tag-Richtlinien mit einer SCP wie dieser:

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

Die Tag-Richtlinie deklariert das Schema; die SCP verweigert die Erstellung ohne das Tag; die IAM-Richtlinie gewährt die Erstellungsaktion. Alle drei werden benötigt. Die required-tags-Regel von AWS Config erkennt und behebt bestehende, nicht konforme Ressourcen.

Systems Manager Automation und Patching

Systems Manager (SSM) ist das operative Rückgrat für Lifecycle-Aktivitäten über Flotten von EC2- und hybriden Knoten hinweg. Für das Patching sind zwei Konstrukte am wichtigsten: Automation-Dokumente (deklarative YAML/JSON-Runbooks, die AWS-APIs oder Skripte aufrufen) und Maintenance Windows (die diese Runbooks für tag-basierte Ziele oder Ressourcengruppen innerhalb eines Änderungsfensters mit Gleichzeitigkeits- und Fehlerschwellenwerten planen).

Der kanonische Patching-Ablauf ist AWS-RunPatchBaseline (ein Command-Dokument), das auf Instanzen ausgeführt wird, die über ein Patch-Group-Tag ausgewählt wurden, und dabei eine Patch-Baseline verwendet, die Genehmigungsregeln pro Betriebssystem definiert. Bei Instanzen hinter Load Balancern unterbricht die direkte Ausführung von AWS-RunPatchBaseline die Verbindungen mitten im Patch-Vorgang, da die Instanzen in der Zielgruppe im Status InService bleiben. Das korrekte Muster ist AWSEC2-PatchLoadBalancerInstance, welches:

1. Die Registrierung der Instanz bei ihrer CLB- oder ALB-Zielgruppe aufhebt.
2. Auf das Connection Draining / die Deregistrierungsverzögerung wartet.
3. Die Scan- und Installationsschritte der Patch-Baseline aufruft.
4. Neu startet, falls die Baseline dies erfordert.
5. Die Instanz erneut registriert und wartet, bis der Zustandscheck der Zielgruppe wieder healthy meldet.

Zwei Voraussetzungen führen zu Fehlern. Erstens muss die als AutomationAssumeRole übergebene IAM-Rolle zusätzlich zu den Standard-SSM-Patching-Berechtigungen auch elasticloadbalancing:DeregisterTargets, RegisterTargets und DescribeTargetHealth enthalten. Zweitens muss die Instanz ein verwalteter Knoten sein – der SSM Agent muss laufen und das Instanzprofil muss AmazonSSMManagedInstanceCore beinhalten. Ohne diese Voraussetzungen schlagen die Deregistrierungsaufrufe fehl oder SSM kann die Instanz nicht sehen.

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 }}'

← Sicherheit · Alle Domänen · Hochverfügbarkeit →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →