Läuft Ihr Azure über einen CSP-Partner, weist Ihr Tenant jede Nutzung mit CHF 0 aus, die eine Reservation oder ein Savings Plan abdeckt. Die verteilte Sicht rechnen Sie aus den Rohdaten selbst zurück, und dafür brauchen Sie eine Handvoll Felder.
Der erste Teil dieser Serie hat die zwei Metriken auseinandergenommen: Actual Cost passt zur Rechnung, Amortized Cost erklärt den Verbrauch einer Ressource. Dieser Teil zeigt, woher die zweite Zahl kommt, wenn Azure sie nicht liefert.
1. Was Ihr Tenant zeigt, und zu welchen Preisen
Microsoft stellt Cost Management im Kunden-Tenant erst bereit, wenn die Cost-Visibility-Policy für Ihren Tenant eingeschaltet ist. Standardmässig steht sie auf Nein.
Ist sie eingeschaltet, rechnet Azure Ihre Nutzung zu Pay-as-you-go-Preisen. Das sind die Preise aus dem Azure Pricing Calculator, ohne die Konditionen aus Ihrem Vertrag.
Für Commitments gilt eine zweite Einschränkung. Die abgedeckte Nutzung erscheint mit CHF 0, in der Actual-Sicht wie in der Amortized-Sicht. Der Kauf erscheint als eigene Position, auf die nutzenden Ressourcen verteilt wird er nie.
Suchen Sie dafür keinen Schalter. Die Amortized-Sicht gibt es im Kunden-Tenant als Umschalter, aber ohne Inhalt.
2. Die Begriffe, mit denen Sie arbeiten
Alles Nötige steckt in den Cost Details, dem Zeilenexport hinter Cost Analysis. Eine Zeile je Tag, Ressource und Meter.
Öffnen Sie einen Monat, in dem eine Reservation läuft, treffen Sie auf drei Sorten von Zeilen. Den Kauf am Kaufdatum, die abgedeckte Nutzung an jedem Tag, und für den ungenutzten Anteil keine Zeile.
| Begriff | Wo er steht | Was er bedeutet |
|---|---|---|
| ChargeType | jede Zeile | Purchase für den Kauf, Usage für Nutzung. UnusedReservation und UnusedSavingsPlan führt Microsoft nur in der Amortized-Sicht, also nicht in Ihrer. |
| PricingModel | jede Zeile | Reservation oder SavingsPlan auf allen Zeilen, die zu einem Commitment gehören, sonst OnDemand. |
| Quantity | Kauf und Nutzung | Auf der Kaufzeile die reservierte Menge, auf der Nutzungszeile die gelaufenen Stunden. |
| EffectivePrice | Nutzung | 0, sobald ein Commitment die Zeile deckt. Das ist Ihr Erkennungsmerkmal. |
| UnitPrice | Nutzung | Der On-Demand-Preis aus Ihrem Price Sheet, also die Bewertung der Stunde ohne Benefit. Kein Betrag, der verrechnet wurde. |
| Ratio | AdditionalInfo | Instance Size Flexibility Ratio, der relative Fussabdruck einer SKU in ihrer Flexibilitätsgruppe. Relative Einheiten, keine Preise. |
| Term, Frequency | Kauf | Laufzeit und Zahlungsrhythmus. Beide bestimmen, über wie viele Tage Sie teilen. |
| ReservationId, BenefitId | Kauf und Nutzung | Die Kennung des Commitments. Reservations tragen ReservationId, Savings Plans BenefitId. |
Die Ratio verdient einen eigenen Absatz, weil sie die Umrechnung zwischen Kauf und Verbrauch macht. Eine Reservation für eine DS4_v2 mit der Ratio 8 deckt acht DS1_v2 mit Ratio 1, oder zwei DS2_v2 und eine DS3_v2, weil 2 plus 2 plus 4 wieder 8 ergibt. Läuft stattdessen eine DS5_v2 mit Ratio 16, deckt die Reservation die halben Compute-Kosten dieser Maschine.
Zwei Fallen dabei. Die rohen Werte beginnen nicht bei 1 für die kleinste SKU, die BS-Serie startet bei 0.25 und die Ddsv5-Serie bei 2. Und Sizes aus einer anderen Flexibilitätsgruppe teilen den Benefit nicht, DSv2 Series High Memory gehört nicht zur DSv2 Series.
Zwei Dinge müssen am Export stimmen: Tagesgranularität, und verrechnete Preise in Rechnungswährung.
3. Wie der Tagesanteil auf die Ressourcen kommt
Gerechnet wird je Commitment und je Tag. Amortisierung ist täglich, und deshalb trägt ein Februar 28 Anteile und ein März 31.
- Den Tagesanteil bilden. Kaufbetrag geteilt durch die Tage der Laufzeit. CHF 12'000 über zwölf Monate ergeben CHF 32.88 pro Tag. Zahlen Sie monatlich, nehmen Sie die Zahlung des Monats geteilt durch dessen Tage.
- Das Gewicht je Zeile bestimmen. Quantity mal Ratio, für jede abgedeckte Zeile des Tages. Die Ratio brauchen Sie, weil eine Reservation innerhalb ihrer Flexibilitätsgruppe auch andere Instanzgrössen abdeckt und Stunden verschiedener Grössen deshalb nicht vergleichbar sind.
- Gegen die reservierte Menge rechnen. Dasselbe Gewicht bilden Sie für die Menge aus der Kaufzeile. Das ergibt den Massstab des Tages, und jede Ressource bekommt den Anteil am Tagesanteil, der ihrem Gewicht entspricht.
- Den Rest stehen lassen. Was nach der Verteilung übrig bleibt, hat niemand gezogen. Dieser Betrag entspricht dem, was Microsoft im EA und im MCA als UnusedReservation ausweist.
Bei Savings Plans gibt es keine Ratio. Dort verbraucht die Nutzung ein Commitment in Franken, deshalb bilden Sie das Gewicht aus Quantity und UnitPrice.
Wie das aussieht, zeigt ein Märztag aus dem Beispiel des ersten Teils. Die Reservation deckt 24 Stunden einer D4as v5, und zwei Maschinen greifen darauf zu.
| Zeile | Stunden (Quantity) | Ratio (AdditionalInfo) | Gewicht (Stunden × Ratio) | Anteil am Massstab | Vom Tagesanteil |
|---|---|---|---|---|---|
| prod-vm-01, D4as v5 | 9.6 | 4 | 38.4 | 40% | 13.15 |
| prod-vm-02, D2as v5 | 14.4 | 2 | 28.8 | 30% | 9.86 |
| Ungenutzt | 7.2 | 4 | 28.8 | 30% | 9.86 |
| Reservierte Menge, der Massstab | 24.0 | 4 | 96.0 | 100% | 32.88 |
prod-vm-02 läuft länger und zieht trotzdem weniger, weil sie mit der halben Ratio in die Rechnung geht. Der Massstab ist die reservierte Menge und nicht die gezogene, und genau deshalb bleibt der ungenutzte Anteil als eigene Zeile stehen.
Über den ganzen März sind das CHF 713 auf Ressourcen und CHF 306 ohne Owner. Über die Laufzeit summieren sich alle Tage auf CHF 12'000, und diese Kontrollrechnung ist der einzige Beweis, dass die Verteilung stimmt.
4. Was ohne diese Verteilung passiert, und wo sie an Grenzen stösst
Ohne die Rückrechnung bleiben zwei Wege, und beide gehen schief.
Wer die Zahlen aus dem Tenant verrechnet, verrechnet Pay-as-you-go-Preise. Ihre Abteilungen zahlen zusammen mehr, als auf der Rechnung steht, und der Rabatt aus dem Commitment landet auf keinem Kostenträger.
Wer den Kauf im Kaufmonat verrechnet, belastet eine einzelne Subscription mit CHF 12'000. Die Abteilung, die im März 70% der Reservation zieht, erscheint in diesem Monat mit CHF 0.
Fünf Grenzen sollten Sie kennen, bevor Sie die Rechnung aufsetzen:
- Microsoft ändert die Ratios gelegentlich. Die Preise bleiben gleich, die Coverage nicht, und eine fest verdrahtete Ratio rechnet danach still falsch.
- Der klassische CSP-Offer liefert diese Daten nicht. Nötig sind Subscriptions im Azure plan auf dem Microsoft Customer Agreement.
- Marketplace-Käufe werden nicht amortisiert. Ausnahme sind Virtual-Machine-Software-Reservations aus dem Marketplace.
- Die Monatsbeträge sind nicht gleich. Ein Februar trägt 28 Tagesanteile, ein März 31, und eine Verteilung auf zwölf gleiche Monate ist falsch.
- Gerechnet haben wir hier nur Virtual Machines. Andere Ressourcen verhalten sich anders, Cosmos DB etwa rechnet in RU/s über Accounts und Regionen hinweg und kennt keine SKU-Ratio. Jede Ressourcenart braucht ihre eigene Prüfung, bevor Sie sie verrechnen.
5. Warum Sie diese Rechnung nicht selbst führen müssen
Chargeback ist im CSP aus drei Gründen mühsamer als im Enterprise Agreement. Die verteilte Sicht fehlt im Tenant, die Preise darin sind nicht die verrechneten, und Käufe hängen nicht an der Ressourcenhierarchie, an der Ihre Kostenstellen hängen.
Dazu kommt der Umfang. Die Rechnung aus Kapitel 3 läuft je Commitment, je Tag und je Ressource, und bei einem Dutzend Commitments über mehrere Subscriptions ist das keine Excel-Aufgabe mehr.
Diesen Teil übernimmt die Zation Platform. Sie führt die Abrechnung aus CSP, MCA und EA zu einer Kostenquelle zusammen und rollt die Monate nach Service, Region, Kostenart und Resource Group auf. Reservations und Savings Plans kommen mit Inventar und Utilization dazu.
Damit gehört Zation zu den wenigen CSP-Partnern, die ihren Kunden die Datengrundlage für ein Chargeback überhaupt verfügbar machen.
Wie unsere Cost Engine daraus Showback und Chargeback macht, nehmen wir im nächsten Teil dieser Serie auseinander.