Cloud-Preise, Kostenmanagement und Governance

Eine Cloud-Rechnung beruht auf Abrechnungseinheiten. Rechenleistung kann pro Sekunde oder Stunde, Speicher pro GB-Monat und Anfragen pro 1.000 oder Million Operationen berechnet werden. Bei Serverless-Funktionen wird üblicherweise eine Aufrufgebühr mit der Ausführungszeit multipliziert mit dem zugewiesenen Arbeitsspeicher kombiniert. Mehr zugewiesener Arbeitsspeicher verändert die Gebühr für Speicherzeit.

Menge und Satz aufeinander abstimmen

Für eine VM zu einem Beispielsatz von 0,10 € pro Stunde kostet ein Monat mit 730 Stunden 73 €. Läuft sie an 22 Arbeitstagen jeweils 10 Stunden, nutzt sie 220 Stunden und kostet 22 €. Ihr 100-GB-Datenträger zu 0,08 € pro GB-Monat kostet in beiden Fällen zusätzlich 8 €, wenn er den ganzen Monat bereitgestellt bleibt. Die planmäßig genutzte Rechenleistung und der beibehaltene Speicher kosten zusammen 30 €.

Die Konvention von 730 Stunden verteilt 8.760 Jahresstunden gleichmäßig auf 12 Monate; Kalendermonate sind unterschiedlich lang. Viele VMs werden sekundengenau mit einer Mindestdauer von einer Minute abgerechnet, andere Produkte pro Minute oder Stunde.

Ungenutzte Kapazität kann Geld kosten

Bereitgestellte Kapazität ist Kapazität, die für deine Ressource reserviert ist. Für eine laufende VM oder bereitgestellte Datenbank fallen Gebühren nach Größe und Zeit an, auch wenn sie wenig arbeitet. Objektanfragen und Funktionsaufrufe richten sich unmittelbarer nach der Nutzung. Ein bereitgestellter Datenträger wird nach seiner zugewiesenen Größe berechnet, nicht nur nach den darauf geschriebenen Dateien.

Beim Stoppen einer AWS-EC2-Instanz enden ihre Rechengebühren. Bei Azure muss die VM gestoppt und ihre Zuordnung aufgehoben werden, damit die Abrechnung der Rechenleistung endet. Wird ihr Betriebssystem heruntergefahren, bleibt sie zugeordnet und wird weiter abgerechnet. Datenträger und Snapshots bleiben separate kostenpflichtige Ressourcen; beibehaltene öffentliche IP-Adressen können ebenfalls Gebühren verursachen.

Gleiche Konfigurationen vergleichen

Bei einem Preisvergleich müssen vCPUs, Arbeitsspeicher, Region, Betriebssystem und Kaufmodell gleich sein. Abbilder mit Windows Server oder SQL Server können eine Softwarelizenz im Preis enthalten. Geeignete vorhandene Lizenzen können den Satz senken. Die Region wirkt sich auf Preis, Latenz und Datenresidenz aus.

Marktplatzsoftware ergänzt die Anbieterrechnung um Gebühren Dritter. Währungsumrechnung und Steuern können anschließend die Rechnungssumme verändern. Der AWS Pricing Calculator schließt Steuern aus; Rechnungen können je nach Rechnungsort und Kundenstatus Verkaufssteuer, Mehrwertsteuer oder GST enthalten.

Kostenlose Angebote verstehen

Kostenlose Angebote umfassen wiederkehrende monatliche Freikontingente, zeitlich begrenzte Testangebote und Guthaben. AWS bietet neuen Konten bis zu 200 US-Dollar Guthaben. Sein Free-Plan wird nach sechs Monaten oder bei Verbrauch des Guthabens geschlossen, je nachdem, was zuerst eintritt, sofern er nicht auf einen Paid-Plan umgestellt wird. Bei kostenpflichtigen Konten fallen oberhalb der Freikontingente oder nach Verbrauch des Guthabens normale Gebühren an. Richte für ein kostenpflichtiges Testkonto eine Budgetwarnung ein, auch wenn seine ersten Workloads in ein kostenloses Angebot passen.

Schätze Speichermenge, Operationen, Abruf, Aufbewahrung, Redundanz und Datenübertragung gemeinsam.

Preise nach der geplanten Datennutzung berechnen

Zu den Objektspeicherebenen für häufigen Zugriff gehören Amazon S3 Standard, Azure Blob hot und Google Cloud Storage Standard. Sie berechnen mehr für die Speicherung als seltener genutzte Ebenen und haben keine Abrufgebühr. Zu den seltener genutzten Optionen gehören S3 Standard-IA und Glacier-Klassen, Azure cool, cold und archive sowie Google Nearline, Coldline und Archive. Sie bieten günstigeren Speicher im Austausch für Abrufgebühren und bei einigen Archivprodukten eine Wiederherstellungsdauer von Stunden.

Bei Beispielsätzen kosten 10.000 GB in einer Standardebene zu 0,023 € pro GB-Monat monatlich 230 €. Eine Archivebene zu 0,002 € kostet 20 € für die Speicherung. Der Abruf von 2.000 GB zu 0,02 € pro GB erhöht die Kosten um 40 € auf 60 € vor Operationen und anderen gegebenenfalls anfallenden Gebühren. Der Abruf aller 10.000 GB erhöht die Kosten um 200 € und bringt diese beiden Bestandteile auf 220 €. Häufiger Abruf kann die Ersparnis aufheben, und lange Wiederherstellungszeiten können eine Archivebene ausschließen.

Aufbewahrung und Kapazität beachten

Eine Mindestspeicherdauer bedeutet, dass bei vorzeitigem Löschen oder Verschieben eine Gebühr für die verbleibende Zeit anfallen kann. Google Coldline hat eine Mindestdauer von 90 Tagen, Azure archive von 180 Tagen. Löschst du ein Objekt nach 30 Tagen aus einer Ebene mit 90 Tagen Mindestdauer, werden die verbleibenden 60 Tage weiterhin berechnet.

Blockdatenträger werden üblicherweise nach bereitgestellter Größe und manchmal nach bereitgestellter Leistung berechnet. Ein 500-GB-Datenträger mit 50 GB geschriebenen Daten wird weiterhin als 500 GB berechnet. Objektspeicher wird für gespeicherte Daten berechnet. Snapshots und Datensicherungen verursachen eigene Gebühren für gespeicherte Daten. Redundanz schafft zusätzliche Kopien; eine Kopie in einer zweiten Region kann sowohl Speicher- als auch Übertragungskosten verursachen.

Die Übertragungsrichtung verfolgen

Eingehender Datenverkehr bezeichnet Daten, die hereinkommen; ausgehender Datenverkehr bezeichnet Daten, die hinausgehen. Eingehender Internetverkehr ist in der Regel kostenlos, einschließlich gewöhnlicher Datenübertragungen aus dem Internet zu AWS. Ausgehender Internetverkehr wird häufig pro GB berechnet, mit Preisstaffeln und Freikontingenten. Kopien zwischen Regionen sind ebenfalls kostenpflichtig, meist als ausgehender Datenverkehr aus der Quellregion.

Bei einer Beispielanwendung kosten 2.000 GB, die zu 0,09 € pro GB an Internetnutzer gesendet werden, 180 €. Die Replikation von 500 GB in eine andere Region zu 0,02 € erhöht die Kosten um 10 €. Der kostenlose Empfang von 300 GB an Uploads fügt keine Kosten hinzu. Die Zwischensumme für die Übertragung beträgt 190 €. Die Speicherrechnung für die replizierten Daten fällt getrennt an.

Auch die Übertragung zwischen Zonen kann Geld kosten. Bei AWS kann EC2-Datenverkehr zwischen Verfügbarkeitszonen auf beiden Seiten der Übertragung Gebühren verursachen; für andere Dienste gelten eigene Regeln und Ausnahmen. Datenverkehr über private Adressen innerhalb einer Zone ist in der Regel kostenlos. Verfolge jeden Pfad durch die tatsächlich genutzten Dienste und prüfe deren Preisseiten einschließlich der Freikontingente. Berücksichtige bei der Planung eines späteren Wechsels zu einem anderen Anbieter auch ausgehende Übertragungen.

Der niedrigste Stundensatz ist nur dann nützlich, wenn seine Bedingungen zur Workload passen. Vergleiche Flexibilität, eine langfristige Verpflichtung und die Möglichkeit, Unterbrechungen zu verkraften, bevor du ein Kaufmodell auswählst.

Flexible Nutzung oder feste Nutzungszusage

On-Demand beinhaltet keine langfristige Nutzungszusage: Du zahlst den regulären Satz für die genutzte Zeit. Das passt zu kurzen, ungewissen und wechselnden Workloads. Eine Nutzungszusage senkt den Satz im Austausch für eine ein- oder dreijährige Verpflichtung. Eine Laufzeit von drei Jahren bietet einen höheren Rabatt als ein Jahr. Ressourcenzusagen richten sich nach Merkmalen wie Ressourcentyp und Region; Ausgabenzusagen decken geeignete Nutzung bis zu einem stündlichen Betrag ab.

AWS nutzt Reserved Instances und Savings Plans; Azure bietet Reservations und den savings plan for compute. Google Cloud bietet ressourcen- und ausgabenbasierte committed use discounts. AWS wirbt für Reserved Instances und Savings Plans mit Einsparungen von bis zu 72 %. Die beworbene maximale Ersparnis gilt nicht für jede Konfiguration.

Eine Nutzungszusage wird für jede Stunde ihrer Laufzeit bezahlt, auch für ungenutzte Stunden. Bei 10 € pro Stunde für ein Jahr beträgt die Verpflichtung 87.600 €. Fallen in einer Stunde zu Plansätzen nur 8 € geeignete Nutzung an, kostet diese Stunde trotzdem 10 €. Die ungenutzten 2 € lassen sich nicht auf eine Stunde mit höherer Nutzung übertragen. Nutzung oberhalb der Zusage wird zu On-Demand-Preisen berechnet.

Den Break-even-Punkt berechnen

Eine Beispiel-VM kostet On-Demand 0,20 € pro Stunde oder mit einer einjährigen Nutzungszusage 0,13 € pro Stunde. Die Nutzungszusage kostet für 8.760 Stunden 1.138,80 €. Ganzjährige On-Demand-Nutzung kostet 1.752 €; die Ersparnis beträgt 613,20 € oder 35 %.

Am Break-even-Punkt müssen die On-Demand-Stunden 1.138,80 € kosten: Dividiere durch 0,20 €, um 5.694 Stunden zu erhalten. Das sind 65 % des Jahres. Oberhalb von 65 % Nutzung lohnt sich die Nutzungszusage; bei 65 % sind die Gesamtkosten gleich. Eine nur an Wochentagen genutzte Workload mit 2.080 Stunden kostet On-Demand nur 416 €. Richte die Nutzungszusage am gemessenen Grundbedarf aus, nicht am kurzzeitig erreichten Maximum einer Workload.

Die AWS-Zahlungsoptionen sind All Upfront, Partial Upfront und No Upfront; höhere Vorauszahlungen erhöhen in der Regel den Rabatt. Azure savings plans haben bei monatlicher Zahlung und Vorauszahlung dieselben Gesamtkosten und können weder gekündigt noch erstattet werden.

Wissen, was eine Reservierung zusagt

Eine AWS Reserved Instance ist ein Abrechnungsvorteil, kein dedizierter physischer Server. Zu den Kriterien für die Übereinstimmung gehören Instanzmerkmale, Region, Betriebssystem und Mandantenbetrieb. Regionale Reservierungen gelten zonenübergreifend; zonale reservieren zusätzlich Kapazität in einer gewählten Zone. Standard Reserved Instances können geändert, aber nicht umgetauscht werden; Convertible Reserved Instances lassen sich bei geringerem Rabatt gegen andere Merkmale umtauschen. Nach Ablauf der Laufzeit laufen Instanzen zu On-Demand-Preisen weiter.

Spot für neu startbare Aufgaben nutzen

Spot nutzt freie Kapazität, die der Anbieter zurückfordern kann. AWS wirbt mit bis zu 90 % Rabatt, Google Cloud mit bis zu 91 %. AWS kündigt eine Unterbrechung normalerweise zwei Minuten vorher an; Azure bemüht sich um eine Ankündigung bis zu 30 Sekunden vorher.

Bei Beispielsätzen kosten 400 Stunden Rechenzeit On-Demand zu 0,20 € 80 € oder mit Spot zu 0,06 € 24 €. Erhöhen Wiederholungen die Arbeit um 10 % auf 440 Stunden, kostet Spot 26,40 €. Stapelverarbeitungsaufträge, Rendering, Builds und neu startbare Analysen können zu Spot passen; eine einzelne Datenbank, die verfügbar bleiben muss, nicht. Eine nützliche Mischung sind Nutzungszusagen für gleichbleibenden Bedarf, On-Demand für schwankenden Bedarf und Spot für neu startbare Aufträge.

Rabatte für kontinuierliche Nutzung bei Google funktionieren anders: Geeignete Maschinentypen, darunter N1 und N2, können bei mehr als 25 % monatlicher Nutzung automatisch und ohne Nutzungszusage Rabatte erhalten, die je nach Typ bis zu 20 % oder 30 % erreichen.

Drei unterschiedliche Anforderungen können eine besondere Kaufentscheidung rechtfertigen: exklusive Hardware, zugesicherte Kapazität oder geeignete Softwarelizenzen. Bestimme zuerst den Bedarf und vergleiche dann die Kosten der passenden Option.

Einen Server teilen oder einen Host kontrollieren

Im Mehrmandantenbetrieb befinden sich die VMs verschiedener Kunden auf demselben physischen Server und werden durch den Hypervisor voneinander isoliert. Das ist für viele Workloads die wirtschaftliche Standardwahl. AWS Dedicated Instances laufen auf Hardware, die von einem Kunden genutzt wird, geben diesem Kunden aber weder die Kontrolle über die Platzierung auf dem Host noch Einblick in den physischen Server.

Ein dedizierter Host stellt einen ganzen Server und Einblick in dessen Sockel und Kerne bereit. AWS Dedicated Hosts, Azure Dedicated Host und Google Cloud sole-tenant nodes erfüllen diesen Bedarf. Kunden können steuern, welche VMs auf diesem Host platziert werden. Compliance-Anforderungen an Hardware für einen einzelnen Mandanten und an physische Kerne oder Sockel gebundene Lizenzen können dies nützlich machen.

Der ganze Host wird berechnet, auch wenn er teilweise leer ist. Bei einem Beispielsatz von 5 € pro Stunde kostet ein Host für einen Monat mit 730 Stunden 3.650 €. Nimmt er 12 VMs auf, betragen die stündlichen Hostkosten bei voller Belegung durchschnittlich etwa 0,42 € pro VM. Bei nur vier VMs sind es durchschnittlich 1,25 €. Dieselbe Hostrechnung wird also auf weniger nutzbare Maschinen verteilt. Vergleiche neben dem ausgewiesenen Hostpreis auch die erwartete Auslastung.

Kapazität zu reservieren ist eine andere Kaufentscheidung

Eine Kapazitätsreservierung hält passende Rechenkapazität vor, damit sie bei Bedarf verfügbar ist. AWS und Azure bieten zonale On-Demand-Kapazitätsreservierungen an. Auch Google-Cloud-Reservierungen sind zonal; ihr Nutzungsgeltungsbereich hängt von der Reservierung und dem Dienst ab. Gib die benötigten Maschinenmerkmale und den Standort an.

Für eine Kapazitätsreservierung fallen Gebühren für die reservierte Kapazität an, auch wenn sie ungenutzt bleibt. Sie gewährt für sich genommen keinen Rabatt; ein passender Vorteil aus einer Nutzungszusage kann die Rechnung senken. Sie macht den physischen Host auch nicht für einen Kunden exklusiv. Frage bei einer geplanten Veranstaltung oder einem Wiederherstellungsstandort getrennt, ob Kapazität verfügbar sein muss und ob sich ein niedrigerer Satz durch eine Nutzungszusage lohnt.

Die Unterscheidung erklärt auch die AWS-Begriffe. Eine regionale Reserved Instance bietet einen Abrechnungsrabatt. Eine zonale Reserved Instance verbindet einen Abrechnungsrabatt mit einer Kapazitätsreservierung. Ein dedizierter Host beantwortet die Frage nach dem Mandantenbetrieb. Ähnliche Namen machen diese Optionen nicht austauschbar.

Lizenzberechtigung prüfen

Bei Abbildern mit eingeschlossener Lizenz ist die Softwarelizenz im Cloud-Satz enthalten. Bei Bring Your Own License oder BYOL werden geeignete Lizenzen genutzt, die der Kunde bereits besitzt. Ob eine Lizenz geeignet ist, bestimmen die Softwarebedingungen; allein der Besitz einer Lizenz begründet kein Recht, sie auf jedem Cloud-Server zu nutzen.

Der Azure-Hybridvorteil unterstützt geeignete Windows-Server- und SQL-Server-Lizenzen mit Software Assurance oder berechtigten Abonnements. AWS License Manager hilft, die Lizenznutzung nachzuverfolgen. Manche Lizenzen verlangen einen bekannten physischen Host, sodass dediziertes Hosting Teil der Lizenzentscheidung werden kann.

Angenommen, ein Team benötigt einen niedrigeren Preis für einen dauerhaft laufenden Dienst, hat aber keine Vorgabe für Hardware eines einzelnen Mandanten. Eine Nutzungszusage im Mehrmandantenbetrieb erfüllt das Preisziel. Benötigt das Team für einen Start stattdessen garantierte Kapazität in einer Zone, kommt eine Kapazitätsreservierung hinzu. Muss eine Lizenz an physische Kerne gebunden sein, prüfe einen dedizierten Host und dessen Auslastung. Preis, Verfügbarkeit und Mandantenbetrieb sind unterschiedliche Merkmale, die du bewusst auswählst.

Die Gesamtbetriebskosten oder TCO addieren die Kosten für Besitz und Betrieb eines Systems über einen gewählten Zeitraum, oft drei bis fünf Jahre. So entsteht ein fairerer Vergleich, als wenn du eine Cloud-Rechnung einem Hardwarekaufpreis gegenüberstellst. Beide Optionen müssen über denselben Zeitraum denselben benötigten Dienst erbringen.

Kaufkosten und Betriebskosten trennen

Mit Investitionsausgaben oder CapEx werden Vermögenswerte wie Server und Gebäude gekauft, die über mehrere Jahre genutzt und abgeschrieben werden. Betriebsausgaben oder OpEx bezahlen laufende Dienste und Betriebskosten. Die Cloud verlagert einen großen Teil der Ausgaben von Hardwarekäufen im Voraus zu wiederkehrenden Dienstgebühren.

Ein eigenes Rechenzentrum verursacht auch bei geringer Nutzung viele fixe Kosten. Cloud-Nutzungsgebühren können steigen oder sinken, aber Nutzungszusagen und bereitgestellte Ressourcen schaffen weiterhin Verpflichtungen. Eine Änderung der Ausgabenart wirkt sich auf Geldfluss und Flexibilität aus; die Gesamtkosten müssen dennoch berechnet werden.

Berücksichtige bei On-Premises-Systemen Hardware, Lizenzen, Fläche, Strom, Kühlung, Wartung, physische Sicherheit, Personalzeit, Erneuerungen, Kapazität für Spitzenlasten und Notfallwiederherstellung. Berücksichtige bei der Cloud Rechenleistung, Speicher, Übertragung, verwaltete Dienste, Support, Personalzeit, Schulungen und Migration. Während eines Wechsels zahlt die Organisation möglicherweise für beide Umgebungen gleichzeitig.

Die benötigte Personalzeit wird anhand der tatsächlichen Aufgaben geschätzt. Ein Cloud-Anbieter verwaltet die physische Hardware, aber der Kunde verwaltet weiterhin Konfigurationen, Daten, Sicherheitsentscheidungen und VM-Betriebssysteme. Bewerte die nötige Arbeit und die benötigten Fähigkeiten, statt anzunehmen, dass die Personalkosten verschwinden.

Schritt für Schritt einen Vergleich erstellen

1. Umfang des Dienstes und Vergleichszeitraum festlegen.
2. Vorhandene Server, Speicher und gemessene Auslastung erfassen.
3. On-Premises-Kauf- und Betriebskosten addieren.
4. Das Cloud-System für den beobachteten Bedarf dimensionieren und seine Komponenten bepreisen.
5. Migration, Schulung und einen etwaigen Zeitraum des Parallelbetriebs hinzufügen.
6. Gesamtkosten vergleichen und anschließend Annahmen zu Wachstum und Dimensionierung prüfen.

Betrachte ein Beispiel über drei Jahre. Vor Ort kostet die Hardware 60.000 €. Jährlich kosten Strom und Kühlung 9.000 €, Fläche 6.000 €, Personal 40.000 €, Lizenzen 10.000 € und Wartung 5.000 €. Diese jährlichen Kosten ergeben zusammen 70.000 €. Drei Jahre kosten 60.000 € zuzüglich 210.000 €, also 270.000 €.

Die Cloud-Alternative benötigt monatlich 3.500 € für Rechenleistung und Speicher, 300 € für Übertragung und 350 € für Support. Die monatlichen 4.150 € ergeben über 36 Monate 149.400 €. Hinzu kommen 60.000 € für drei Jahre Personalzeit und 25.000 € für die Migration: 234.400 €. Der Unterschied beträgt 35.600 €, etwa 13 % der On-Premises-Gesamtkosten.

Prüfen, was das Ergebnis verändern könnte

Eine größere Cloud-Konfiguration, schnelleres Wachstum oder mehr ausgehender Datenverkehr können diese Ersparnis verringern. Eine Nutzungszusage kann die Sätze senken, schafft aber eine Verpflichtung. Wer gekaufte Kapazität für Spitzenlasten in die Cloud überträgt, kann den Bedarf überschätzen; die gemessene Auslastung hilft bei der passenden Dimensionierung der Schätzung.

AWS Migration Evaluator, der Business Case von Azure Migrate und Google Cloud Migration Center helfen, Systeme zu erfassen und Kosten zu vergleichen. Ihre Ergebnisse hängen von der eingegebenen Bestandsaufnahme und den Annahmen ab. Führe schwer zu beziffernde Vorteile wie schnellere Bereitstellung, globale Reichweite, Elastizität und Widerstandsfähigkeit neben der Kostenrechnung auf. Skaleneffekte helfen Anbietern, Kosten zu senken. Eine unverändert migrierte, gleichmäßig genutzte Workload zu On-Demand-Preisen kann dennoch genauso viel oder mehr kosten als die On-Premises-Alternative.

Ein Preisrechner wandelt eine geplante Cloud-Konfiguration in eine geschätzte Gebühr um. AWS, Azure und Google Cloud bieten kostenlose Webrechner an. Gib alle Komponenten und eine realistische Nutzung ein, bevor du Entwürfe vergleichst.

Alle Komponenten erfassen

Beginne mit der Architektur: Anwendungs-VMs, Datenbank, Datenträger, Objektdaten, Anfragen, Datensicherungen und Übertragungspfade. Berücksichtige Entwicklungs- und Testumgebungen, nicht nur die Produktion. Wähle für jeden Dienst Region, Betriebssystem, Ressourcengrößen, Betriebsstunden und Preismodell. Füge den Supportplan gesondert hinzu, falls er noch nicht enthalten ist.

Verwende durchgehend dieselbe Zeitbasis. Setze für einen Schätzmonat mit durchgehendem Betrieb 730 Stunden an. Ein Testsystem für Wochentage braucht seinen tatsächlichen Zeitplan, während beibehaltene Datenträger möglicherweise einen vollen Monat Speicher benötigen. Rechne die Rohzahlen der Anfragen in Millionen um, bevor du einen Satz pro Million anwendest.

Die Einzelpositionen addieren

Verwende für eine kleine Webanwendung diese Beispielsätze und monatlichen Mengen:

Die Summe dieser vier Positionen beträgt 325,26 € monatlich oder 3.903,12 € jährlich. Füge dieser Zwischensumme benötigte Datensicherungen, Support und andere Dienste hinzu.

Senkt eine einjährige Nutzungszusage nur den VM-Satz um 35 %, ergibt die VM-Position 140,16 € multipliziert mit 0,65, also vor dem Runden 91,104 €. Addierst du die unveränderten Kosten für Datenbank, Speicher und ausgehenden Datenverkehr, erhältst du 276,204 €, ausgewiesen als 276,20 € monatlich. Würdest du 35 % auf die ganze Schätzung anwenden, erhielten Dienste außerhalb dieses VM-Angebots fälschlich einen Rabatt.

Die Bedeutung der Schätzung festhalten

Prüfe monatliche Gebühren, Vorauszahlungen und Jahressummen gemeinsam. Ein Angebot mit vollständiger Vorauszahlung kann eine kleine laufende Rechnung ausweisen, obwohl zu Beginn Geld benötigt wird. Halte Datum, Region, Konfiguration, Stunden, Übertragung, Laufzeit der Nutzungszusage und Preisgrundlage fest. Öffentliche Schätzungen verwenden Listenpreise; einige Rechner können ausgehandelte Preise nutzen. Der Google-Rechner kann Vertragspreise verwenden, wenn er mit einem geeigneten Rechnungskonto verbunden ist.

Der AWS Pricing Calculator schließt Steuern aus. Preislisten und APIs wie die AWS Price List API und die Azure Retail Prices API liefern Sätze für Tools und Skripte; die Sätze können sich nach dem Speichern einer Schätzung ändern.

Gruppiere die Schätzung nach Workload, speichere einen teilbaren Link und exportiere sie zur Überprüfung. AWS unterstützt CSV- und PDF-Exporte. Vergleiche nach der Bereitstellung jede größere Position mit dem Kostenbericht. Untersuche Abweichungen bei tatsächlichen Stunden, Speicher und Übertragung gegenüber den gespeicherten Mengen.

Eine zentrale Abrechnungsstelle kann für getrennte Konten, Abonnements oder Projekte mehrerer Teams bezahlen. Behalte sowohl die zahlende Stelle als auch die Ressourcenverantwortlichen im Blick.

Die zahlende Stelle finden

Bei AWS hat eine Organisation in AWS Organizations ein Verwaltungskonto, das die Mitgliedskonten über die konsolidierte Abrechnung bezahlt. Bei Azure sind Abonnements einem Rechnungskonto untergeordnet; unter einem Microsoft Customer Agreement organisieren Abrechnungsprofile und Rechnungsabschnitte die Zahlung. Bei Google Cloud ist jedes Projekt mit einem Cloud-Rechnungskonto verbunden, das seine Gebühren bezahlt.

Eine Rechnung umfasst normalerweise einen Kalendermonat. Ihre Gruppierungen nach Dienst, Nutzungsart, Region und Konto oder Projekt erklären die Gebühren. Guthaben, Erstattungen und Steuern beeinflussen den fälligen Betrag. Detaillierte Positionen verbinden eine gemessene Menge mit einem Satz und, sofern verfügbar, einer Ressource.

Berechtigte Nutzung für Mengenpreise zusammenfassen

Die konsolidierte Abrechnung von AWS kostet keine zusätzliche Gebühr und fasst berechtigte Nutzung für Mengenpreisstaffeln zusammen. Betrachte Beispielsätze für Speicher: 0,023 € pro GB-Monat für die ersten 50.000 GB und 0,022 € darüber. Drei Konten speichern einen Monat lang jeweils 20.000 GB.

Bei getrennter Abrechnung zahlt jedes 460 €, insgesamt also 1.380 €. Die konsolidierte Nutzung beträgt 60.000 GB: Die ersten 50.000 kosten 1.150 € und die verbleibenden 10.000 kosten 220 €. Die konsolidierte Summe beträgt 1.370 €.

Nur die Menge oberhalb der Staffelgrenze erhält den niedrigeren Satz. Würden alle 60.000 GB zu 0,022 € berechnet, ergäbe das 1.320 € und die günstigere Staffel würde fälschlich auf die vorherige Nutzung ausgedehnt.

Geteilte Vorteile aus Nutzungszusagen nachvollziehen

Vorteile aus Reserved Instances und Savings Plans können ebenfalls zwischen berechtigten Konten geteilt werden. Besitzt Konto A eine Reserved Instance, hat aber in einer Stunde keine passende Nutzung, kann eine laufende passende Instanz von Konto B den Vorteil erhalten. Das Verwaltungskonto kann die gemeinsame Nutzung für ausgewählte Konten ausschalten.

Die angezeigte Rechnung eines Mitgliedskontos ist daher eine Informationsansicht der Gebühren und zugewiesenen Vorteile. Wende die zentrale Zuordnungsregel an, wenn ein anderes Team den gekauften Vorteil nutzt.

Getrennte Konten, Abonnements oder Projekte machen die Verantwortung sichtbar, weil Gebühren diesen Bereichen bereits zugeordnet sind. Tags unterteilen die Kosten darin weiter, etwa nach Anwendung oder Umgebung.

Für den Zugriff auf die Abrechnung ist weiterhin eine Berechtigung nötig. Gib Personen, die Kosten einsehen, die Möglichkeit, Berichte zu prüfen, ohne ihnen zugleich das Recht zu geben, Zahlungsdaten zu ändern oder Nutzungszusagen zu kaufen. Trenne Kosteneinsicht, Zahlungsänderungen und den Kauf von Nutzungszusagen durch Berechtigungen nach dem Prinzip der geringsten Rechte.

Nutze Kostenberichte, um den Dienst, die Ressource und die verantwortliche Person hinter einer Ausgabenveränderung zu finden.

Eine nützliche Ansicht wählen

AWS Cost Explorer, die Kostenanalyse in Microsoft Cost Management und Google Cloud Billing reports zeigen Ausgaben im Zeitverlauf. Filtere und gruppiere nach Dienst, Konto oder Projekt, Region, Nutzungsart und Tags. Prognosen schätzen künftige Kosten anhand früherer Nutzungsmuster.

Exportiere für eine detaillierte Analyse Abrechnungsdatensätze. Daten des AWS Cost and Usage Report können über AWS Data Exports an S3 geliefert werden, Azure-Cost-Management-Exporte schreiben in ein Speicherkonto und Google-Cloud-Abrechnungsexporte gehen an BigQuery. Mit diesen Datensätzen können Analysten Ressourcen-IDs, Mengen und Tags abfragen oder eigene Dashboards erstellen.

Zahlungszeitpunkt und zeitlich verteilte Kosten unterscheiden

Eine Ansicht tatsächlicher Kosten zeigt Gebühren in dem Zeitraum, in dem sie berechnet wurden. Eine Ansicht amortisierter Kosten verteilt im Voraus bezahlte Gebühren für Nutzungszusagen über deren Laufzeit. Kostet eine einjährige Nutzungszusage im Voraus 8.760 €, zeigt die tatsächliche Ansicht im Kaufmonat 8.760 €. Eine einfache monatliche amortisierte Ansicht verteilt sie auf etwa 730 € pro Monat.

Nutze tatsächliche Kosten für den Zahlungszeitpunkt und amortisierte Kosten für Zeitvergleiche; ein Kauf im Voraus ist kein Nutzungssprung.

Die größte Veränderung genauer untersuchen

Angenommen, die Rechnung steigt von 10.000 € auf 12.000 €. Der Anstieg um 2.000 € beträgt 20 % des Vormonats. Eine Gruppierung nach Dienst zeigt:

Die Übertragung erklärt 1.900 € des Nettoanstiegs um 2.000 €, also 95 %. Beginne dort: Gruppiere die Übertragung nach Region, dann nach Konto oder Tag und untersuche anschließend Ressource und Nutzungsart. Ein zunehmender Replikationspfad verlangt eine andere Reaktion als wachsende Downloads an Kunden. Bestimme nach dem Finden der Ursache eine verantwortliche Person und eine Maßnahme.

Verzögerungen und verborgene Veränderungen berücksichtigen

Abrechnungsberichte hinken der Ressourcenaktivität hinterher. AWS-Budgetdaten werden bis zu dreimal täglich aktualisiert; Azure-Kostendaten treffen üblicherweise innerhalb von 8 bis 24 Stunden ein. Eine neue Workload kann bereits Ausgaben verursachen, bevor ihre Kosten erscheinen. Vergleiche beim Prüfen einer Warnung gleichwertige Zeiträume und Kostenansichten.

Anomalietools erkennen ungewöhnliche Ausgabenmuster. AWS Cost Anomaly Detection, Anomaliewarnungen in Microsoft Cost Management und die Anomalieerkennung von Google Cloud können auf einen vergessenen Cluster oder einen Übertragungssprung hinweisen. Empfehlungsdienste wie AWS Trusted Advisor, Azure Advisor und Google Cloud Recommender schlagen Einsparungen vor, die untersucht werden sollten.

Eine gleichbleibende Gesamtsumme kann wachsende Datenbankkosten verbergen, die durch sinkende VM-Kosten ausgeglichen werden. Vergleiche Veränderungen nach Dienst zusammen mit Gruppierungen nach Konto und Tag, um sowohl Nutzung als auch Verantwortung zu erkennen.

Ein Budget legt einen geplanten Betrag für einen Zeitraum und Geltungsbereich fest. Warnungen vergleichen Kosten oder Nutzung mit diesem Plan. Sie helfen, vor der Schlussrechnung zu reagieren; deshalb sind Geltungsbereich, Schwellen und Empfänger ebenso wichtig wie der Betrag.

Geltungsbereich und Zweck festlegen

AWS Budgets, Budgets in Microsoft Cost Management und Google Cloud Billing budgets können ein Konto oder einen engeren Teilbereich verfolgen. Beispiele sind ein Azure-Abonnement oder eine Ressourcengruppe, ein Google-Projekt oder ein Filter nach Dienst oder Tag. Azure unterstützt monatliche, vierteljährliche und jährliche Zurücksetzungen; AWS unterstützt auch benutzerdefinierte Zeiträume wie die Dauer eines Projekts.

AWS bietet Kosten- und Nutzungsbudgets sowie Auslastungs- und Abdeckungsbudgets für Reserved Instances und Savings Plans. Die Auslastung fragt, wie viel der gekauften Nutzungszusage genutzt wird. Die Abdeckung fragt, wie viel der berechtigten Nutzung einen Vorteil aus einer Nutzungszusage erhält. Ein Team kann eine hohe Auslastung, aber eine niedrige Abdeckung haben, wenn eine kleine Nutzungszusage von einer viel größeren Workload vollständig genutzt wird.

Schwellen für tatsächliche und prognostizierte Kosten nutzen

Eine Warnung zu tatsächlichen Kosten vergleicht die bisherigen Ausgaben mit einer Schwelle. Eine Warnung zu prognostizierten Kosten vergleicht die erwarteten Ausgaben für den gesamten Zeitraum mit einer Schwelle. Zu den von Google vorgeschlagenen Standardschwellen gehören 50 %, 90 % und 100 %; wähle Werte, die den Verantwortlichen Zeit zum Reagieren lassen.

Bei einem monatlichen Budget von 5.000 € liegt eine Schwelle von 80 % für tatsächliche Kosten bei 4.000 €. Am 12. Tag eines Monats mit 30 Tagen betragen die Ausgaben 2.400 €. Das sind 48 % des Budgets, die Schwelle für tatsächliche Kosten ist also noch nicht erreicht. Bei den aktuellen 200 € pro Tag erreicht eine einfache Prognose 6.000 € oder 120 % des Budgets. Eine Prognoseschwelle von 100 % warnt jetzt.

Das verbleibende Budget beträgt 2.600 € für 18 Tage. Durch Division erhältst du etwa 144,44 € pro Tag. Das ist der durchschnittliche verbleibende Ausgabenrahmen, um den Plan einzuhalten; geringere künftige Ausgaben beseitigen keine bereits angefallenen Gebühren.

Festlegen, was nach der Warnung geschieht

Ein gewöhnliches Budget warnt, stoppt Ausgaben aber standardmäßig nicht. Azure-Budgetbenachrichtigungen wirken sich nicht auf Ressourcen aus. Reine Warnbudgets von Google begrenzen den Verbrauch nicht. Abrechnungsdaten treffen verzögert ein, sodass Kosten eine Schwelle überschreiten können, bevor die Benachrichtigung jemanden erreicht.

Automatisierung muss konfiguriert werden. AWS-Budgetaktionen können IAM- oder Service-Kontrollrichtlinien anwenden oder EC2- und RDS-Instanzen stoppen. Azure-Aktionsgruppen können Functions, Logic Apps oder Webhooks aufrufen. Google-Pub/Sub-Benachrichtigungen können Automatisierungen auslösen; Google bietet außerdem separat konfigurierte Budgets mit Ausgabenobergrenze, die unterstützte Dienste in einem Projekt pausieren.

Wähle die Aktion unter Berücksichtigung des Verfügbarkeitsbedarfs der Workload. Ein Testsystem automatisch zu stoppen, kann vertretbar sein; das Stoppen der einzigen Produktionsdatenbank kann einen teuren Ausfall verursachen. Prüfe Geltungsbereich und Berechtigungen einer automatisierten Aktion, bevor du dich auf sie verlässt.

Eine verantwortliche Person für das Budget benennen

Benachrichtigungen können per E-Mail, an AWS-SNS-Themen und Chat-Apps, Azure-Aktionsgruppen und die mobile App oder Google-Pub/Sub- und Cloud-Monitoring-Kanäle gehen. Benenne die Person oder das Team, die oder das die Untersuchung übernehmen soll, und lege fest, wie dringende Warnungen behandelt werden. Ein gemeinsames Postfach ist nur nützlich, wenn jemand für die Reaktion verantwortlich ist. Prüfe bei regelmäßigen Überprüfungen, ob der Geltungsbereich noch zur Workload passt und die Empfänger weiterhin zum Handeln befugt sind.

Ein Tag ist eine Schlüssel-Wert-Kennzeichnung an einer Ressource, etwa „Environment = Production“ oder „CostCenter = 4410“. Tags verbinden technische Ressourcen mit den Personen und Geschäftszwecken hinter ihren Kosten. AWS und Azure nutzen dafür Tags; Google Cloud nutzt Labels für die Aufschlüsselung der Abrechnung und getrennte Tags hauptsächlich für bedingte Richtlinien.

Einen gemeinsamen Standard festlegen

Nützliche Schlüssel sind CostCenter, Owner, Environment, Project und Application. Definiere zulässige Namen und Werte und wende sie beim Erstellen von Ressourcen an. „Environment = Production“ und „environment = prod“ können eine beabsichtigte Gruppe in zwei Gruppen aufteilen. Bei AWS wird bei Tag-Schlüsseln und -Werten zwischen Groß- und Kleinschreibung unterschieden. Bei Azure wird bei Vorgängen für Tag-Namen nicht danach unterschieden, für Werte aber schon.

Getrennte Konten schaffen eine grobe Verantwortungsgrenze; Tags ergänzen Details innerhalb dieser Grenze. Ein gemeinsam genutztes Konto könnte Ressourcen mit „Application = Orders“ und „Application = Search“ enthalten, sodass ein Kostenbericht diese Anwendungen trennen kann, ohne sie zu verschieben.

Die Kennzeichnungen für die Abrechnung nutzbar machen

Bei AWS muss ein Verwaltungs- oder eigenständiges Konto Tags in Billing and Cost Management als Kostenzuordnungs-Tags aktivieren. Neben benutzerdefinierten Tags gibt es von AWS erzeugte Tags mit dem Präfix „aws:“, etwa „aws:createdBy“. Aktivierung und Verfügbarkeit können Zeit brauchen; bis zum Erscheinen können bis zu 24 Stunden vergehen. Eine angeforderte nachträgliche Übernahme kann Tags auf bis zu 12 Monate zurückliegende Kostendaten für Ressourcen anwenden, die sie bereits trugen.

Azure-Ressourcen erben Tags von Ressourcengruppen oder Abonnements standardmäßig nicht. Azure Policy kann Tags an Ressourcen hinzufügen oder vererben. Die Tag-Vererbung von Cost Management wendet Tags höherer Ebenen auf Nutzungsdatensätze an; diese Berichtsfunktion unterscheidet sich davon, Tags auf die Ressourcen selbst zu schreiben. Azure erlaubt bis zu 50 Tags pro Ressource, Ressourcengruppe oder Abonnement.

Gemeinsame und fehlende Kosten ausdrücklich zuordnen

Nicht jeder Ressourcentyp unterstützt Tags, und Supportgebühren, Steuern und einige Übertragungsgebühren haben möglicherweise kein Ressourcen-Tag. Behalte eine Kategorie für nicht zugeordnete Kosten bei und vereinbare, wie tatsächlich gemeinsam genutzte Kosten aufgeteilt werden.

Angenommen, die Ressourcengebühren betragen insgesamt 5.000 €: Auf Team A entfallen 3.000 €, auf Team B 1.500 €, und 500 € haben kein Tag. Die Kosten mit Tags betragen insgesamt 4.500 €. Eine gesonderte Supportgebühr von 400 € wird im Verhältnis der Kosten mit Tags aufgeteilt. Team A erhält den Anteil 3.000 € geteilt durch 4.500 € an der Gebühr, also 266,67 €. Team B erhält 133,33 €. Die vollständige Rechnung beträgt 5.400 €, und die 500 € ohne Tag bleiben zur Klärung durch die Verantwortlichen offen. Verteile sie nicht stillschweigend, als wäre ihre Zuordnung bekannt.

Showback weist einem Team Kosten zur Information aus. Chargeback bucht diese Kosten auf sein internes Budget. Beides braucht zuverlässige Ressourcenzuständigkeiten und eine Zuordnungsmethode, die gemeinsame Gebühren erklärt.

Tags korrekt und sicher halten

Setze den Standard durch Infrastructure as Code und Prozesse zur Ressourcenerstellung um. AWS-Tag-Richtlinien vereinheitlichen unterstützte Tag-Schlüssel und -Werte; nutze zusätzliche Kontrollen, um fehlende Tags zu erkennen oder zu verhindern. Azure Policy kann ein Tag verlangen, einen Wert hinzufügen oder eine regelwidrige Erstellung ablehnen. Verfolge die Tag-Abdeckung als Anteil der relevanten Kosten mit den erforderlichen Tags und untersuche fehlende Abdeckung.

Tags erscheinen als Klartext in Berichten, Protokollen und Exporten. Halte Passwörter, personenbezogene Daten und andere sensible Werte aus ihnen heraus. Ein Tag für sich genommen ist ein Metadatum; Zugriffsregeln brauchen eine separate Richtlinie, die es nutzt.

Cloud Governance verbindet Regeln, Prozesse und Kontrollen. Eine präventive Maßnahme blockiert eine unerwünschte Aktion, eine detektierende Maßnahme meldet ein Problem und eine korrigierende Maßnahme behebt es. Wähle die Kontrolle passend zur tatsächlichen Anforderung: Wer darf handeln, welcher Ressourcenzustand ist erlaubt oder was muss gegen versehentliche Änderungen geschützt werden?

Azure-Ressourcenregeln anwenden

Azure RBAC steuert, wer Aktionen ausführen darf. Azure Policy prüft Ressourceneigenschaften unabhängig davon, wer die Anfrage sendet. Ein Contributor kann die Berechtigung haben, VMs zu erstellen, aber eine Allowed-locations-Richtlinie kann eine nicht genehmigte Region trotzdem ablehnen.

Eine Richtliniendefinition enthält eine Regel und eine Wirkung. Eine Initiative gruppiert Definitionen. Eine Zuweisung wendet eine davon auf eine Verwaltungsgruppe, ein Abonnement, eine Ressourcengruppe oder eine Ressource an; untergeordnete Bereiche erben sie, soweit keine Ausnahmen konfiguriert sind.

Die Wirkung bestimmt die Reaktion. audit protokolliert Verstöße; deny blockiert eine regelwidrige Änderung. modify und append können eine Anfrage ändern, etwa ein Tag hinzufügen. auditIfNotExists prüft zugehörige Ressourcen und deployIfNotExists kann sie bereitstellen. denyAction blockiert bestimmte Aktionen wie das Löschen; disabled schaltet die Bewertung aus. Vorhandene Ressourcen benötigen möglicherweise Korrekturaufgaben. Bewertungen erfolgen bei relevanten Änderungen und in Prüfungen, die normalerweise alle 24 Stunden laufen. Beginne mit audit, wenn du die Auswirkungen einer Zuweisung verstehen möchtest, bevor du deny durchsetzt.

Ressourcen vor versehentlichen Änderungen schützen

Azure-Sperren gelten auf Ebene eines Abonnements, einer Ressourcengruppe oder einer Ressource und werden vererbt. CanNotDelete, im Portal als Delete angezeigt, erlaubt Lesen und Ändern, blockiert aber das Löschen. ReadOnly erlaubt nur das Lesen und kann unerwartete Verwaltungsvorgänge blockieren, darunter das Starten einer VM oder das Auflisten von Speicherschlüsseln.

Nur Rollen mit Sperrberechtigungen wie Owner oder User Access Administrator können Sperren verwalten. Eine Sperre kann eine ansonsten erlaubte Aktion blockieren, aber jemand mit der Berechtigung, sie zu entfernen, kann diesen Schutz aufheben. Sperren schützen Verwaltungsvorgänge, keine gespeicherten Daten: Eine Speicherkontosperre verhindert nicht das Löschen von Blobs über die Datenebene. Eine gesperrte Ressource kann das Löschen ihrer gesamten Ressourcengruppe verhindern.

Die passenden organisatorischen Leitplanken nutzen

AWS-Service-Kontrollrichtlinien oder SCPs legen maximale Berechtigungen für IAM-Benutzer und -Rollen in Mitgliedskonten fest, einschließlich der Root-Benutzer von Mitgliedskonten. Sie gewähren selbst keine Berechtigungen und beschränken das Verwaltungskonto nicht. Eine SCP kann Aktionen außerhalb genehmigter Regionen verweigern. AWS-Config-Regeln erkennen Verstöße bei Ressourcen; Control Tower hilft beim Einrichten von Konten und Kontrollen. Tag-Richtlinien vereinheitlichen unterstützte Tag-Werte, aber eine Regel gegen fehlende Tags braucht geeignete zusätzliche Durchsetzung.

Der Google Cloud Organization Policy Service wendet Einschränkungen auf Ebene der Organisation, eines Ordners oder Projekts an, die in der Hierarchie nach unten vererbt werden. Alle drei Anbieter nutzen Kontingente, um Mengen wie vCPUs zu begrenzen. Ein Kontingent beschränkt die Ressourcenmenge, nicht die Gesamtrechnung über alle Dienste hinweg.

Für „genehmigte EU-Regionen, ein CostCenter-Tag und Schutz vor dem Löschen der Datenbank“ braucht Azure Regions- und Tag-Richtlinien sowie eine CanNotDelete-Sperre. AWS kombiniert regionale SCPs, Tag-Standards und Prüfungen sowie Löschschutz für die Datenbank. Google kombiniert Einschränkungen für Ressourcenstandorte, Label-Prüfungen und Löschschutz.

Microsoft Purview dient einem anderen Zweck: Es hilft, Daten über Umgebungen hinweg zu finden, zu klassifizieren, zu katalogisieren und zu schützen, und unterstützt Compliance. Beschränke VM-Größen und Regionen mit einer Ressourcenrichtlinie, nicht mit einem Datenkatalog.

Eine Person mit Cloud-Berechtigungen kann innerhalb von Minuten eine kostenpflichtige Ressource erstellen. Finanzielle Steuerung braucht daher eine kontinuierliche Praxis: Kosten ausweisen, Verantwortung zuweisen, auf Veränderungen reagieren und prüfen, ob Kontrollen weiterhin zum Unternehmen passen.

Personen, Prozesse und Technik verbinden

FinOps bringt Finanz-, Entwicklungs- und Geschäftsteams zusammen, um fundierte Ausgabenentscheidungen zu treffen. Entwickler verstehen die Systeme und können deren Nutzung ändern. Die Finanzabteilung legt Budgets und Prognosen fest. Führungskräfte entscheiden, wie Kosten gegen Geschwindigkeit, Zuverlässigkeit und Qualität abgewogen werden.

Gib jedem Konto, Abonnement oder Projekt eine namentlich benannte kostenverantwortliche Person. Ein zentrales FinOps-Team oder Cloud-Kompetenzzentrum legt gemeinsame Standards fest, erstellt Berichte und koordiniert Nutzungszusagen für den gemeinsamen Grundbedarf. Es unterstützt die Entscheidungen der Entwicklerteams, statt ihnen jede tägliche Ressourcenentscheidung abzunehmen.

Tools unterstützen diese Arbeit: Kontostrukturen, Tags, Kostenberichte, Budgets, Anomaliewarnungen, Richtlinien, Kontingente und Empfehlungen. Ein Dashboard ohne verantwortliche Person entscheidet nicht, was zu tun ist; eine Warnung ohne Reaktionsprozess kann ungelesen bleiben.

Die FinOps-Phasen wiederholen

Das FinOps Framework nennt drei sich wiederholende Phasen:

• Informieren: Ausgaben sichtbar machen und Verantwortlichen zuordnen.
• Optimieren: Nutzung und Sätze verbessern und dabei Anforderungen erfüllen.
• Betreiben: Ziele und Richtlinien festlegen, nach vereinbarten Prozessen handeln und die Praxis verbessern.

Sie bilden einen Kreislauf, kein einmaliges Projekt. Bei einer monatlichen Überprüfung lassen sich tatsächliche Kosten mit Prognosen vergleichen, Veränderungen nach Team untersuchen, die Tag-Abdeckung prüfen und ungenutzte Nutzungszusagen überprüfen. Zwischen den Überprüfungen bearbeitet ein Anomalieprozess dringende Veränderungen. Ein Kaufprozess für Nutzungszusagen sollte festlegen, wer die Verpflichtung genehmigen darf und welcher Grundbedarf sie rechtfertigt.

Die Google-Ressourcenhierarchie aus Organisation, Ordnern, Projekten und Ressourcen hilft, Verantwortung mit vererbten Zugriffs- und Organisationsrichtlinien zu verbinden. Kostentransparenz, Berechtigungsgrenzen und Prüfungen sollten zu dieser Struktur passen, damit die für ein Projekt verantwortliche Person dessen Ausgaben untersuchen kann.

Kosten ins Verhältnis zur nutzbaren Leistung setzen

Unit Economics teilt Kosten durch eine Geschäftsleistung, etwa bearbeitete Bestellungen. Bei 12.000 € für 400.000 Bestellungen betragen die Kosten 0,03 € pro Bestellung. Bei 15.000 € für 600.000 Bestellungen sinken sie auf 0,025 € pro Bestellung.

Die Rechnung stieg um 25 %, während die Bestellungen um 50 % stiegen. Eine größere Rechnung kann also mit verbesserten Kosten pro Einheit einhergehen. Prüfe sowohl die Gesamtsumme als auch den Wert pro Einheit: Die Gesamtsumme ist für das Budget wichtig, während der Wert pro Einheit die Effizienz bei veränderter Leistung erklärt. Niedrigere Kosten pro Einheit können mit ungenutzten Ressourcen einhergehen, untersuche deshalb weiterhin die Kosten einzelner Ressourcen.

Nach einem Vorfall den Kreislauf schließen

Angenommen, eine wöchentliche Anomalie zeigt einen Anstieg um 40 %. Die Warnung erreicht den Kontoverantwortlichen, der den Bericht nach Tag gruppiert und einen Testcluster findet, der in voller Größe weiterläuft. Das Team stoppt die unnötige Arbeit, bestätigt die Wirkung in späteren Kostendaten und ergänzt ein Enddatum für Anforderungen von Testressourcen. Bei der nächsten Überprüfung aktualisiert es den Standard und prüft, ob ähnliche Ressourcen vorhanden sind.

Diese Abfolge gibt jedem Tool einen Zweck: Die Warnung erkennt, der Bericht erklärt, die verantwortliche Person handelt und der Prozess verringert Wiederholungen. Prüfe vor einer Kostensenkung deren Auswirkungen auf Sicherheit, Leistung und Zuverlässigkeit. Finanzielle Steuerung strebt nützliche Geschäftsergebnisse aus Cloud-Ausgaben an und macht die Zielkonflikte für die Verantwortlichen sichtbar.

Ein Supportplan bietet Zugang zu Hilfe unter festgelegten Bedingungen. Wähle ihn anhand der Auswirkungen der Workload und der benötigten Erstreaktion und berechne dann die Gebühr. Eine Zielzeit für die Reaktion sagt dir, wann die Hilfe beginnt, nicht wann die Anwendung repariert ist.

Supportstufen vergleichen

Basispläne enthalten Hilfe zu Konto und Abrechnung, Dokumentation und Zugang zur Community. Kostenpflichtige Pläne ergänzen technische Supportfälle und schnellere Reaktionen bei schweren Vorfällen. Höhere Stufen können Architekturberatung und einen Technical Account Manager oder TAM ergänzen, der laufend berät. Eröffne Fälle über die Konsole des Anbieters, etwa AWS Support Center oder Azure Help + support.

Stand Oktober 2026 empfiehlt AWS Business Support+ als Mindestplan für den Produktivbetrieb. Er enthält an 24 Stunden pro Tag und 7 Tagen pro Woche technischen Support per Telefon, Chat und E-Mail, alle Trusted-Advisor-Prüfungen und eine Zielzeit für die Reaktion von weniger als 30 Minuten beim Ausfall eines geschäftskritischen Systems. Enterprise Support ergänzt einen zugewiesenen TAM und Well-Architected-Überprüfungen mit einer Zielzeit von weniger als 15 Minuten für diese Schwere. Unified Operations ergänzt Incident-Management-Ingenieure mit einer Zielzeit von weniger als fünf Minuten, Spezialisten und eine Überwachung der Workloads an 24 Stunden pro Tag und 7 Tagen pro Woche.

AWS stellt ältere Pläne Developer, Business und Enterprise On-Ramp in kommerziellen Regionen am 1. Januar 2027 ein. Developer- und Business-Nutzer können zu Business Support+ wechseln; Enterprise-On-Ramp-Nutzer werden auf Enterprise Support umgestellt.

Staffeln und Mindestbetrag anwenden

Business Support+ kostet den höheren Betrag aus 29 US-Dollar monatlich pro Konto und gestaffelten Prozentsätzen der monatlichen AWS-Gebühren: 9 % der ersten 10.000 US-Dollar, 7 % von 10.000 bis 80.000 US-Dollar, 5 % von 80.000 bis 250.000 US-Dollar und 3 % über 250.000 US-Dollar.

Bei Gebühren von 20.000 US-Dollar trägt die erste Staffel 900 US-Dollar und die nächste 700 US-Dollar bei, insgesamt 1.600 US-Dollar. Wende 7 % nicht auf alle 20.000 US-Dollar an: Für frühere Ausgaben gilt weiterhin der Satz ihrer Staffel. Bei Gebühren von 200 US-Dollar ergeben 9 % 18 US-Dollar, sodass der Mindestbetrag von 29 US-Dollar gilt.

Enterprise Support nutzt einen Mindestbetrag von 5.000 US-Dollar oder 10 % der ersten 150.000 US-Dollar, 7 % bis 500.000 US-Dollar, 5 % bis 1 Million US-Dollar und 3 % darüber. Bei 100.000 US-Dollar beträgt die Gebühr 10.000 US-Dollar. Unified Operations beginnt bei 50.000 US-Dollar monatlich. Vergleiche den Mindestbetrag mit der berechneten Summe, nachdem du alle relevanten Staffeln angewendet hast.

Den Plan auf den Bedarf abstimmen

Azure Basic enthält Hilfe zu Abrechnung und Abonnements. Developer kostet 29 US-Dollar monatlich für Nichtproduktionsnutzung; Fälle mit minimalen Auswirkungen werden innerhalb von acht Stunden während der Geschäftszeiten beantwortet. Standard kostet 100 US-Dollar für Produktion; kritische Fälle werden innerhalb einer Stunde beantwortet. Professional Direct kostet 1.000 US-Dollar für geschäftskritische Nutzung; kritische Fälle werden innerhalb einer Stunde und mittelschwere Fälle innerhalb von zwei Stunden beantwortet. Unified Enterprise hat individuelle Preise, eine Azure-Reaktion bei Systemausfall innerhalb von 15 Minuten und Support für weitere Microsoft-Produkte.

Google Cloud Customer Care hat die Stufen Basic, Standard, Enhanced und Premium. Kostenpflichtige Stufen verbessern die Zielzeiten für die Reaktion; Premium ergänzt einen TAM.

Für einen produktiven Webshop, der durchgehend technische Hilfe ohne festen Kundenbetreuer benötigt, kann AWS Business Support+ oder Azure Standard passen. Die Anforderung eines TAM verändert den Vergleich. Prüfe Schweregrad, Abdeckungszeiten, Zielzeit für die Erstreaktion, enthaltene Beratung und Preis gemeinsam. Der Support unterstützt das Team des Kunden; der Kunde betreibt weiterhin seine Anwendung.

Ein Anbieter bietet verschiedene Arten von Hilfe, weil unterschiedliche Probleme unterschiedliche Reaktionen brauchen. Benenne zuerst die Aufgabe: eine Konfiguration lernen, einen Vorfall untersuchen, Kosten überprüfen, Software kaufen oder eine Migration planen.

Lernen und entwerfen

Die offizielle Dokumentation erklärt Funktionen und Konfiguration. AWS ergänzt Whitepaper, Blogs, Prescriptive Guidance für Strategien und Muster sowie das Knowledge Center für häufige Fragen. Microsoft Learn und das Azure Architecture Center bieten vergleichbare Nachschlagewerke. Die Google-Cloud-Dokumentation und das Architecture Center erklären Google-Dienste und Entwurfsmuster.

Communitys ermöglichen es, Fragen zu stellen und zu beantworten: AWS re:Post, Microsoft Q&A und Azure-Communitys sowie die Google Cloud Community. Sie können bei Entwurfsfragen oder mit gemeinsamen Erfahrungen helfen. Bei einem dringenden Produktionsvorfall, für den eine Zielzeit für die Reaktion erforderlich ist, eröffne einen technischen Fall unter dem passenden Supportplan.

AWS-Lösungsarchitekten beraten zum Entwurf von Workloads, während AWS Professional Services bei der Durchführung größerer Beratungsprojekte hilft. Partner können Umgebungen entwerfen, migrieren und betreiben. Unabhängige Softwareanbieter oder ISVs verkaufen Software; Systemintegratoren und Beratungspartner verbinden Systeme und helfen bei der Umsetzung. Partnerprogramme der Anbieter bieten Schulungen, Zertifizierungen, Veranstaltungen und geschäftliche Vorteile.

Dienststatus und Empfehlungen prüfen

Dienststatus-Dashboards melden Ereignisse aufseiten des Anbieters. AWS Health zeigt den öffentlichen Dienststatus und Ereignisse, die dein Konto betreffen; die AWS Health API stellt Ereignisse für Automatisierungen bereit. Azure Service Health meldet Probleme, Wartungen und Hinweise, die für Abonnements relevant sind. Google-Cloud-Dienststatusdienste bieten Informationen zum Dienststatus und, soweit verfügbar, personalisierte Informationen zu Vorfällen.

Eine öffentliche Statusseite kann normal aussehen, während ein Ereignis ein bestimmtes Konto oder eine Ressource betrifft. Prüfe bei der Untersuchung eines Ausfalls die Konto- oder Abonnementansicht und vergleiche sie mit der eigenen Überwachung der Anwendung. Fehlt ein aufgeführtes Ereignis, ist das ein Grund, die Anwendung weiter zu untersuchen, und kein Grund, ihre Symptome zu ignorieren.

Beratungstools prüfen Konfigurationen und Nutzung. AWS Trusted Advisor prüft Kosten, Sicherheit, Fehlertoleranz, Leistung, Dienstkontingente und operative Exzellenz. Basic enthält grundlegende Prüfungen; kostenpflichtige Pläne enthalten alle Prüfungen. Azure Advisor deckt Zuverlässigkeit, Sicherheit, Leistung, Kosten und operative Exzellenz ab und bietet einen Advisor-Score. Google Cloud Recommender, Teil von Active Assist, schlägt Maßnahmen vor, etwa die Größenanpassung nicht ausgelasteter VMs.

Kaufen, beauftragen oder melden

Marktplätze verkaufen Software, Daten und Dienste Dritter über die Cloud-Rechnung. Sie können die Beschaffung und die Nachverfolgung von Nutzungsrechten vereinfachen: Wer darf gekaufte Software nutzen? Sie sind keine Warteschlangen für technischen Support. Nutze einen Partner oder ein Beratungsteam des Anbieters, wenn du Fachwissen für die Durchführung einer Migration oder die Organisationsgestaltung brauchst.

AWS Trust and Safety bearbeitet mutmaßlichen Missbrauch aus AWS-Ressourcen, etwa Spam, Scans, Denial-of-Service-Datenverkehr oder Schadsoftware. Jeder kann mutmaßlichen Missbrauch melden; dieser Weg unterscheidet sich von einem Supportfall zu deiner eigenen Anwendung.

Ordne eine konkrete Anfrage dem Dienst zu: „Was hat sich am Dienststatus unseres Abonnements geändert?“ verlangt die personalisierte Dienststatusansicht. „Wer kann uns bei der Durchführung unserer Migration helfen?“ verlangt einen Beratungspartner oder Professional Services. „Wo können wir eine Firewall über unsere Cloud-Rechnung lizenzieren?“ verlangt den Marktplatz. „Welche Ressourcen scheinen nicht ausgelastet zu sein?“ verlangt ein Beratungs- oder Empfehlungstool und anschließend die Prüfung des Workload-Bedarfs durch die verantwortliche Person.

Ein Well-Architected Framework ordnet bewährte Vorgehensweisen für Entwurf und Betrieb einer Workload. Seine Säulen helfen einem Team, ausgewogene Fragen zum System zu stellen. Es dient als Orientierung für Überprüfung und Verbesserung, nicht als Zertifizierung oder Compliance-Standard.

Die Säulen und ihre Bedeutung kennen

AWS hat sechs Säulen: operative Exzellenz, Sicherheit, Zuverlässigkeit, Leistungseffizienz, Kostenoptimierung und Nachhaltigkeit. Azure hat fünf: Zuverlässigkeit, Sicherheit, Kostenoptimierung, operative Exzellenz und Leistungseffizienz. Google Cloud hat sechs: operative Exzellenz; Sicherheit, Datenschutz und Compliance; Zuverlässigkeit; Kostenoptimierung; Leistungsoptimierung und Nachhaltigkeit.

Operative Exzellenz bedeutet, Systeme durch Überwachung, Automatisierung und sichere Änderungen zu betreiben und zu verbessern. Sicherheit schützt Systeme und Daten. Zuverlässigkeit bedeutet, sich von Fehlern zu erholen und die vorgesehenen Funktionen weiterhin zu erfüllen. Leistungseffizienz oder -optimierung bedeutet, den Bedarf mit geeigneten Ressourcen und Skalierung zu decken. Kostenoptimierung sucht die niedrigsten angemessenen Kosten für den benötigten geschäftlichen Nutzen. Nachhaltigkeit berücksichtigt die Umweltauswirkungen der Workload.

Die Kostensäule verbindet Preise mit dem Entwurf: Miss Ausgaben, ordne sie Verantwortlichen zu, wähle geeignete Kaufmodelle und überprüfe die Nutzung. Ein verwalteter Dienst kann die gesamten Betriebskosten senken, auch wenn seine direkte Dienstgebühr die VM-Gebühr einer selbst verwalteten Alternative übersteigt.

Aus Fragen einen Verbesserungsplan machen

Das AWS Well-Architected Tool ist ein kostenloser Konsolendienst, mit dem eine Workload anhand von Fragen zu jeder Säule überprüft wird. Es erfasst Probleme hohen und mittleren Risikos und unterstützt einen Verbesserungsplan. Linsen ergänzen Fragen für Workload-Typen wie Serverless. Azure bietet eine Well-Architected-Review-Bewertung, und Azure Advisor ordnet Empfehlungen nach seinen Säulen.

Bei einer Überprüfung weist ein fehlendes Budget auf ein Kostenproblem hin. Eine Datenbank in einer einzigen Verfügbarkeitszone ist einem Zuverlässigkeitsrisiko ausgesetzt. Fehlende Mehrfaktorauthentifizierung bei Administratorkonten ist ein Sicherheitsproblem. Manuelle Bereitstellungen weisen auf Betriebsrisiken hin. Priorisiere die fehlende MFA und das Ausfallrisiko anhand der Anforderungen und Auswirkungen der Workload; behandle nicht jeden Befund als gleich dringend.

Zielkonflikte erklären

Eine zweite Region kann die Widerstandsfähigkeit verbessern, verursacht aber zusätzliche Infrastruktur-, Replikations- und Übertragungskosten. Ein vollständiges Duplikat verdoppelt ungefähr die Kosten der duplizierten Komponenten. Ein kleineres Standby kostet weniger und braucht üblicherweise länger, um die volle Kapazität wiederherzustellen. Keine der beiden Optionen lässt sich ohne Anforderungen an akzeptable Ausfallzeiten und Wiederherstellung sinnvoll wählen.

Eine Kostensenkung, die eine notwendige Wiederherstellungskopie entfernt, kann die Zuverlässigkeit verschlechtern. Zusätzliche Sicherheitsmaßnahmen können Aufwand und Kosten erhöhen und gleichzeitig das Risiko senken. Ziel ist ein begründetes Gleichgewicht, nicht der höchstmögliche Wert für jede Säule einzeln.

Stell dir einen Dienst vor, der eine mehrstündige Unterbrechung verkraftet, und einen Dienst, der nach wenigen Minuten erhebliche Umsätze verliert. Derselbe teure Entwurf mit einer zweiten Region kann für beide Dienste unterschiedlichen Wert haben. Halte die geschäftliche Anforderung hinter der Entscheidung fest und überprüfe sie, wenn sich Datenverkehr, Architektur oder Kritikalität ändern.

Eine Well-Architected-Überprüfung konzentriert sich auf eine Workload. Ein organisationsweiter Plan für Fähigkeiten, Governance und Migration nutzt ein Cloud Adoption Framework. Verbinde beide Ebenen: Organisationsweite Standards helfen Teams, während Befunde aus Workloads praktische Lücken in diesen Standards aufzeigen.

Ein Cloud Adoption Framework begleitet den Wechsel einer Organisation in die Cloud. Es verbindet Geschäftsziele, Personen, Governance, Sicherheit und Betrieb mit der technischen Arbeit. Eine Well-Architected-Überprüfung fragt, wie eine Workload betrieben werden sollte; die Orientierung zur Cloud-Einführung fragt, wie die Organisation bereit wird, viele Workloads aufzubauen und zu betreiben.

AWS-Perspektiven und -Phasen nutzen

AWS CAF gruppiert Fähigkeiten in sechs Perspektiven. Business, People und Governance konzentrieren sich auf geschäftliche Fähigkeiten. Platform, Security und Operations konzentrieren sich auf technische Fähigkeiten. Ein Business Case gehört zu Business, Fähigkeiten der Mitarbeiter zu People und Cloud-Finanzmanagement zu Governance.

Die Phasen des Weges heißen Envision, Align, Launch und Scale. AWS beschreibt gewünschte Ergebnisse, darunter geringeres Geschäftsrisiko, verbesserte Leistung in Umwelt, Sozialem und Unternehmensführung, höhere Umsätze und verbesserte betriebliche Effizienz. Perspektiven beschreiben Fähigkeitsbereiche; Phasen beschreiben den Weg. Sie beantworten unterschiedliche Fragen zur Strukturierung.

Azure-Aufgaben im Framework einordnen

Die sieben Microsoft-Phasen heißen Strategy, Plan, Ready, Adopt, Govern, Secure und Manage. Strategy legt fest, warum die Cloud eingeführt wird und wie Erfolg zu erkennen ist. Plan bereitet Personen und Workloads vor. Ready richtet die Umgebung ein. Adopt migriert, modernisiert und erstellt Workloads. Govern steuert die Umgebung, Secure schützt sie und Manage betreibt und verbessert sie.

Govern, Secure und Manage laufen neben dem Betrieb der Workloads weiter. Es sind dauerhafte Aufgaben, keine drei Aufgaben, die bis zum Abschluss jeder Migration aufgehoben werden.

Eine Landing Zone ist die vorbereitete Umgebung für Workloads mit Konten oder Abonnements, Identität, Netzwerk, Protokollierung, Richtlinien und Abrechnungsstruktur. Azure Landing Zones unterstützen Ready; AWS Control Tower hilft, eine Umgebung mit mehreren Konten und Kontrollen einzurichten. Bereite diese Grundlagen vor, bevor Teams Workloads in einer Umgebung ohne Steuerung bereitstellen.

Den Google-Cloud-Reifegrad bewerten

Das Google Cloud Adoption Framework nutzt vier Themen: Learn, Lead, Scale und Secure. Es bewertet jedes anhand der taktischen, strategischen und transformativen Phase auf der Cloud Maturity Scale. Taktische Arbeit konzentriert sich auf einzelne Workloads ohne langfristigen Plan. Strategische Arbeit bereitet auf künftige Bedürfnisse vor. Transformative Organisationen arbeiten reibungslos und konzentrieren sich auf Innovation und Daten.

Ein Team kann bei Führung oder Fähigkeiten Verbesserungsbedarf haben, selbst wenn seine technische Plattform stark ist. Bewerte die Themen, um zu erkennen, welche organisatorische Fähigkeit die Einführung bremst; der Kauf weiterer Dienste liefert weder geschulte Personen noch einen gemeinsamen Plan.

Konkrete Aufgaben zuordnen, ohne Begriffe zu vermischen

Für ein Handelsunternehmen gehört „Rechenzentrumskosten in drei Jahren um 20 % senken“ zu Microsoft Strategy und zur AWS-Perspektive Business. „40 Mitarbeiter schulen“ passt zu Microsoft Plan und AWS People. „Konten, Netzwerk und Richtlinien vorbereiten“ passt zu Microsoft Ready und AWS Platform. Die Migration von 30 Anwendungen passt zu Microsoft Adopt; Tags und Budgets passen zu Govern und AWS Governance. Die Überwachung laufender Dienste passt zu Microsoft Manage und AWS Operations.

Nutze bei der Erklärung der Zuordnung die jeweiligen Bezeichnungen des Anbieters. AWS hat keine Phase namens Ready, und Googles Thema Learn ist keine Azure-Phase. Passe die Orientierung an die Ziele der Organisation an, ordne die Arbeit nach Abhängigkeiten und halte Governance und Betrieb auch nach Ankunft der ersten Workloads aktiv.