Amazon SOA-C02: Kostenmanagement und Ressourcen-Tagging — Lernleitfaden
Teil des AWS SysOps Administrator Associate SOA-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.
Kostenmanagement und Ressourcen-Tagging sind zentrale operative Tätigkeiten, die die Cloud-Ausgaben sichtbar, vorhersagbar und kontrolliert halten. Eine genaue Abrechnung und Berichterstattung ermöglichen es Betreibern, Kosten Teams, Projekten und Umgebungen zuzuordnen; Tagging in Verbindung mit durchgesetzten Richtlinien ermöglicht eine automatisierte interne Weiterverrechnung und Bereinigung. Die aktive Nutzung von Cost Explorer, Cost and Usage Reports, Budgets und Optimierungstools begrenzt Verschwendung und liefert Informationen für Kaufentscheidungen wie Savings Plans oder Reserved Instances. Das Verständnis dienstspezifischer Kostentreiber (Netzwerk, Speicher, Load Balancer, NAT) verhindert unerwartete Gebühren für ausgehenden Datenverkehr (Egress) und verwaltete Dienste.
Grundlagen zu Abrechnung, Kostenberichten und Cost Explorer
Aktivieren Sie die konsolidierte Abrechnung über AWS Organizations und stellen Sie den Cost and Usage Report (CUR) in einem S3-Bucket mit stündlicher Granularität und Ressourcen-IDs bereit, um eine detaillierte Zuordnung zu unterstützen. Aktivieren Sie in der Billing-Konsole Kostenzuordnungs-Tags (sowohl von AWS generierte als auch benutzerdefinierte), damit Cost Explorer und der CUR Tag-Spalten enthalten. Für den programmgesteuerten Zugriff verwenden Sie die Cost Explorer API oder die CLI: zum Beispiel
undefined
.
Nutzen Sie den Cost Explorer für interaktive Trendanalysen und Rightsizing-Ansichten: Aktivieren Sie den Bericht „Rightsizing Recommendations“, filtern Sie nach Tag oder verknüpftem Konto und exportieren Sie die Empfehlungen als CSV-Dateien. Für automatisierte Workflows nehmen Sie den CUR in Athena auf (erstellen Sie eine externe Tabelle für die CUR-Dateien), um SQL-Abfragen über verschiedene Dimensionen (linkedAccountId, productName, usageType, resourceId, Tags) auszuführen. Kombinieren Sie Athena-Abfragen mit Glue-Crawlern, um Dashboards in QuickSight zu erstellen oder eine abrechnungsgesteuerte Automatisierung zu versorgen.
Entscheidungskriterien für die Wahl der Granularität und Aufbewahrung von Berichten:
- Verwenden Sie den stündlichen CUR, wenn Sie eine instanzgenaue interne Weiterverrechnung oder eine Automatisierung für kurzlebige Instanzen benötigen.
- Verwenden Sie den täglichen CUR für monatliche Trendanalysen, wenn das stündliche „Rauschen“ nicht erforderlich ist.
- Aktivieren Sie Ressourcen-IDs, wenn Sie Abrechnungsdaten mit dem Inventar (Tag Editor, Resource Groups) für eine genaue Zuordnung verknüpfen möchten.
Tagging-Strategien für Kostenzuordnung und Governance
Führen Sie eine disziplinierte Taxonomie für Tag-Schlüssel ein (zum Beispiel: CostCenter, Owner, Project, Environment, Lifecycle) und setzen Sie diese bei der Erstellung von Ressourcen durch. Aktivieren Sie diese Schlüssel als Kostenzuordnungs-Tags in der Billing-Konsole, damit sie im Cost Explorer und im CUR erscheinen. Implementieren Sie die Durchsetzung mit:
- Tag-Richtlinien in AWS Organizations, um erlaubte Schlüssel und Werte vorzuschreiben.
- der verwalteten AWS Config-Regel
required-tags, um fehlende Tags zu erkennen. - IAM-Berechtigungen oder Service Control Policies, um die Erstellung von Ressourcen ohne die erforderlichen Tags zu verweigern (verwenden Sie die Condition Keys
aws:RequestTagundaws:TagKeys).
Verwenden Sie die Resource Groups Tagging API und den Tag Editor, um Tags regionsübergreifend zu prüfen und zu korrigieren: zum Beispiel
undefined
. Automatisieren Sie die Weitergabe von Tags aus CI/CD oder CloudFormation, indem Sie Tags auf Stack-Ebene anfügen und Lambda-basierte Hooks verwenden, um Laufzeit-Metadaten (instanceId, launchTime) zu Ressourcen hinzuzufügen.
Abwägungen bei der Wahl der Tag-Durchsetzung:
- Strikte Durchsetzung (Erstellung ohne Tags verweigern) verhindert das Entstehen nicht getaggter Ressourcen, kann aber kurzlebige Entwickler-Workflows blockieren, sofern keine Ausnahmen definiert sind.
- Erkennen und korrigieren (Config + Automatisierung) ist reibungsärmer, führt aber zu einer Verzögerung zwischen der Erstellung und der Korrektur.
Savings Plans, Reserved Instances und Rightsizing
Entscheiden Sie sich zwischen On-Demand, Savings Plans und Reserved Instances basierend auf der Vorhersagbarkeit der Compute-Nutzung und den Flexibilitätsanforderungen. Wesentliche Unterschiede:
- Savings Plans: Compute Savings Plans gelten für EC2, Fargate und Lambda und bieten Flexibilität bei Instanzgrößen/-regionen; EC2 Instance Savings Plans zielen auf Instanzfamilien in einer Region ab und bieten höhere Rabatte, aber weniger dienstübergreifende Abdeckung.
- Reserved Instances (RIs): Standard RIs bieten die größten Rabatte für festgelegte Instanztypen und können regional oder zonal sein; Convertible RIs ermöglichen den Wechsel der Instanzfamilie, erfordern aber eine Neukonfiguration.
- On-Demand: Keine Verpflichtung, höchste Kosten pro Stunde, am besten für unregelmäßige oder unbekannte Workloads.
Nutzen Sie die Rightsizing-Berichte von Compute Optimizer und Cost Explorer, um nicht ausgelastete Instanzen (CPU, Netzwerk, EBS-Durchsatz) und überprovisionierten Speicher zu identifizieren. Kombinieren Sie CloudWatch-Metriken (
undefined
) mit den Empfehlungen des Compute Optimizer, um eine Verkleinerung oder einen Wechsel der Instanzfamilie zu rechtfertigen. Bei stabiler Auslastung (z. B. Grundlast an vCPU-Stunden für die Produktion), berechnen Sie den Break-Even und die Abdeckung: Kaufen Sie Savings Plans oder RIs für die vorhersagbare Grundlast und behalten Sie einen Puffer an On-Demand-Kapazität für Nutzungsspitzen.
Budgets, Benachrichtigungen und Prognosen
Erstellen Sie in AWS Budgets Budgets für Kosten, Nutzung und die Abdeckung durch RIs/Savings Plans mit den Schwellenwerttypen „Tatsächlich“ (Actual) und „Prognostiziert“ (Forecasted). Verwenden Sie die Konsole oder die CLI (
undefined
) und fügen Sie Benachrichtigungen über SNS-Themen, E-Mail oder Lambda-Aktionen an. Für eine programmgesteuerte Problembehebung verknüpfen Sie SNS mit Lambda, um kurzlebige Ressourcen zu taggen oder zu stoppen oder um Tickets in ITSM-Systemen zu öffnen, wenn Prognosen die Schwellenwerte überschreiten.
Fügen Sie Cost Anomaly Detection hinzu, um plötzliche Ausgabenspitzen zu erkennen, und verknüpfen Sie Anomalien mit SNS/SQS für automatisierte Untersuchungs-Workflows. Die Prognosefunktion im Cost Explorer verwendet historische Ausgaben; kombinieren Sie sie mit Geschäftssignalen (Kampagnen zu Quartalsbeginn, offene Tickets), um realistische Budget-Benachrichtigungen festzulegen. Für operative Entscheidungen:
- Verwenden Sie prognostizierte Schwellenwerte, um wachsende Trends früher zu erkennen.
- Verwenden Sie tatsächliche Schwellenwerte, um eine Überschreitung gegen Monatsende zu verhindern.
- Verknüpfen Sie Benachrichtigungen mit automatisierten Leitplanken (Stoppen/Herunterskalieren) für nicht kritische Konten.
Datenübertragung und servicespezifische Kostentreiber
Netzwerk und Speicher sind häufige Kostentreiber mit hoher Varianz. Verstehen Sie diese Besonderheiten:
- Datenübertragung: Ausgehender Datenverkehr zwischen Regionen (Inter-Region Egress) wird pro GB abgerechnet; Datenverkehr zwischen AZs kann je nach Service kostenlos oder kostenpflichtig sein (einige Services berechnen Gebühren für Cross-AZ). Die Gebühren für NAT Gateway umfassen eine stündliche Gebühr plus verarbeitete GB – Rechnungen für NAT Gateway können bei Workloads mit hohem Durchsatz die Egress-Kosten dominieren.
- Load Balancer: Bei ALB/NLB fallen Gebühren pro Stunde und pro verarbeitetem GB an; weiterleitungsintensiver Datenverkehr erhöht die Kosten.
- S3/EBS: Die Speicherpreise von S3 hängen von der Klasse (Standard, Intelligent-Tiering, Glacier) und den Anfragen ab; Lifecycle-Richtlinien verschieben Objekte in kostengünstigere Stufen, um die Speicherausgaben zu reduzieren. EBS-Snapshot-Speicher wird pro GB-Monat und für regionsübergreifende Kopiervorgänge abgerechnet.
- Verwaltete Dienste: RDS I/O, Lese-/Schreibkapazität und On-Demand-Backups von DynamoDB sowie Speicher- und Snapshot-Kosten von ElasticSearch (OpenSearch Service).
Optimierungstaktiken:
- Verwenden Sie VPC-Endpunkte für S3, um den Internet-Egress zu reduzieren, und nutzen Sie S3 Transfer Acceleration oder CloudFront, um den Origin-Egress bei der Bereitstellung für globale Benutzer zu verringern.
- Konsolidieren Sie regionsübergreifenden Datenverkehr oder legen Sie Dienste in derselben Region zusammen, um Inter-Region-Egress zu vermeiden.
- Ersetzen Sie NAT Gateways durch VPC-Endpunkte, Gateway Load Balancer oder NAT-Instanzen, wenn dies angemessen ist und nachdem die Performance-Kompromisse getestet wurden.
Häufige Fallstricke und Entscheidungskriterien
- Ressourcen nicht getaggt und nicht zugeordnet lassen: Erzwingen Sie erforderliche Tags mit AWS Config und verwenden Sie die Resource Groups Tagging API, um nicht getaggte Ressourcen automatisch zu finden und zu korrigieren.
- Missverständnis des Geltungsbereichs von Savings Plans/RIs: Bestätigen Sie vor einer Zusage, ob Compute Savings Plans (serviceübergreifend) oder EC2 Instance Savings Plans / RIs (familien-/zonenbezogen) zu Ihren Workloads passen.
- Sich beim Rightsizing nur auf die CPU verlassen: Beziehen Sie Metriken für Arbeitsspeicher, Netzwerk und Festplatten-IOPS (CloudWatch und Compute Optimizer) mit ein, um Leistungsregressionen nach dem Downsizing zu vermeiden.
- Ignorieren von Datenübertragungskosten zwischen Regionen/Services: Bilden Sie Datenverkehrsflüsse ab, messen Sie den Egress über VPC Flow Logs/Athena und legen Sie starke Produzenten/Konsumenten am selben Standort zusammen oder verwenden Sie CloudFront/VPC-Endpunkte.
- Fehlkonfiguration von Budgets: Wählen Sie „Ist“ (Actual) vs. „Prognostiziert“ (Forecasted) angemessen aus und fügen Sie programmgesteuerte Aktionen (SNS → Lambda) an, um frühzeitig zu drosseln oder zu benachrichtigen.
- Verwaisten Speicher/Snapshots und ungenutzte ELBs zurücklassen: Planen Sie eine automatisierte Bereinigung für nicht angehängte EBS-Volumes, veraltete Snapshots und ungenutzte Load Balancer.
Praktisches Problem: Anwendungsfallszenario
ApexAnalytics verzeichnet nach einer Marketingkampagne einen Kostenanstieg von 40 % im Vergleich zum Vormonat; die Entwickler haben viele Entwicklungs-Stacks in verschiedenen Regionen hochgefahren und sich für den Internetzugang auf NAT Gateways verlassen. Das Finanzteam benötigt sofortige Transparenz und Abhilfemaßnahmen.
- Aktivieren Sie stündliche CUR mit Ressourcen-IDs und liefern Sie diese an einen dedizierten S3-Bucket für Kosten; erstellen Sie eine Athena-Tabelle, um die Top-Kostentreiber nach linkedAccountId, Region und usageType abzufragen.
- Aktivieren und erzwingen Sie Kostenzuordnungs-Tags (CostCenter, Project, Owner) über Tag Policies und erforderliche Tags in AWS Config, und tragen Sie fehlende Tags mit der Resource Groups Tagging API nach.
- Führen Sie Rightsizing- und Compute-Optimizer-Berichte im Cost Explorer aus, identifizieren Sie die stabile Grundlast-Rechenleistung und erwerben Sie einen passenden Savings Plan für die Grundlaststunden; planen Sie das Downsizing für nicht ausgelastete Instanzen.
- Prüfen Sie den Netzwerk-Egress mit VPC Flow Logs → Athena; ersetzen Sie NAT Gateways wo möglich durch VPC-Endpunkte und zentralisieren Sie regionale Test-Workloads, um regionsübergreifende Übertragungen zu vermeiden.
- Erstellen Sie AWS Budgets mit prognostizierten Schwellenwerten, binden Sie SNS an, um eine Lambda-Funktion auszulösen, die unkritische Entwicklerkonten unter Quarantäne stellt oder die Eigentümer benachrichtigt, und aktivieren Sie die Cost Anomaly Detection für plötzliche Spitzen.
Begründung: Die Bereitstellung von CUR und die Erzwingung von Tags ermöglichen eine präzise Kostenverrechnung und historische Analysen. Rightsizing und überlegte Verpflichtungen (Savings Plans) reduzieren die vorhersagbaren Ausgaben, während Netzwerkoptimierungen und automatisierte Budget-Aktionen zukünftige überraschende Egress-Kosten verhindern.
← Serverless und Anwendungsintegration · Alle Domänen
Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Bestehe deine Prüfung →