Einheit 2.4: Kostenarchitektur und FinOps

Einführung

Die Cloud-Kosten auf IONOS CLOUD sind kein Abrechnungsproblem, das nachträglich gelöst wird; sie sind eine architektonische Eigenschaft, die bereits im Entwurfsstadium festgelegt wird, wenn Sie eine Compute-Klasse, eine Storage-Ebene, eine Skalierungsstrategie und eine Commitment-Laufzeit wählen. Jeder dieser Faktoren ist ein Hebel, und sie unterscheiden sich erheblich in ihrer Wirkung: Die Wahl der Compute-Kontenanz kann die Rechnung stärker beeinflussen als alle Dashboard-Einstellungen zusammen. FinOps ist hier daher vor allem Architektur, ergänzt durch eine schlanke operative Schicht für Zuweisung und Alerting. Diese Einheit behandelt die Hebel in Reihenfolge ihrer Wirkung, erläutert, wie Savings Plans Ausgaben korrekt commiten, und schließt mit dem Aufbau des einen gut dokumentierten Guardrails, eines Kosten-Alerts, im Data Center Designer.

1. Compute Contention: Der erste Kostentreiber

Die größte einzelne Kostenentscheidung besteht darin, wie eine Workload die physische CPU nutzt. Compute Engine bietet zwei CPU-Nutzungsklassen: Dedicated Core Server, bei denen der Kern der VM exklusiv zur Verfügung steht, und vCPU Server, bei denen der Kern mit anderen Mietern geteilt wird. Geteilte Kerne sind günstiger und eignen sich für burstige, latenztolerante oder Nicht-Produktions-Workloads. Exklusive Kerne kosten mehr und sind dort richtig, wo die Leistung vorhersehbar sein muss oder wo Isolation an sich eine Anforderung darstellt, was bei einem regulierten Umgebungsbestand häufig der Fall ist.

Hier wird ein bewusster Over-Provisioning zu einer gerechtfertigten Kontrollkostenstelle, statt als Verschwendung zu gelten. Für die im Geltungsbereich liegenden, regulierten Hosts von FinCorp sind Single-Tenancy und vorhersehbare Leistung Compliance- und Risikoinputs. Die Bezahlung dedizierter Kerne (und die Bereitstellung von Pufferkapazität über der gemessenen Basislinie) kauft Isolation und Stabilität, die durch eine Einsparung bei geteilten Kernen untergraben würden. Die Disziplin besteht darin, bewusst vorzugehen: Hosts, die Compliance- oder Leistungspflichten tragen, werden überdimensioniert, und überall dort, wo die Workload Kontention toleriert, werden geteilte Kerne verwendet. Beachten Sie auch, dass VM Auto Scaling neue Replikate aus einer Replikatvorlage zur Designzeit erzeugt. Eine Schicht, die automatisch skalieren muss, hat daher ihre Replikate-Compute-Form und damit ihre Replikate-Kosten zur Designzeit festgelegt, wodurch die Elastizitätsentscheidung in die Kostenentscheidung einfließt.

2. Speicher-Tiering nach Zugriffsmuster

Die Speicherkosten werden dadurch festgelegt, dass das Tier an das Zugriffsmuster angepasst wird, und die drei Block-Tiers weisen wesentlich unterschiedliche Preisniveaus auf. Die veröffentlichten Preise pro GB und Monat lauten:

Zwei Einschränkungen beeinflussen die Wahl neben dem Preis. Erstens: die Leistungsgrenze von SSD. Sowohl SSD Standard- als auch SSD Premium-Volumes erfordern eine Mindestgröße von 100 GB, um die volle Leistung zu erreichen. Ein zu kleines SSD-Volume zahlt daher SSD-Preise, ohne SSD-Leistung zu liefern. Dies ist eine häufige und vermeidbare Verschwendung bei Datenbankdisks. Zweitens: Block-Speicher ist nicht der richtige Ort für Massen- oder Archivdaten. Object Storage ist das geeignete Tier für Sicherungen, Audit-Archive, Datensätze und kalte Daten. Hier befindet sich auch das Object-Lock-Archiv aus Einheit 2.3. Das Muster besteht darin, heiße, latenzsensitive Daten auf entsprechend dimensionierten SSDs, Kapazitätsdaten auf HDD und alles, was massenhaft oder archiviert ist, auf Object Storage zu platzieren.

3. Scale-Up im Vergleich zu Cache-basiertem Scale-Out für die Daten-Ebene

Die Daten-Ebene weist ein charakteristisches Kostenprofil auf, da die Plattform keine Lese-Replikate bereitstellt (Einheit 1.3 und Modul 5). Die beiden Ansätze zur Bewältigung steigender Lese-Lasten haben sehr unterschiedliche wirtschaftliche Auswirkungen. Scale-Up bedeutet, eine größere Datenbank-Instanz zu beschaffen, was zu einer vorhersehbaren, dauerhaft laufenden Kostensteigerung führt und schließlich an Grenzen stößt. Scale-Out für Lesezugriffe bedeutet, einen In-Memory-Cache vor der relationalen Ebene zu positionieren und den Lese-Verkehr dort abzufangen. Dies ist in der Regel deutlich günstiger pro abgewickeltem Lesezugriff und schützt die Datenbank davor, ausschließlich zur Bewältigung von Lese-Spitzen überdimensioniert zu werden. Für die meisten leseintensiven Workloads von FinCorp kostet eine richtig dimensionierte Datenbank plus eine Cache-Ebene weniger als eine dauerhaft hochskalierte Datenbank. Zudem ist dies der einzige horizontale Pfad für das Skalieren von Lesezugriffen, den die Plattform bietet. Die zentrale Kostenlektion lautet: Die Datenbank sollte für ihre Schreib- und Arbeitsbereichs-Bedarfe dimensioniert werden, während der Cache, nicht eine größere Instanz, das Lese-Wachstum absorbiert.

4. Savings Plans: Die Mindestverpflichtung korrekt festlegen

Ein Savings Plan ist eine ressourcenbasierte Verpflichtung, die einen festen Vertragszeitraum gegen einen Rabatt auf Compute Engine Dedicated Core Server, Managed Kubernetes Dedicated Core Node Pools und Nextcloud Workspace eintauscht. Er deckt die Dimensionen Kerne und RAM (GB) ab. Die Wirtschaftlichkeit ist präzise:

Mehrere Regeln machen dies nur dann sicher, wenn Sie sie einhalten. Ein Plan reserviert Abrechnungsbeträge, nicht physische Kapazität, und blockiert daher niemals die Bereitstellung. Überschreitungen werden sauber behandelt: Der Verbrauch über der vertraglich festgelegten Menge hinaus wird zum regulären PAYG-Tarif abgerechnet, sodass eine Überverpflichtung das einzige echte Risiko darstellt. Wenn mehrere Pläne dasselbe Produkt abdecken, werden sie chronologisch nach Erstellung (älteste zuerst) angewendet. Innerhalb eines Produkts gilt der Rabatt für die älteste VM zuerst. Die AMD Opteron CPU Familie ist ausgeschlossen. Ein Plan wird nicht automatisch verlängert, und nur ein Vertragsinhaber kann einen Plan erwerben.

Die wichtigste operative Tatsache ist, dass ein Savings Plan nach der Aktivierung nicht bearbeitet werden kann. Das einzige bearbeitbare Feld ist der Planname, und der Plan kann nach dem Kauf nicht storniert werden. Dadurch wird die Verpflichtung zu einer Entscheidung ohne Rückweg, und sie bestimmt die Disziplin: Die Mindestverpflichtung festlegen. Verpflichten Sie sich nur für die stabile Grundlast, die Sie mit Sicherheit über die gesamte Vertragslaufzeit betreiben werden, und nehmen Sie den PAYG-Überschuss für alles darüber hinaus. Verlängern Sie die Laufzeit nur für Kapazität, von der Sie zuversichtlich sind, dass sie drei Jahre bestehen bleibt. Eine optimistische Verpflichtung auf den Spitzenverbrauch führt zu Ausgaben, die Sie nicht nach unten korrigieren können. Die Mindestverpflichtung sichert den Rabatt auf garantierten Verbrauch, während variable Lasten auf dem flexiblen PAYG-Modell verbleiben.

5. Allokation, Showback und Chargeback

Die Kostenallokation baut auf der Struktur aus Einheit 2.1 auf. Da jedes VDC bereits einen eigenen Abschnitt auf der monatlichen Rechnung erzeugt, ist die Hierarchie aus Vertrag und VDC die primäre Allokationsachse: Ein Vertrag fasst einen Bereich für Governance und Abrechnung zusammen, und die VDCs innerhalb dieses Bereichs trennen Umgebungen oder Projekte in separate Rechnungszeilen. Die Ansicht „Cost & Usage“ im DCD ist die Analyseebene hierfür, und eine Cost & Usage API steht zur Verfügung, um Abrechnungsworkflows programmgesteuert zu versorgen.

Die Allokation unterstützt zwei Betriebsmodelle. Showback berichtet jedem Team oder Projekt seinen Anteil an den Kosten, um Transparenz und Verantwortlichkeit sicherzustellen, ohne Geldbeträge zu verschieben. Chargeback stellt die Kosten tatsächlich der verbrauchenden Einheit in Rechnung. Showback ist der leichtgewichtigere Einstiegspunkt und reicht in der Regel aus, um das Verhalten zu ändern; Chargeback fügt finanzielle Durchsetzungsfunktionen hinzu, erfordert jedoch mehr Abrechnungstechnik. Für FinCorp führt die Zuordnung von VDCs zu Projekten, sodass jedes auf seiner eigenen Rechnungszeile landet, sofort zu einem sauberen Showback, wobei Chargeback später hinzugefügt werden kann, wenn es die Finanzabteilung erfordert. (Betrachten Sie das Dashboard und die Allokationsnavigation als Analyseschicht; der unten beschriebene Aufbau ist der Guardrail für Kostenalarme, der gut dokumentierte Erstellpfad.)

DCD-Implementierung: Schritt-für-Schritt-Anleitung

Sie erstellen einen Kostenalarm, der einen Empfänger per E-Mail benachrichtigt, wenn die Vertragsausgaben einen Budgetschwellenwert überschreiten. Dies ist der gut dokumentierte Kostenbau; er ist die operative Schutzmaßnahme, die die oben genannten architektonischen Hebel stützt. Voraussetzung ist der Zugriff als Vertragsinhaber oder Administrator, da nur diese Rollen Kostenalarme erstellen können. Beachten Sie, dass der Alarm auf Vertragsebene eingerichtet wird (ein Betrag und eine E-Mail-Adresse). Die Zuweisung über VDCs hinweg ist eine Berichtsanfrage, die in der Ansicht „Cost & Usage“ behandelt wird, nicht im Alarm selbst.

Bauziel: Erstellen eines Kostenalarms für einen Budgetschwellenwert.

Schritte (im Data Center Designer):

1. Gehen Sie zu Menü > Management > Cost alert. Das Fenster „Cost alert“ wird geöffnet; in dieser Ansicht werden auch vorhandene Alarme aufgelistet.
2. Wählen Sie Create cost alert.
3. Geben Sie im Dialog den amount (den Ausgabenschwellenwert für den Vertrag) und die E-Mail-Adresse ein, die benachrichtigt werden soll.
4. Wählen Sie Create cost alert, um zu bestätigen. Der Alarm ist jetzt aktiv und sendet eine E-Mail an den Empfänger, sobald die Vertragsausgaben den Schwellenwert überschreiten.

Häufige Fehler:

• Die Erwartung, dass der Alarm die Ausgaben begrenzt oder stoppt. Er benachrichtigt nur; er ist ein Auslöser, keine harte Budgetdurchsetzung. Die Ausgaben setzen sich über den Schwellenwert hinaus fort.
• Die Einrichtung pro VDC. Der Kostenalarm ist auf Vertragsebene (Betrag plus E-Mail); für die Analyse und Zuweisung pro VDC die Ansicht „Cost & Usage“ verwenden.
• Die Abhängigkeit von Alarmen anstelle von Architektur. Der Alarm erfasst Abweichungen; die Entscheidungen zur Compute-Klasse, zum Storage-Tier und zum Savings Plan bestimmen tatsächlich die Rechnung.
• Die Ausrichtung des Alarms auf ein persönliches Postfach. Senden Sie ihn an eine überwachte Adresse für Finanzen oder Betrieb, damit die Benachrichtigung gesehen und bearbeitet wird.

Architektur-Muster

Eine verteidigungsfähige Kostenarchitektur von FinCorp gliedert die Hebel nach ihrer Wirkung. In der untersten Ebene wird die Compute-Klasse pro Stufe ausgewählt: dedizierte Kerne für die regulierten und automatisch skalierenden Stufen im Geltungsbereich (mit bewusstem Puffer als gerechtfertigte Kontrollkosten), geteilte Kerne für tolerante und Nicht-Produktions-Workloads. Der Speicher wird nach dem Zugriffsmuster gestaffelt, wobei SSD-Volumes auf oder über der Untergrenze von 100 GB gehalten werden und Massen- bzw. Archivdaten in Object Storage abgelegt werden. Die Datenschicht wird für Schreibvorgänge und den Arbeitsbereich dimensioniert, wobei ein In-Memory-Cache das Lese-Wachstum absorbiert, anstatt eine überdimensionierte Datenbank einzusetzen. Darüber hinaus sichert ein Savings Plan nur den stabilen Grundbedarf an dedizierten Kernen und RAM über eine Laufzeit, die der tatsächlichen Persistenz entspricht, während der darüberliegende Überschuss nach PAYG abgerechnet wird. Auf der obersten Ebene ordnet die Zuordnung VDCs Projekten zu, um Showback zu ermöglichen, und eine kostenbezogene Warnung auf Vertragsebene dient als Auslöser bei Abweichungen. Als konkretes Beispiel: Eine Stufe mit stabilen 32 dedizierten Kernen kostet bei PAYG etwa 1,28 EUR pro Stunde (32 x 0,04). Die Festlegung dieses Grundbedarfs in einem 3-Jahres-Plan senkt die Kernkosten auf etwa 0,77 EUR pro Stunde (32 x 0,024), was einer Reduktion von 40 % auf der garantierten Baseline entspricht, während jeder Anstieg über 32 Kerne hinaus weiterhin nach PAYG abgerechnet wird.

Zusammenfassung

Die Cloud-Kosten auf IONOS CLOUD werden architektonisch gestaltet und nicht lediglich überwacht. Die Compute-Kontenzzklasse ist der größte Hebel, wobei eine bewusste Überdimensionierung der betroffenen Hosts als Kontrollkosten gerechtfertigt wird; der Speicher wird gemäß dem Zugriffsmuster innerhalb des SSD-Leistungsniveaus gestaffelt; und die Datenebene skaliert Lesezugriffe über einen Cache, anstatt eine überdimensionierte Instanz zu verwenden. Savings Plans sichern Festpreisrabatte von 15 % (1 Jahr) und 40 % (3 Jahre) für dedizierte Kerne und RAM, können nach der Aktivierung jedoch nicht bearbeitet werden, was es erforderlich macht, nur den sicheren Mindestbestand zu reservieren und den PAYG-Überlauf zu nutzen. Die Allokation folgt der Vertrags- und VDC-Struktur für Showback oder Chargeback, und eine kostenspezifische Warnung auf Vertragsebene stellt die im DCD integrierte operative Schutzschranke dar.

Wichtige Punkte:

• Compute-Kontenz ist der erste Kosteneinflussfaktor: geteilte Kerne sind günstiger, exklusive (dedizierte) Kerne kaufen Vorhersehbarkeit und Isolation; Auto-Scaling legt die Compute-Form jedes Replikats zum Designzeitpunkt fest und integriert Elastizität in die Kostenentscheidung.
• Staffeln Sie den Speicher nach dem Zugriffsmuster: HDD 0,04, SSD Standard 0,07, SSD Premium 0,15 EUR/GB/Monat; halten Sie SSD-Volumes auf oder über dem 100-GB-Vollleistungsniveau; lagern Sie Massen- und Archivdaten in Object Storage aus.
• Skalieren Sie Lesezugriffe der Datenebene mit einem In-Memory-Cache, nicht mit einer überdimensionierten Datenbank, da keine Lese-Replikate vorhanden sind.
• Savings Plans bieten 15 % (1 Jahr) und 40 % (3 Jahre) Rabatt auf dedizierte Kerne und RAM, Überlauf wird nach PAYG abgerechnet, Pläne werden nach dem ältesten zuerst angewendet und können nach der Aktivierung nicht bearbeitet werden, daher nur den sicheren Mindestbestand reservieren.
• Allokation nach Vertrag und VDC (jedes VDC wird bereits als eigene Zeile abgerechnet); Auswahl zwischen Showback oder Chargeback; eine kostenspezifische Warnung auf Vertragsebene (Betrag plus E-Mail) ist die Schutzschranke zum Build-Zeitpunkt und sendet nur Benachrichtigungen, begrenzt jedoch die Ausgaben nicht.

Wichtige Begriffe:

• CPU-Nutzungsklasse: Ob die Kerne eines Servers exklusiv (Dedicated Core) oder geteilt (vCPU) sind; der primäre Hebel für Compute-Kosten und Leistung.
• Savings Plan: Eine ressourcenbasierte Abrechnungsverpflichtung über 1 oder 3 Jahre für dedizierte Kerne und RAM, mit PAYG-Überlauf, nicht bearbeitbar nach der Aktivierung, nur vom Vertragsinhaber kaufbar.
• Showback / Chargeback: Berichterstattung des Kostenanteils eines Teams zur Rechenschaftslegung (Showback) im Gegensatz zur tatsächlichen Rückrechnung der Kosten an das Team (Chargeback).
• Kostenspezifische Warnung: Eine Schwelle auf Vertragsebene (Betrag plus E-Mail), die bei Überschreitung der Ausgaben benachrichtigt; sie warnt, begrenzt jedoch nicht.