Kostenkontrolle mit Azure Billing API (Preview)


Ganz neu und frisch gibt es seit wenigen Tagen eine Azure Billing API. Enterprise Agreement Kunden haben ja eine eigene Verwaltung ihrer Subscriptions im Microsoft Azure - EA Portal und eine eigne Schnittstelle. Alle anderen Azure Subscriptions und deren Verwendung und die angefallenen Kosten können nun seit kurzem mit der neuen Azure Billing API (Preview) abgefragt werden.

Wozu?

Das ist besonders für kleine Unternehmen sinnvoll, die kein Azure EA besitzen, aber dennoch mehrere Azure Subscriptions verwenden. So werden etwa oft mehrere eigene Unternehmens-MSDN Abos von unterschiedlichen Mitarbeitern verwendet, da macht es Sinn die “usage” und das “billing” automatisiert (oder in weiterer Folge gesammelt) abzufragen.

Code-Beispiele

Auf GitHub gibt es bereits drei Code Samples von Bryan Lamos dafür, nämlich die ConsoleApp-Billing-Usage, die ConsoleApp-Billing-RateCard und WebApp-Billing-MultiTenant: https://github.com/Azure/BillingCodeSamples

23

Hier die Beschreibung der Code Samples von GitHub:

Microsoft liefert die Daten über die Verwendung über den Provider "providers/Microsoft.Commerce/UsageAggregates" und die Kostendaten über den Provider "providers/Microsoft.Commerce/RateCard" (siehe auch unten) – daher auch die Benennung der Beispiele nach diesen Endpunkten mit “Usage” und “RateCard”.

Start mit Authentifizierung

Ich habe zunächst einmal das Beispiel ConsoleApp-Billing-Usage angesehen. Hier müssen natürlich zuerst die eigenen Daten und die Berechtigungen gesetzt werden. Das erste Compile lädt die erforderlichen NuGet Packages nach und wirft gleich einen Fehler mit dem Hinweis im Code, dass die AppSettings korrekt eingetragen werden müssen:

#error Please update the appSettings section in app.config, then remove this statement

Danke für den Hinweis, also die Zeile im Code entfernen, die Settings wollte ich soundso gerade anpassen…

24

Das Sample verwendet natürlich die ADAL Bibliotheken zur Authentifizierung mit OAuth und benötigt ein AD (TenantDomain), eine native App (ClientID) darin und eine Azure Subscription ID (SubscriptionID). Das Gute dabei ist, dass eine App in einem beliebigen AD ausreicht, um mehrere Azure Subscriptions abzufragen (natürlich muss das verwendete Konto darin berechtigt, sprich zB. Co-Admin, sein).
Die Anleitung zur Inbetriebnahme ist übrigens auf GitHub im Sample zu finden.

Um es kurz zu machen, so funktionierts: Im Azure Portal werden aus den “Settings” die SubscriptionID und das Default-Directory benötigt. In diesem Beispiel wird die Subscription mit dem AD “mvpdemo2014.onmicrosoft.com” verwaltet.

25

In diesem AD (mvpdemo2014*…) wird eine neue “native” App angelegt. Wichtig hierbei ist, dass die “ADALRedirectURL” wie im Code-Beispiel in den AppSettings verwendet wird. Bei uns lautet sie “https://localhost/”.

26

Zum Abschluss sind noch die erforderlichen Permissions für die App zu setzen, wie hier - alles auf einen Blick:

27

Diese Daten werden nun in die AppSettings eingetragen (hier nur der Beginn der IDs… bitte die eigenen verwenden).

28

Das war die Konfiguration. Nun geht es mit dem Programm weiter.

Die Abfrage der Daten

Die Abfrage erfolgt durch den REST Endpoint und Parameter. Für die “Usage” sieht das beispielsweise wie folgt aus:

https://management.azure.com/subscriptions/<SubscriptionID>/providers/Microsoft.Commerce/UsageAggregates?api-version=2015-06-01-preview&reportedstartTime=2015-03-01+00%3a00%3a00Z&reportedEndTime=2015-05-18+00%3a00%3a00Z

Eine Liste der Parameter und der Bedeutung für Usage sind in der API Documentation zu finden:
Get price and metadata information for resources used in an Azure subscription

Wenn man das Sample ConsoleApp-Billing-RateCard ansieht (und ev. gleich in das Usage-Sample integriert), sieht man, dass es nach demselben Prinzip funktioniert. Hier wollen wir die Daten einer MSDN-Subscription in Euro und mit deutschen Bezeichnungen:

https://management.azure.com/subscriptions/<SubscriptionID>/providers/Microsoft.Commerce/RateCard?api-version=2015-06-01-preview&$filter=OfferDurableId eq 'MS-AZR-0061P' and Currency eq 'EUR' and Locale eq 'de-DE' and RegionInfo eq 'DE'

Die Namen der Subscription (hier: MS-AZR-0061P) sind in Microsoft Azure Offer Details ersichtlich.

29

Eine Liste der Parameter und der Bedeutung für die RateCard sind in der API Documentation zu finden:
Resource RateCard (Preview)

Das bedeutet ggf. die Parameter nach eigenen Erfordernissen anpassen.

Los gehts

Wenn nun die App mit F5 gestartet wird, folgt zunächst eine SignIn-Box. Hier mit einem berechtigten Azure-Konto und der App “azurebillingdemo” (unserer native App im AD) anmelden.

30

Beim ersten Start müssen noch die App-Berechtigungen (Consent) erteilt werden:

31

Die Daten

Wenns lauft, dann laufts. So sieht dann etwa die “usageResponse” im JSON Format aus. Sie zeigt mehrere Values mit ihren verschiedenen properties – eben die verwendete Benutzung einzelner Cloud-Dienste.

32

Genauso sieht es mit den Kostendaten “rateCardResponse” aus:

33

Diese Daten gehören dann wohl in eine Datenbank oder in meinem Beispiel zu mindestens in eine CSV-Datei zur Weiterverarbeitung geschrieben. Man sieht aber bereits, was hier geliefert wird.

Jede “Usage”-Zeile besitzt eine “MeterId”, das ist eine GUID, etwa wie hier (teilweise):

34

Diese findet sich auch in der “RateCard” wieder.

35

In diesem Beispiel wären also die Kosten für “0.016129” mal “DB Units” genau “7.439 Euro” im Zeitraum zwischen usageStartTime und usageEndTime. Und so weiter.

Die Felder und deren Bedeutung sind in Get price and metadata information for resources used in an Azure subscription im Teil “JSON Element Definitions” dokumentiert:

36

Das Schöne an der neuen Azure Billing API: Die Abfragen funktionieren sehr schnell (ganz im Gegensatz zum elendslangsamen manuellen Herunterladen dieser Rechnungsdaten im Azure Billing Portal).

Mein derzeitiges Handicap: Ich habe es noch nicht geschafft, hier dieselben Daten, sprich dieselben Kosten, zu erhalten, die ich auch im Azure-Billing Portal angezeigt bekomme. Bei der Fülle an Daten ist das auch recht aufwändig und ich werde hier noch etwas Energie investieren müssen. Oder es liegt an der Preview. Oder an meinem Verständnis der Rechnungen. Das wird also noch etwas dauern.

Aber, wie heißt es so schön: You get the idea. Zwinkerndes Smiley

Mehr

Es gibt auch bereits fertige Produkte, welche diese (Preview) APIs nutzen: Cloudyn und Cloud Cruiser. Die sehen bereits recht vielversprechend aus, diese möchte ich mir auch noch näher ansehen.

Danke an Oliver Michalski für den API-Tipp im Azure Community Deutschland Blog!

Ich denke, die Azure Billing API wird Anwendern und Unternehmen sehr helfen die lästigen manuelle Tätigkeiten im Azure Portal durch ein nettes kleines Tool und entsprechende Auswertung dazu zu ersetzen. Endlich gibt es eine Azure Billing API – wenn auch noch in Preview!


Skip to main content