Eine Kostenrichtlinie ist das schriftliche Regelwerk, das festlegt, was Teams in der Cloud ohne Rückfrage nutzen und ausgeben dürfen: in welchen Regionen, mit welchen Diensten und Größen, mit welchen Pflicht-Tags, ab welchem Betrag nur mit Freigabe, wer Commitments kauft, wer Kostendaten sieht und wie eine Ausnahme aussieht. Sie ist die Vorlage, aus der Guardrails, Budgets und Reviews abgeleitet werden. Fehlt sie, setzt jede Plattformeinstellung eine Regel durch, die niemand beschlossen hat, und jede fehlende Einstellung erlaubt etwas, das niemand erlauben wollte. Für die Rechnung entscheidet die Richtlinie, welche Kosten gar nicht entstehen können, welche erst nach einer Unterschrift entstehen und welche nur gemeldet werden.
So funktioniert es
Die FinOps Foundation behandelt das Thema in der Capability Governance, Policy & Risk, die zur Domain Manage the FinOps Practice gehört, und unterscheidet drei Formen der Umsetzung: Guidelines, Guardrails und Automatisierung. Wie die Capabilities zusammenhängen, beschreibt Die vier Domains und ihre Capabilities. Wirksam wird eine Richtlinie erst, wenn jeder ihrer Bereiche einen Mechanismus hat, der ihn durchsetzt oder einen Verstoß meldet.
Bereiche und Mechanismen
| Bereich | Was die Richtlinie festlegt | AWS | Azure | Google Cloud |
|---|---|---|---|---|
| Regionen | erlaubte Regionen je Umgebung | SCP mit Bedingung auf aws:RequestedRegion | eingebaute Policy für erlaubte Standorte, Effekt deny | Einschränkung gcp.resourceLocations, etwa mit in:eu-locations |
| Dienste und Größen | erlaubte Dienste, Instanzfamilien und SKUs | SCP, die Dienste verweigert | eingebaute Policies für erlaubte Ressourcentypen und VM-SKUs | gcp.restrictServiceUsage; Custom Constraint auf resource.machineType |
| Pflicht-Tags | Schlüssel und Werte der Tagging-Richtlinie | Tag Policies, SCP mit aws:RequestTag, Config-Regel required-tags | Azure Policy mit deny, modify oder audit | Custom Constraint auf resource.labels |
| Commitments | wer kaufen darf | Aktion savingsplans:CreateSavingsPlan nur für benannte Rollen | Owner oder Reservation Purchaser; Richtlinie „Reserved Instances“ unter EA und MCA | compute.commitments.create, enthalten in Compute Admin; ausgabenbasiert nur Billing Account Administrator |
| Kostendaten | wer welche Kosten sieht | Billing-Konsole erst nach Activate IAM Access, dann IAM-Aktionen | Cost-Management-Rollen je Scope | Cloud-Billing-Rollen |
| Ausnahmen | Antragsteller, Grund, Enddatum | eigene Organisationseinheit mit anderer SCP | Policy Exemption mit expiresOn | abweichende Richtlinie auf Ordner oder Projekt |
Freigabeschwellen fehlen in der Tabelle, weil kein Mechanismus eine Unterschrift ersetzt; wie sie am Budget bemessen werden, beschreibt Guardrails und Freigabeschwellen. Wie die Tag-Regeln als Code gepflegt werden, steht in Policy as Code: Tagging-Regeln durchsetzen, die Rollen für Kostendaten in Zugriff auf Kostendaten: Rollen der Provider.
Präventiv, detektiv, proaktiv
AWS Control Tower ordnet jede Kontrolle einem von drei Verhalten zu. Eine präventive Kontrolle verhindert die Aktion und ist mit Service Control Policies und verwandten Organisationsrichtlinien umgesetzt. Eine detektive Kontrolle meldet einen Verstoß nachträglich und beruht auf AWS-Config-Regeln. Eine proaktive Kontrolle prüft eine Ressource vor dem Anlegen, über CloudFormation Hooks und deshalb nur für Ressourcen, die CloudFormation anlegt. Azure Policy kennt dieselbe Unterscheidung als Effekt: deny lehnt eine Anfrage ab, audit protokolliert sie, und bestehende Ressourcen bewertet ein regulärer Prüfzyklus alle 24 Stunden. Google Cloud bietet für Organisationsrichtlinien einen Dry-Run-Modus, der Verstöße protokolliert, ohne sie zu blockieren.
Präventive Regeln haben zwei Grenzen. Sie wirken nicht rückwirkend: Google schreibt, dass neue Organisationsrichtlinien in der Regel nicht rückwirkend gelten, und der modify-Effekt von Azure Policy ändert vorhandene Ressourcen nicht, sondern markiert sie als nicht konform, bis ein Remediation-Task sie korrigiert. Was vor der Regel existierte, findet nur eine detektive Prüfung. Außerdem gelten SCPs nicht für Benutzer und Rollen im Management-Konto einer AWS-Organisation, und auch Control Tower nimmt dessen Administratoren von den Kontrollen aus, damit das Konto bedienbar bleibt. Workloads, die der Richtlinie folgen sollen, gehören deshalb in Mitgliedskonten.
Ausnahmen und Überprüfung
Eine Richtlinie ohne Weg für begründete Abweichungen wird umgangen. Azure Policy bildet diesen Weg als Exemption ab: in der Kategorie Waiver, wenn ein Verstoß vorübergehend hingenommen wird, oder Mitigated, wenn das Ziel auf anderem Weg erreicht ist, mit optionalem Ablaufdatum expiresOn und frei wählbaren Metadaten wie Antragsteller, Freigebendem und Ticketnummer. Nach dem Ablaufdatum gilt die Ausnahme nicht mehr, das Objekt bleibt aber als Nachweis bestehen, und Microsoft empfiehlt, Ausnahmen regelmäßig durchzusehen. Das Muster taugt für jeden Provider: Eine Ausnahme nennt Ressource, Grund, Verantwortlichen und Enddatum und liegt dort, wo die Richtlinie liegt.
Wie oft die Richtlinie selbst überprüft wird, legt die Organisation fest. Das Framework der FinOps Foundation verbindet einen festen Überprüfungsrhythmus mit der Reifestufe Walk und erwartet in der Stufe Run Regeln, die vor Merge oder Deployment automatisch geprüft werden. Anlässe für eine Prüfung außer der Reihe ergeben sich aus dem Betrieb: eine neue Region, ein neuer Provider, ein deutlich verändertes Budget, eine Ausnahme, die zum dritten Mal verlängert werden soll.
Was es für Ihre Kosten bedeutet
Jeder Bereich der Richtlinie wirkt anders auf die Rechnung. Regionen, Dienste und Größen begrenzen, welche Posten überhaupt entstehen können. Pflicht-Tags entscheiden, welcher Anteil der Kosten einem Verantwortlichen zugeordnet werden kann; gemessen wird das als Zuordnungsgrad, wie Tag-Abdeckung und nicht getaggte Kosten beschreibt. Der Zugriff auf Kostendaten entscheidet, wer eine Abweichung überhaupt bemerkt.
Die Kaufregel für Commitments ist der Bereich, in dem ein Fehler am längsten auf der Rechnung steht. Google schreibt für ressourcenbasierte wie für ausgabenbasierte Committed Use Discounts, dass ein gekauftes Commitment nicht gekündigt werden kann, und AWS schreibt, dass ein Kauf von EC2 Reserved Instances nach Abschluss nicht storniert werden kann. Der Kreis der Käufer ist dabei oft größer als gedacht: Bei Azure darf jeder Owner oder Reservation Purchaser einer berechtigten Subscription Reservierungen kaufen, unter EA und MCA lässt sich das über die Richtlinie „Reserved Instances“ einschränken; bei Google genügt für ressourcenbasierte Commitments die Rolle Compute Admin im Projekt. Welche Wege Tausch und Rückgabe danach noch bieten, beschreibt Tausch, Kündigung und Ablauf von Commitments.
Ausnahmen ohne Enddatum werden zu Dauerkosten. Eine Region, die für einen Kunden freigegeben wurde, bleibt freigegeben, wenn der Kunde längst gekündigt hat; mit Enddatum kommt sie im nächsten Review wieder auf den Tisch, mit Namen und Grund.
Wo es schiefgeht
- Richtlinie nur im Dokument. Symptom: Die Richtlinie verbietet eine Region, die Abrechnungsdaten zeigen trotzdem Kosten dort. Ursache: Für den Bereich wurde weder ein präventiver noch ein detektiver Mechanismus eingerichtet.
- Management-Konto vergessen. Symptom: Ausgerechnet im zentralen AWS-Konto laufen Ressourcen außerhalb der erlaubten Regionen. Ursache: SCPs wirken nur in Mitgliedskonten.
- Neue Regel, alter Bestand. Symptom: Nach Einführung einer Regionssperre sinken die Kosten in der gesperrten Region nicht. Ursache: Präventive Regeln greifen bei neuen Anfragen; vorhandene Ressourcen findet nur eine detektive Prüfung.
- Abgelaufene Ausnahme. Symptom: Eine Ressource erscheint plötzlich wieder als nicht konform, obwohl sich an ihr nichts geändert hat. Ursache: Das Ablaufdatum der Azure-Exemption ist erreicht; das Objekt ist noch da, gilt aber nicht mehr.
- Kaufrecht über die Projektrolle. Symptom: Ein Commitment erscheint, das niemand freigegeben hat. Ursache: Owner einer Azure-Subscription oder Compute Admin eines Google-Projekts dürfen kaufen, und die Richtlinie hat diese Rollen nicht eingeschränkt.
- Starre Allowlist. Symptom: Teams beantragen für jede neue Instanzfamilie eine Ausnahme. Ursache: Eine Liste erlaubter Größen enthält nur, was beim Schreiben existierte, und niemand überprüft sie.
Quellen
Gelesen am 2026-10-16. FinOps Foundation Governance, Policy & Risk (CC BY 4.0); AWS Verhalten von Kontrollen in Control Tower, Kontrollen und die Ausnahme des Management-Kontos, Service Control Policies, globale Bedingungsschlüssel, Tag Policies, Config-Regel required-tags, Zugriffsverwaltung für Savings Plans, EC2 Reserved Instances kaufen und Zugriff auf die Billing-Konsole; Microsoft Übersicht über Azure Policy, Modify-Effekt, Struktur von Policy-Ausnahmen, Azure-Reservierung kaufen und Zugriff auf Cost-Management-Daten zuweisen; Google Cloud Organization Policy Service, Ressourcenstandorte einschränken, Dienstnutzung einschränken, Custom Constraints für Compute Engine, ressourcenbasierte Commitments kaufen, ausgabenbasierte Committed Use Discounts und Zugriffssteuerung für Cloud Billing.