AWS Cost Allocation Tags Guide 2026

Aktualisiert: 20. Juni 2026

AWS Cost Allocation Tags sind Schlüssel-Wert-Paare, die du an AWS-Ressourcen anhängst, damit der Cost & Usage Report (CUR) deine Kosten nach Team, Projekt, Umgebung oder Kostenstelle aufschlüsseln kann. In Multi-Account-Setups wird die Tagging-Strategie schnell zur wichtigsten FinOps-Disziplin überhaupt: ohne sie liefert der Cost Explorer keine belastbare Showback-Sicht, und Chargeback bleibt eine Excel-Bastelei. Dieser Leitfaden zeigt dir die Strategie, die ich 2026 in Organisationen mit 80+ AWS-Konten produktiv einsetze (inklusive Tag Policies, Cost Categories und CUR 2.0).

AWS unterstützt bis zu 500 aktive user-defined Cost Allocation Tags pro Zahlungskonto. Klingt viel, ist aber bei wildwüchsigem Tagging schnell aufgebraucht.
Tag Policies in AWS Organizations erzwingen Groß-/Kleinschreibung und erlaubte Werte. Sie verhindern aber nicht das Erstellen ungetaggter Ressourcen; dafür brauchst du Service Control Policies oder AWS Config Rules.
Cost Categories ergänzen Tags und sind die einzige Möglichkeit, untaggable Services (z. B. Datentransfer, IAM, Route 53) sauber Kostenstellen zuzuordnen.
Aktivierte Cost Allocation Tags wirken erst ab dem Aktivierungszeitpunkt, historische Daten werden NICHT rückwirkend angereichert.
CUR 2.0 mit Athena-Anbindung und stündlicher Granularität ist 2026 der De-facto-Standard für jede Allocation jenseits von 10 Konten.
Eine 8-Tag-Mindeststrategie (Environment, CostCenter, Application, Owner, ManagedBy, DataClass, Compliance, ExpiryDate) deckt 90 % der Reporting-Anforderungen ab.

Was sind AWS Cost Allocation Tags?

AWS Cost Allocation Tags sind eine Untermenge der normalen Resource Tags, die du in der Billing-Konsole des Zahlungskontos aktiv geschaltet hast, damit sie als zusätzliche Spalten in deinem Cost & Usage Report und als Filter- oder Group-by-Dimension im Cost Explorer erscheinen. Es gibt zwei Klassen: AWS-generated Tags (z. B. aws:createdBy, aws:cloudformation:stack-name) und User-defined Tags, die deine eigene Strategie abbilden. Ein Tag, das auf einer EC2-Instanz lebt, taucht erst dann als kostentragende Dimension in Reports auf, wenn du es im Billing-Dashboard explizit aktivierst. Das ist der häufigste Stolperstein, weil Teams oft tagen und sich dann wundern, warum nichts im Cost Explorer auftaucht.

In meiner Praxis sehe ich vier Verwendungsarten: Allocation (welche Kostenstelle zahlt?), Operations (wer ist Owner, wann läuft das aus?), Security (DataClass, Compliance) und Automation (ManagedBy, BackupSchedule). Diese Klassen müssen in der Tag-Strategie sauber getrennt sein, sonst entstehen Sammeltags wie Project=null, die hinterher 30 % deiner Kosten als "Unallocated" auflaufen lassen. Und ja, Tags sind case-sensitive. environment=prod und Environment=prod sind zwei verschiedene Tags. Ein Klassiker, der ohne Tag Policies eskaliert.

Tagging-Strategie für Multi-Account-Organisationen

Eine belastbare Multi-Account-Strategie startet mit einem schmalen Mindestset an Pflicht-Tags, das du in jedem Account erzwingst, und einer Erweiterungsschicht, die team-spezifisch bleiben darf. Ich arbeite mit acht Pflicht-Tags und maximal sechs optionalen pro Workload. Die Pflichttags müssen in einer zentralen Datei (z. B. tags.yaml im Platform-Repository) versioniert sein, damit Terraform-Module, CloudFormation-Stacks und CDK-Projekte sie aus derselben Quelle ziehen. Vermeide es, Tag-Listen in PowerPoint-Folien zu pflegen, die divergieren innerhalb eines Quartals.

Tag-Key	Pflicht/Optional	Erlaubte Werte	Zweck
Environment	Pflicht	prod, staging, dev, sandbox	Umgebungs-Showback
CostCenter	Pflicht	4-stellige Ziffer (SAP-Kreis)	Chargeback
Application	Pflicht	freier String, kebab-case	App-level Reporting
Owner	Pflicht	E-Mail-Adresse	Eskalation, Aufräumen
ManagedBy	Pflicht	terraform, cdk, console, ansible	Drift-Erkennung
DataClass	Pflicht	public, internal, confidential, restricted	Compliance-Audits
Compliance	Optional	pci, hipaa, gdpr, none	Regulatorische Reports
ExpiryDate	Optional	YYYY-MM-DD	Sandbox-Cleanup

Für Multi-Account-Setups empfehle ich, die Tag-Strategie über AWS Organizations zu verteilen und nicht pro Account einzuführen. Mehr zur Beziehung zwischen Account-Struktur und Rabattierung findest du in meinem Vergleich Savings Plans vs. Reserved Instances 2026. Die Wahl des richtigen Rabattmodells hängt direkt davon ab, wie sauber du Workloads pro Account isolieren kannst.

Wie aktiviere ich Cost Allocation Tags in AWS?

Cost Allocation Tags werden ausschließlich im Management Account (Payer Account) der AWS Organization aktiviert, nicht in den Member Accounts. Navigiere zu Billing and Cost Management → Cost Allocation Tags → User-defined cost allocation tags, wähle die gewünschten Tag-Keys aus und klicke Activate. Die Aktivierung wirkt erst ab dem nächsten CUR-Lauf (ca. 24 Stunden Verzögerung) und ist nicht rückwirkend. Das ist der wichtigste operative Fakt, den FinOps-Teams oft übersehen.

Per CLI lässt sich der gleiche Vorgang automatisieren, was in größeren Setups Pflicht ist:

aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status \
  '[{"TagKey":"Environment","Status":"Active"},
    {"TagKey":"CostCenter","Status":"Active"},
    {"TagKey":"Application","Status":"Active"},
    {"TagKey":"Owner","Status":"Active"},
    {"TagKey":"ManagedBy","Status":"Active"},
    {"TagKey":"DataClass","Status":"Active"}]'

Den aktuellen Status aller Tags prüfst du mit:

aws ce list-cost-allocation-tags \
  --status Active \
  --query 'CostAllocationTags[].[TagKey,Type,Status]' \
  --output table

Ich verpacke beide Aufrufe in einen Terraform null_resource mit local-exec, damit die Aktivierung Teil des Platform-Repos ist und nicht als manueller Klick irgendwo verloren geht. Die offizielle Referenz dazu liefert die AWS Billing-Dokumentation zu Cost Allocation Tags.

Tag Policies und Compliance erzwingen

Tag Policies in AWS Organizations sind das Werkzeug, um Schreibweise und erlaubte Werte zentral zu erzwingen. Sie verhindern, dass jemand in einem Member Account environment=Prod statt Environment=prod schreibt. Wichtig: Tag Policies blockieren standardmäßig keine Tag-Erstellung, sie markieren nur Non-Compliance. Erst mit aktivierter enforcement-Option lehnt die API non-konforme Tag-Operationen ab, und das auch nur für unterstützte Resource-Typen (eine vollständige Liste pflegt AWS in den Organizations-Docs).

{
  "tags": {
    "Environment": {
      "tag_key": { "@@assign": "Environment" },
      "tag_value": {
        "@@assign": ["prod", "staging", "dev", "sandbox"]
      },
      "enforced_for": {
        "@@assign": ["ec2:instance", "rds:db", "s3:bucket"]
      }
    },
    "CostCenter": {
      "tag_key": { "@@assign": "CostCenter" },
      "tag_value": {
        "@@assign": ["@@none"]
      }
    }
  }
}

Für die "muss vorhanden sein"-Anforderung brauchst du zusätzlich AWS Config Rules wie required-tags, die non-konforme Ressourcen melden, oder eine Service Control Policy, die RunInstances ohne Pflicht-Tags ablehnt. Die SCP-Variante ist härter, aber operationell teurer, weil sie auch Bootstrap-Operationen blockiert. Details zur Syntax findest du in der AWS Organizations Tag-Policy-Referenz.

Was ist der Unterschied zwischen Cost Categories und Cost Allocation Tags?

Cost Categories sind im Management Account definierte Regelsätze, die Kosten anhand von Account-ID, Service, Region oder bestehenden Tags in benannte Buckets aggregieren, ohne dass eine Ressource tatsächlich getaggt sein muss. Cost Allocation Tags sind hingegen direkt an Ressourcen geheftete Metadaten. Beide ergänzen sich: Tags sind die Datenquelle, Categories die Aggregationsschicht. Für untaggable Services wie AWS Data Transfer, AWS Support, Route 53 Hosted Zones oder konsolidierte IAM-Kosten sind Cost Categories die einzige Möglichkeit, sie einer Kostenstelle zuzuordnen.

Ein typisches Beispiel: Du hast 12 Member Accounts pro Geschäftsbereich. Statt jeden Account einzeln im Cost Explorer zu filtern, definierst du eine Cost Category BusinessUnit mit Werten retail, logistics, finance, die per Account-ID-Regel zuordnet. Die Aufschlüsselung wird dann in CUR 2.0 als zusätzliche Spalte ausgespielt und du kannst sie in QuickSight wie jede andere Tag-Dimension verwenden. Die offizielle AWS-Doku zu Cost Categories beschreibt die Regelsyntax im Detail.

Eine Cost Category darf bis zu zehn Regeln und Verschachtelungen referenzieren. Nutze das, um eine Hierarchie wie Division → BusinessUnit → Product ohne riesige Spreadsheets abzubilden. Cost Categories aktualisieren sich rückwirkend für offene Abrechnungsperioden, was ein riesiger operativer Vorteil gegenüber Tags ist: wenn du dich beim Mapping vertan hast, korrigierst du die Regel, und der Monat wird neu aggregiert. Ich nutze Categories deshalb für alle "weichen" Allocation-Dimensionen (BusinessUnit, Region-Cluster, Compliance-Scope) und Tags strikt für ressourcennahe Dimensionen, die der Workload selbst kennt (Application, Owner, Environment).

CUR 2.0, Athena und QuickSight für Showback

Ab etwa 10 Accounts wird der Cost Explorer als alleiniges Reporting-Werkzeug zu eng. Spätestens dann brauchst du den Cost & Usage Report 2.0. CUR 2.0 liefert dir stündliche Granularität, normalisierte Spaltennamen und eine Parquet-Variante, die direkt in S3 landet. Aktiviere CUR 2.0 mit Athena-Integration und Resource-ID-Detailspalten, sonst sind Drill-downs auf einzelne EC2-Instanzen nicht möglich.

-- Showback-Query: Kosten pro CostCenter und Environment für den letzten Monat
SELECT
  resource_tags['user_CostCenter']    AS cost_center,
  resource_tags['user_Environment']   AS environment,
  product['product_name']             AS service,
  ROUND(SUM(line_item_unblended_cost), 2) AS cost_usd
FROM customer_cur_data.cur_2_0
WHERE bill_billing_period_start_date = DATE '2026-05-01'
  AND line_item_line_item_type = 'Usage'
GROUP BY 1, 2, 3
HAVING SUM(line_item_unblended_cost) > 10
ORDER BY cost_usd DESC;

Ungetaggte Kosten erkennst du sofort an NULL in der CostCenter-Spalte. Diese "Unallocated"-Quote ist deine wichtigste FinOps-KPI, ich ziele auf unter 5 % monatlich. Liegt sie höher, muss zuerst die Tagging-Disziplin steigen, bevor Showback überhaupt belastbar wird. Ähnliche Allocation-Themen behandelt mein Artikel Kubernetes-Kosten mit Karpenter und Kubecost, denn auf Cluster-Ebene gilt dieselbe Logik: ohne Namespace- oder Label-Strategie keine sinnvolle Aufteilung. Weitere Hintergründe zum Thema sammelt die FinOps Foundation in ihrem Allocation-Capability-Modell.

Typische Fallstricke in Multi-Account-Setups

Die fünf Fehler, die ich in nahezu jedem Multi-Account-Audit wiederfinde:

Tag-Strategie ohne Eigentümer. Wenn niemand das Tagging-Dokument pflegt, divergieren Schreibweisen innerhalb eines Quartals. Ernenne eine Person im Cloud-Platform-Team explizit als "Tag Owner".
Tags aktiviert, aber nicht rückwirkend. Teams aktivieren ein Tag und wundern sich, warum Q1-Daten leer sind. Aktivierung wirkt nur prospektiv, kommuniziere das aktiv im Onboarding.
Kein Tagging auf Auto-Scaling-Group-Launch-Templates. EC2-Instanzen, die von ASGs erzeugt werden, erben nur die Tags, die im Launch Template mit PropagateAtLaunch=true markiert sind. Klassischer blinder Fleck.
Lambda-Layer und Container-Images bleiben untaggable. Plane Cost Categories dafür ein.
Reservation- und Savings-Plan-Rabatte werden falsch aufgeteilt. Standardmäßig erbt das Konto, das die Reservation hält, den vollen Rabatt, nicht das konsumierende Konto. Aktiviere Reservation Sharing in der Organization und nutze die amortized cost-Spalte im CUR für faire Showbacks.

Bonusfalle: Cross-Account-Snapshots und KMS-Keys. Snapshots wandern bei DR-Setups oft in einen zentralen Backup-Account, der die Kosten dann komplett trägt, obwohl die Daten einem Workload-Account gehören. Lege dafür eine Cost Category mit Filterregel auf den Snapshot-Source-Account an, sonst sieht dein Backup-Team aus, als würde es 40 % deines Cloud-Budgets verbrennen. Genau diesen Fall hatte ich Anfang 2026 bei einem Kunden auf dem Tisch (Ergebnis: über 18.000 USD pro Monat im falschen Konto). Ähnliches gilt für zentral verwaltete KMS-Keys: die Per-Request-Kosten landen im Key-Owner-Account und nicht beim Verbraucher.

Häufig gestellte Fragen

Wie viele Cost Allocation Tags sind in AWS erlaubt?

Pro Ressource sind maximal 50 Tags möglich (allgemeine AWS-Grenze). Aktivierbar als Cost Allocation Tags sind seit 2025 bis zu 500 pro Zahlungskonto, vorher waren es 50. Praktisch sollten es nicht mehr als 20 bis 30 sein, um Reports übersichtlich zu halten.

Werden Cost Allocation Tags rückwirkend angewendet?

Nein. Cost Allocation Tags wirken ausschließlich ab dem Zeitpunkt ihrer Aktivierung im Billing Dashboard. Historische CUR-Daten werden nicht nachträglich um die neuen Tag-Spalten ergänzt, plane die Aktivierung daher zu Monatsbeginn.

Welche AWS-Services unterstützen kein Tagging?

Klassische Beispiele sind AWS Support, ein Großteil von AWS Data Transfer, Route 53 Hosted-Zone-Queries und einige IAM-Operationen. Für diese Kosten brauchst du Cost Categories oder regelbasierte Aufteilungen im CUR.

Sollte ich Service Control Policies oder Tag Policies zum Erzwingen nutzen?

Tag Policies erzwingen die Schreibweise und erlaubte Werte, SCPs können das Erstellen ungetaggter Ressourcen komplett verhindern. In der Praxis kombinierst du beides: Tag Policies für Konsistenz, SCPs für die "muss vorhanden sein"-Anforderung, aber nur in Production-OUs, nicht in Sandboxes.

Was kostet der Cost & Usage Report (CUR)?

Der CUR selbst ist kostenlos, aber die S3-Speicherung der Parquet-Files und die Athena-Queries verursachen Gebühren. Bei einem mittelgroßen Setup (50 Accounts, 30 aktive Tags) liegen die kombinierten Kosten typischerweise bei 30 bis 80 US-Dollar pro Monat.