Azure Container Apps Kosten entstehen im Consumption-Plan aus vCPU-Sekunden und GiB-Sekunden je laufender Replik, zu einem aktiven oder einem reduzierten Leerlaufpreis, plus HTTP-Anfragen von außerhalb der Umgebung, und im Dedicated-Plan aus Workload-Profil-Instanzen je Stunde plus einer Verwaltungsgebühr; Container Instances berechnen vCPU und GB je Sekunde einer Containergruppe, und die Container Registry kostet einen Tagessatz je Stufe plus Speicher über dem Inklusivvolumen. Auf der Rechnung dominieren bei Container Apps die Repliken, die durch eine Mindestreplikzahl nie auf null skalieren, bei der Registry der Premium-Tagessatz multipliziert mit den replizierten Regionen.
Preisdimensionen
| Dimension | Einheit | Was sie treibt | Optional |
|---|---|---|---|
| Container Apps, vCPU und Arbeitsspeicher (Consumption) | vCPU-Sekunde und GiB-Sekunde je Replik, aktiv oder im Leerlauf | Zugewiesene Ressourcen je Replik von 0,25 bis 4 vCPU, Zahl der Repliken, Mindestreplikzahl; je Abonnement und Monat sind 180.000 vCPU-Sekunden und 360.000 GiB-Sekunden frei | Nein, aber null bei null Repliken |
| Container Apps, Anfragen | je Million HTTP-Anfragen | Anfragen von außerhalb der Umgebung; Health Probes und interne Aufrufe zählen nicht; 2 Millionen je Abonnement und Monat frei | Nein für Apps mit externem Ingress |
| Container Apps, Dedicated-Workload-Profile | Instanz je Stunde nach Profil (D4 bis D32, E4 bis E32, GPU) plus Verwaltungsgebühr je Stunde und Umgebung | Zahl der Profilinstanzen und Profilgröße, nicht die Zahl der Apps darauf; Private Endpoints und geplante Wartung lösen die Verwaltungsgebühr auch im Consumption-Plan aus | Ja |
| Container Apps, serverlose GPU und Dynamic Sessions | GPU-Sekunde; Sitzung je Stunde (Code Interpreter) oder E16-Instanzen (Custom Container) | GPU-Typ und Zahl zugewiesener Sitzungen; GPU-Repliken kennen keinen Leerlaufpreis | Ja |
| Container Instances | vCPU-Sekunde und GB-Sekunde je Containergruppe | vCPU auf ganze Zahlen aufgerundet, GB auf Zehntel; von der Image-Pull bis zum Stopp; Windows-Software je vCPU-Sekunde zusätzlich | Ja |
| Container Registry | Registry je Tag in Basic, Standard oder Premium | Stufe mit 10, 100 oder 500 GiB inklusive; Speicher darüber je GB und Monat; Premium für Geo-Replikation, Private Link und Retention | Nein für eine eigene Registry |
| Container Registry, Geo-Replikation | Premium-Registry-Einheit je Tag und Region, Speicher je Replik | Zahl der Replikregionen; ein Image in fünf Regionen belegt fünfmal Speicher; der Abgleich zwischen Regionen kostet Datentransfer | Ja |
| ACR Tasks und ausgehender Datenverkehr | vCPU-Sekunde für Builds; GB ausgehend | Build-Minuten und Pulls in andere Regionen oder ins Internet | Ja (Bandbreite und Netzwerk) |
| Kaufoption | Savings Plan für Compute auf Dedicated-Profile | Ein- oder Dreijahreslaufzeit | Ja (Azure Savings Plans) |
Eine Replik gilt als im Leerlauf, wenn ihre Revision eine Mindestreplikzahl über null hat und auf diese Zahl skaliert ist, alle Container gestartet sind, keine HTTP-Anfrage in Arbeit ist, weniger als 0,01 vCPU genutzt werden und weniger als 1.000 Byte je Sekunde Netzwerkverkehr ankommen. Dann gilt der reduzierte Leerlaufpreis; sobald eine der Bedingungen fällt oder die Revision über das Minimum skaliert, gilt für alle laufenden Repliken der aktive Preis. Jobs werden immer aktiv berechnet, weil sie nach der Ausführung keine Ressourcen mehr belegen. Das Freikontingent erscheint nicht auf der Rechnung; berechnet wird nur der Verbrauch darüber.
Im Dedicated-Plan zahlen Sie Profilinstanzen, nicht Apps: Ein Profil D4 mit 4 vCPU und 16 GiB nimmt mehrere Apps auf, skaliert nach Bedarf auf weitere Instanzen und wird je laufender Instanz berechnet, und sobald die Umgebung ein Dedicated-Profil enthält, fällt die Verwaltungsgebühr je Stunde an. Das Flexible-Profil in der Vorschau wird wie Consumption plus Verwaltungsgebühr berechnet und kann nicht auf null skalieren. Wie sich Container Apps zu AKS und zu den Diensten der anderen Anbieter verhält, ordnet Container und Kubernetes ein; die AKS-Zähler beschreibt Azure Kubernetes Service.
Container Instances berechnen je Containergruppe die angeforderten vCPU, auf ganze Zahlen aufgerundet, und den angeforderten Arbeitsspeicher, auf Zehntel-GB aufgerundet, sekundengenau vom Beginn der ersten Image-Pull bis zum Stopp der Gruppe; je Gruppe sind mindestens 1 vCPU und 1 GB und höchstens 4 vCPU möglich. Die Container Registry berechnet einen Tagessatz je Stufe, solange die Registry existiert, unabhängig von Pulls und Pushes; Basic schließt 10 GiB, Standard 100 GiB und Premium 500 GiB Speicher ein, darüber kostet jedes GB je Monat.
So erscheint es in den Abrechnungsdaten
Container Apps stehen im Kostenexport unter MeterCategory Azure Container Apps. Im Consumption-Plan heißen die Zähler Standard vCPU Active Usage und Standard vCPU Idle Usage je 1 Second, Standard Memory Active Usage und Standard Memory Idle Usage je 1 GiB Second und Standard Requests je 1M; Dedicated-Profile erzeugen Dedicated vCPU Usage je 1 Hour, Dedicated Memory Usage je 1 Hour und Dedicated Plan Management je 1 Hour, GPU-Profile Dedicated GPU Usage und serverlose GPUs Standard NC T4 v3 GPU Usage oder Standard NC A100 v4 GPU Usage je 1 Second. ConsumedService ist Microsoft.App; ResourceId zeigt bei Verbrauchszählern auf containerApps/ und den App-Namen oder auf jobs/, bei der Verwaltungsgebühr auf managedEnvironments/ und die Umgebung.
Container Instances stehen unter MeterCategory Container Instances mit Standard vCPU Duration je 1 Hour, Standard Memory Duration je 1 GB Hour und Standard Windows Software Duration je 1 Second, ConsumedService Microsoft.ContainerInstance und ResourceId auf containerGroups/. Die Container Registry steht unter MeterCategory Container Registry mit Basic Registry Unit, Standard Registry Unit oder Premium Registry Unit je 1/Day, Data Stored je 1 GB/Month, Premium Registry Replication Unit je 1/Day je Replikregion und Task vCPU Duration je 1 Second; ConsumedService ist Microsoft.ContainerRegistry. Image-Pulls aus einer anderen Region oder ins Internet stehen bei der Bandbreite, nicht bei der Registry. Den Aufbau des Exports beschreibt Azure-Kostenexporte.
Im FOCUS-Export werden diese Zeilen zu ChargeCategory Usage mit PricingCategory Standard, Savings-Plan-Zeilen auf Dedicated-Profilen zu Committed; MeterName landet in SkuMeter, Kategorie und Unterkategorie in x_SkuMeterCategory und x_SkuMeterSubcategory. ServiceName leitet Microsoft aus ConsumedService und Ressourcentyp ab, sodass Container Apps, Container Instances und Container Registry drei getrennte Dienste bleiben (FOCUS-Spalten).
Stellhebel
Konfiguration: Die Mindestreplikzahl ist der größte Hebel bei Container Apps, weil null Repliken nichts kosten und eine Replik im Leerlauf nur zum reduzierten Preis, aber rund um die Uhr; eine App ohne Latenzanforderung skaliert auf null, eine App mit Anforderung hält eine Replik, nicht drei. Die Ressourcen je Replik sind der zweite Hebel, weil vCPU und Arbeitsspeicher getrennt gezählt werden und 0,25 vCPU je Sekunde ein Viertel von 1 vCPU kosten; Resource Requests gelten hier wie in Kubernetes (Rightsizing). Jobs ersetzen Dauerrepliken für periodische Arbeit, und Skalierungsregeln mit Zeitplan halten Entwicklungsumgebungen nachts auf null (Zeitpläne und Auto-Scaling). Bei der Registry ist die Stufe der Hebel: Premium kostet das Zehnfache von Basic je Tag und lohnt sich nur für Geo-Replikation, Private Link oder Retention-Regeln; ungenutzte Manifeste belegen Speicher, bis sie gelöscht werden.
Kaufoption: Für Dedicated-Profile gilt der Savings Plan für Compute; Consumption-Verbrauch, Container Instances und die Registry haben kein Commitment (Commitment-Strategie).
Architektur: Ein Dedicated-Profil lohnt sich erst, wenn die Apps einer Umgebung zusammen eine Instanz dauerhaft auslasten oder Netzwerkfunktionen brauchen, die der Consumption-Plan nicht bietet, weil die Verwaltungsgebühr und die Instanzen unabhängig von der Last anfallen. Container Instances passen zu kurzen, isolierten Aufgaben, nicht zu Dauerdiensten, bei denen die Rundung auf ganze vCPU und die fehlende Skalierung teurer sind als eine Container App (Architekturentscheidungen und Kosten). Eine Registry je Region statt Geo-Replikation spart die Replikationseinheit, kostet aber Datentransfer bei jedem Pull über Regionsgrenzen (Datentransfer-Optimierung).
Wo es schiefgeht
- Die Mindestreplik läuft rund um die Uhr. Eine Revision mit
minReplicas1 erzeugt jede Sekunde vCPU- und Speicherzeilen, auch ohne Anfrage. Prüfen Sie das Verhältnis vonIdle UsagezuActive Usageje App; eine App, die fast nur Leerlauf meldet, braucht die Mindestreplik vermutlich nicht. - Leerlauf, der keiner ist. Ein Hintergrundprozess, ein Polling-Trigger oder Logging über 1.000 Byte je Sekunde hält die Replik aktiv, und der aktive Preis gilt für vCPU und Arbeitsspeicher. Prüfen Sie Apps, deren
Idle Usagetrotz Mindestreplik bei null liegt. - Die Verwaltungsgebühr ohne Dedicated-Profil. Private Endpoints und geplante Wartung lösen
Dedicated Plan Managementauch in einer Umgebung ohne Dedicated-Profil aus. Die Zeile zeigt aufmanagedEnvironments/. - Mehrere Umgebungen. Jede Container-Apps-Umgebung mit Dedicated-Profil trägt ihre eigene Verwaltungsgebühr; Umgebungen je Team statt je Netzwerk vervielfachen sie.
- Alte Revisionen im Multi-Revision-Modus. Eine Revision ohne Traffic, aber mit Mindestreplik läuft weiter. Deaktivieren Sie Revisionen, die keinen Traffic-Anteil mehr haben.
- Container Instances, die nie stoppen. Eine Containergruppe mit Neustart-Richtlinie Always kostet jede Sekunde weiter, und die Rundung auf ganze vCPU und Zehntel-GB macht kleine Gruppen teurer, als ihre Anforderung vermuten lässt (ungenutzte und verwaiste Ressourcen).
- Die Registry wächst mit jedem Build. Jeder Push legt neue Layer ab, und untagged Manifeste bleiben, bis eine Retention-Regel oder ein Purge sie löscht;
Data Storedwächst über das Inklusivvolumen, und bei Geo-Replikation je Region. - Premium für eine Region. Eine Premium-Registry ohne Geo-Replikation, Private Link oder Retention zahlt das Zehnfache von Basic für Limits, die sie nicht nutzt.
Beispiel
Listenpreise der Azure Retail Prices API für Germany West Central, gelesen am 2026-10-21. In EUR: Dedicated-Profile kosten 0,0502 EUR je vCPU-Stunde und 0,0044 EUR je GiB-Stunde, die Verwaltungsgebühr 0,088 EUR je Stunde und Umgebung; Anfragen kosten 0,352 EUR je Million über den 2 Millionen freien. Container Instances kosten 0,041 EUR je vCPU-Stunde und 0,0045 EUR je GB-Stunde. Die Container Registry kostet 0,1466 EUR je Tag in Basic, 0,5866 EUR in Standard und 1,4666 EUR in Premium, Speicher über dem Inklusivvolumen 0,088 EUR je GB und Monat und jede Replikregion weitere 1,4666 EUR je Tag. Die sekundengenauen Consumption-Zähler gibt die API in EUR nur mit vier Nachkommastellen aus, sodass sie als 0 erscheinen; dieselbe Abfrage in USD nennt 0,000024 USD je aktiver vCPU-Sekunde, 0,000003 USD je vCPU-Sekunde im Leerlauf und 0,000003 USD je GiB-Sekunde aktiv wie im Leerlauf. Eine Mindestreplik mit 0,5 vCPU und 1 GiB kostet damit aktiv 0,000015 USD je Sekunde und im Leerlauf 0,0000045 USD je Sekunde, also 0,054 USD und 0,0162 USD je Stunde vor dem Freikontingent. Die Zahlen zeigen, dass der Leerlaufpreis der vCPU ein Achtel des aktiven ist, dass eine Premium-Registry je Tag das Zehnfache einer Basic-Registry kostet und dass eine Dedicated-Umgebung schon über die Verwaltungsgebühr mehr kostet als eine kleine Consumption-App im Leerlauf.
Quellen
Gelesen am 2026-10-21. Preise: Azure Retail Prices API, Container Apps in Germany West Central in EUR, Container Apps Standard in USD, Container Instances in EUR, Container Registry in EUR, Dedicated-Zähler mit Savings-Plan-Preisen, Dokumentation der Azure Retail Prices API, Preisseite Container Instances. Abrechnungsdaten: Felder der Kostendetails, Umwandlung von Cost-Management-Daten nach FOCUS. Dienst: Abrechnung in Azure Container Apps, Workload-Profile, Stufen der Container Registry, Geo-Replikation der Container Registry.