AWS Cloud Practitioner 10: Accounts, Billing und Support

Wer AWS beruflich nutzt, arbeitet selten mit nur einem Account. Mehrere Accounts brauchen eine gemeinsame Klammer, eine gemeinsame Rechnung und Regeln, die sich nicht in jedem Account einzeln aushebeln lassen. Darum geht es in Domain 4 des Exam Guide, „Billing, Pricing, and Support“, zusammen mit den Werkzeugen, mit denen wir Kosten schätzen, beobachten und begrenzen. Für die Prüfung ist dieser Teil besonders tückisch, weil AWS die Support-Pläne Ende 2025 neu geschnitten hat.

AWS Organizations als Klammer über viele Accounts

AWS Organizations fasst mehrere AWS-Accounts zu einer Organisation zusammen. An der Spitze steht der Management Account, der die Organisation anlegt und verwaltet. Alle übrigen sind Member Accounts. Sie lassen sich in Organizational Units (OUs) gruppieren, etwa nach Umgebung (Produktion, Test) oder nach Abteilung.

Der wichtigste wirtschaftliche Effekt heißt konsolidierte Abrechnung. Die Organisation bekommt eine einzige Rechnung, und die Kosten lassen sich trotzdem pro Account aufschlüsseln. Für Mengenrabatte zählt die Nutzung aller Accounts zusammen, etwa bei den Preisstaffeln von S3 oder beim Datentransfer (Consolidated Billing). Die Rabatte von Reserved Instances und Savings Plans können über die konsolidierte Abrechnung ebenfalls zwischen den Accounts geteilt werden. Der Management Account kann dieses Teilen für einzelne Accounts abschalten (AWS-Doku zum Abschalten des Rabatt-Sharings). Die Kaufoptionen selbst, also Reserved Instances und Savings Plans, haben wir in Teil 3 behandelt.

Organizations ist auch eine Sicherheitsfrage. Mit der zentralen Root-Verwaltung lassen sich die Root-Credentials von Member Accounts zentral entfernen und privilegierte Aufgaben vom Management Account aus erledigen. Was der Root User ist und warum er so heikel ist, steht in Teil 2, ebenso wie IAM Identity Center für die Anmeldung von Menschen.

Service Control Policies begrenzen, sie erlauben nichts

Eine Service Control Policy (SCP) legt fest, welche Aktionen in einem Account überhaupt möglich sind. Sie hängt an der Organisation, an einer OU oder an einem einzelnen Account. Eine SCP gewährt keine einzige Berechtigung, das ist der häufigste Denkfehler. Sie zieht eine Obergrenze ein, und innerhalb dieser Grenze muss weiterhin eine IAM-Policy die Aktion ausdrücklich erlauben. Fehlt das explizite Allow, bleibt die Aktion verboten, auch wenn die SCP sie zulässt.

SCPs gelten für alle User und Roles eines Member Accounts, auch für dessen Root User. Ausgenommen sind service-linked Roles, mit denen AWS-Dienste im Account eigene Aufgaben erledigen. Die zweite Ausnahme ist der Management Account selbst. SCPs wirken nur auf Member Accounts (AWS-Doku zu SCPs). Wer den Management Account mit SCPs absichern will, sichert gar nichts ab.

Control Tower, RAM und Service Catalog

Drei Dienste bauen auf Organizations auf und stehen alle in der In-Scope-Liste des Exam Guide.

AWS Control Tower richtet eine Landing Zone ein, also eine vorkonfigurierte Mehr-Account-Umgebung nach AWS-Empfehlungen. Dazu gehören Controls (früher Guardrails), vorgefertigte Regeln für ganze OUs. Sie wirken präventiv, detektiv oder proaktiv, präventive Controls unter anderem über SCPs (Controls in Control Tower). Control Tower ist die Antwort, wenn in einer Prüfungsfrage viele Accounts schnell und einheitlich aufgesetzt werden sollen.

AWS Resource Access Manager (RAM) teilt Ressourcen mit anderen Accounts, statt sie dort ein zweites Mal anzulegen. Typische Beispiele sind Subnets oder ein Transit Gateway aus Teil 6.

AWS Service Catalog ist ein Self-Service-Portal. Ein zentrales Team stellt freigegebene CloudFormation-Produkte bereit, und andere Teams starten nur diese geprüften Vorlagen. Das Stichwort in der Prüfung lautet meist „nur genehmigte Ressourcen“.

Vier Preismodelle

AWS beschreibt seine Preise mit vier Modellen (AWS Pricing, Stand Oktober 2026). Sie erklären, warum dieselbe Leistung je nach Art der Nutzung unterschiedlich viel kostet.

Pay-as-you-go ist der Tausch fixer gegen variable Kosten aus Teil 1. Welche Zusage sich bei „Save when you commit“ lohnt, empfiehlt der Cost Explorer (siehe Kostenwerkzeuge unten). Bei „Pay less by using more“ hilft eine Organisation, weil AWS die Nutzung aller Accounts für die Staffeln zusammenrechnet.

Free Plan, Always Free und Netzkosten

Für neue Accounts ab dem 15. Juli 2025 gilt der Free Plan. Er gibt 100 USD Credits bei der Anmeldung und bis zu 100 USD weitere Credits für Aktivitäten, zusammen also bis zu 200 USD. Der Free Plan endet nach sechs Monaten oder sobald die Credits aufgebraucht sind. Ohne Wechsel auf den Paid Plan wird der Account danach geschlossen.

AWS hält die Inhalte noch 90 Tage vor, in dieser Zeit ist der Wechsel weiter möglich. Wer wechselt, behält Restcredits, muss sie aber binnen zwölf Monaten nutzen. Tritt ein Account einer Organisation bei oder richtet eine Control-Tower-Landing-Zone ein, wechselt er automatisch in den Paid Plan (AWS Free Tier, Free-Tier-Pläne, re:Post Knowledge Center). Ältere Accounts behalten das frühere Zwölf-Monats-Modell.

Unabhängig davon gibt es Always Free-Kontingente, die nicht ablaufen. Zwei Beispiele (Stand Oktober 2026):

Netzkosten sind ein Prüfungsklassiker, weil sie leicht übersehen werden. Datenverkehr in AWS hinein ist kostenlos. Verkehr innerhalb derselben AZ über private IP-Adressen kostet ebenfalls nichts. Zwischen zwei AZs fallen 0,01 USD pro GB an, und zwar je Richtung, also beim Senden und beim Empfangen (AWS-Doku zu Data-Transfer-Kosten).

Ins Internet sind 100 GB pro Monat frei, aggregiert über alle Services und Regionen (EC2-Preisseite). Der Preis zwischen Regionen hängt vom Regionspaar ab und steht auf derselben Preisseite. Alle Preise sind eine Momentaufnahme (Stand Oktober 2026) und beziehen sich auf us-east-1.

Werkzeuge für Kosten, vorher und nachher

AWS bietet eine ganze Reihe von Kostenwerkzeugen, die sich in Prüfungsfragen gern ähneln. Der Unterschied liegt meist im Zeitpunkt. Manche schätzen vor dem Start, andere analysieren, was bereits angefallen ist, wieder andere warnen.

Bei Budgets kann jeder der bis zu fünf Alerts an bis zu zehn E-Mail-Empfänger und an ein SNS-Topic gehen. Ein Account darf bis zu 20.000 Budgets haben (Budgets FAQ).

Compute Optimizer deckt längst mehr ab als EC2, Auto Scaling Groups, EBS und Lambda. Dazu kommen unter anderem ECS on Fargate, RDS, Aurora, NAT Gateway, ElastiCache, DynamoDB und SageMaker Endpoints. Kostenpflichtig ist nur die Option Enhanced Infrastructure Metrics mit längerem Analysezeitraum (Compute Optimizer Pricing).

Die Prognose im Cost Explorer reicht bis zu 18 Monate in die Zukunft (Cost Explorer FAQ). Außerdem gibt der Cost Explorer Empfehlungen für Savings Plans und Reserved Instances (AWS Pricing, Reservierungsempfehlungen).

Cost Allocation Tags wirken nicht von selbst. Ein Tag taucht erst in Cost Explorer und im CUR als eigene Aufschlüsselung auf, wenn er als Cost Allocation Tag aktiviert wurde (Cost Allocation Tags aktivieren).

AWS Trusted Advisor prüft einen Account gegen Best Practices in sechs Kategorien, nämlich Cost Optimization, Performance, Security, Fault Tolerance, Service Limits und Operational Excellence (Trusted Advisor). Wie viele Checks wir sehen, hängt vom Support-Plan ab. Im Basic-Plan sind es sechs Security-Checks und die Service-Limit-Checks (Support FAQ).

Das neue Schema der Support-Pläne

AWS hat die Support-Pläne umgebaut. Seit dem 2. Dezember 2025 lassen sich Developer und der klassische Business-Plan nicht mehr neu buchen, beide enden am 1. Januar 2027. Enterprise On-Ramp wird bis zum 31. Dezember 2026 unterstützt. Der Exam Guide nennt in Task 4.3 nur noch das neue Schema mit Basic, Business Support+, Enterprise Support und Unified Operations.

Die übrigen Stufen sind in allen drei bezahlten Plänen gleich. Fälle zu einem ausgefallenen Produktivsystem beantwortet AWS binnen einer Stunde, zu einem beeinträchtigten Produktivsystem binnen vier Stunden, zu einem beeinträchtigten System binnen zwölf Stunden und zu einer allgemeinen Frage binnen 24 Stunden (Support-Pläne, Preise). Die Pläne unterscheiden sich also vor allem in der obersten Stufe und im Umfang der persönlichen Betreuung.

Der Exam Guide fragt in Task 4.3 auch nach Hilfe außerhalb der Pläne. Dazu gehören Customer Service, die Communities mit re:Post, das Knowledge Center und AWS Prescriptive Guidance. Für Unterstützung durch Dritte gibt es das AWS Partner Network mit Independent Software Vendors (ISVs) und System Integrators. Partner bekommen unter anderem Zugang zu Programmen und Finanzierung, zu Training und Zertifizierung sowie zu Partner-Events (AWS Partner Network). Fremde Software lässt sich über den AWS Marketplace kaufen, abrechnen und verwalten. AWS Professional Services und Solutions Architects sind AWS-eigene Beratung. Die AWS Health API liefert die Ereignisse des Health Dashboard aus Teil 7 maschinenlesbar.

Support-Fälle eröffnen wir im AWS Support Center in der Konsole. Auch mit dem Basic-Plan lassen sich dort Fälle zu Account und Abrechnung sowie Anträge auf höhere Service Quotas anlegen, technische Fälle setzen einen bezahlten Plan voraus (Support-Pläne in der Doku).

Den Support-Plan muss nicht mehr der Root User wechseln. Die Aufgabe steht nicht mehr auf der Liste der Root-only-Aufgaben.

Hands-on

Legen wir ein Budget an, prüfen es und löschen es wieder. AWS Budgets und der Cost Explorer sind globale Dienste mit einem API-Endpunkt in us-east-1. Deshalb steht in diesem Teil ausnahmsweise --region us-east-1 statt eu-central-1. Die eigene Account-ID lesen wir mit aws sts get-caller-identity aus.

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

aws budgets create-budget \
  --account-id "$ACCOUNT_ID" \
  --budget '{"BudgetName":"ccp-demo-monatsbudget","BudgetLimit":{"Amount":"5","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \
  --region us-east-1

aws budgets describe-budget \
  --account-id "$ACCOUNT_ID" \
  --budget-name ccp-demo-monatsbudget \
  --region us-east-1

Gekürzte Ausgabe von describe-budget:

{
  "Budget": {
    "BudgetName": "ccp-demo-monatsbudget",
    "BudgetLimit": { "Amount": "5.0", "Unit": "USD" },
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }
}

In der Konsole: Billing and Cost Management → Budgets and Planning → Budgets → Create budget. Dort wählen wir unter „Budget setup“ zwischen „Use a template (simplified)“ und „Customize (advanced)“. Die Konsole verlangt anders als die CLI schon beim Anlegen mindestens einen E-Mail-Empfänger.

Der Screenshot zeigt die Vorlagenauswahl, abgeschickt haben wir das Formular nicht.

In unserem Lauf hatte das Budget keine Benachrichtigung, es ging nur um Anlegen und Löschen. Im echten Einsatz hängen wir einen E-Mail-Alert direkt beim Anlegen an, etwa bei 80 Prozent der tatsächlichen Kosten:

aws budgets create-budget \
  --account-id "$ACCOUNT_ID" \
  --budget file://budget.json \
  --notifications-with-subscribers '[{"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80,"ThresholdType":"PERCENTAGE"},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"kosten@example.com"}]}]' \
  --region us-east-1

Danach fragen wir den Cost Explorer nach den Kosten des laufenden Monats, gruppiert nach Service. Jede Abfrage der Cost-Explorer-API kostet 0,01 USD. Das Enddatum in --time-period ist exklusiv, der 25. Oktober zählt also nicht mehr mit.

aws ce get-cost-and-usage \
  --time-period Start=2026-10-01,End=2026-10-25 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE \
  --region us-east-1

In der Konsole: Billing and Cost Management → Cost and Usage Analysis → Cost Explorer. Das Free Tier steht unter Billing and Cost Management → Free Tier, die Cost Allocation Tags unter Billing and Cost Management → Cost Organization → Cost Allocation Tags.

Die Abfrage funktionierte. Die Beträge aus dem Demo-Account veröffentlichen wir nicht, die Struktur der Antwort sieht gekürzt so aus:

{
  "ResultsByTime": [
    {
      "TimePeriod": { "Start": "2026-10-01", "End": "2026-10-25" },
      "Groups": [
        {
          "Keys": ["<Servicename>"],
          "Metrics": { "UnblendedCost": { "Amount": "<Betrag>", "Unit": "USD" } }
        }
      ]
    }
  ]
}

Zum Schluss räumen wir auf:

aws budgets delete-budget \
  --account-id "$ACCOUNT_ID" \
  --budget-name ccp-demo-monatsbudget \
  --region us-east-1

Ein Budget selbst ist schnell gelöscht. Ressourcen, die aus dieser Serie stehen bleiben, verbrauchen im Free Plan Credits und erzeugen im Paid Plan Kosten.

Für die Prüfung

Typische Fallen:

• SCPs erlauben nichts. Ohne explizites Allow in einer IAM-Policy bleibt eine Aktion verboten.
• Der Management Account ist von SCPs ausgenommen. Gleiches gilt für service-linked Roles.
• Cost Explorer prognostiziert 18 Monate, nicht zwölf.
• Developer, Business und Enterprise On-Ramp sind Auslaufmodelle. Antworten mit diesen Plänen passen nicht zum aktuellen Exam Guide.
• Billing Alarm liegt in CloudWatch in us-east-1 und kennt nur Ist-Kosten.
• RI- und Savings-Plans-Rabatte werden in einer Organisation geteilt, der Management Account kann das Teilen aber für einzelne Accounts abschalten.
• Cost Allocation Tags erscheinen erst nach der Aktivierung in Cost Explorer und CUR. Ein gesetzter Tag allein genügt nicht.

Quellen

• Exam Guide CLF-C02, insbesondere Domain 4
• In-Scope-Services CLF-C02
• Service Control Policies
• Controls in Control Tower
• Root User und zentrale Root-Verwaltung
• Abschalten des RI- und Savings-Plans-Sharings
• AWS Pricing (Preismodelle)
• Aktivieren von Cost Allocation Tags
• Consolidated Billing
• Reservierungsempfehlungen im Cost Explorer
• AWS Partner Network
• AWS Free Tier und Beginn und Ende des Free Tier
• Lambda Free Tier, DynamoDB
• Data-Transfer-Kosten im CUR, EC2 On-Demand-Preise
• Cost Explorer FAQ, Budgets FAQ
• Compute Optimizer Pricing
• Trusted Advisor
• Support-Pläne, Support-Preise, Support FAQ, Support-Pläne in der Doku

Im letzten Teil setzen wir alles zusammen, mit dem Well-Architected Framework, Disaster-Recovery-Strategien, Migration und den häufigsten Prüfungsfallen.