Azure

Azure Container Apps

Overview

Azure Container Apps ist eine serverlose Plattform für containerisierte Anwendungen. Du lieferst ein Container-Image aus einer beliebigen Registry, etwa Azure Container Registry oder Docker Hub, Azure kümmert sich um Bereitstellung, Skalierung, Ingress und die Aktualität der Plattform. Typische Einsätze sind API-Endpunkte, Microservices, ereignisgesteuerte Verarbeitung und Hintergrundjobs.

Abgrenzung zu verwandten Diensten: Azure Container Instances (ACI) startet einzelne Container-Gruppen für kurzlebige Aufgaben, ohne Revisionen, Traffic-Splitting oder eingebaute Service Discovery. Azure Kubernetes Service (AKS) gibt volle Kontrolle über einen Kubernetes-Cluster, verlangt dafür aber den Betrieb von Node Pools, Upgrades und Clusterkonfiguration. Azure App Service bleibt der einfachere Weg für klassische Web-Apps, Azure Functions für einzelne ereignisgesteuerte Funktionen, die sich auch innerhalb von Container Apps betreiben lassen.

Für Azure Spring Apps, das am 31. März 2028 endet, nennt Microsoft Container Apps mit seinen verwalteten Java-Komponenten wie Eureka Server und Config Server als Hauptziel der Migration. Neuere Bausteine sind serverlose GPUs (NVIDIA T4 und A100) für KI-Inferenz, dynamische Sitzungen für Code Interpreter und eigene Container sowie das Workload-Profil Flexible, das sich in der Preview befindet.

How it works

Container Apps laufen in einer Umgebung (Container Apps Environment), die eine gemeinsame Netzwerk- und Protokollgrenze bildet und optional in einem bestehenden VNet liegt. Der Ablauf:

  1. Du legst eine Umgebung an. Sie enthält immer das Workload-Profil Consumption, zusätzlich lassen sich Dedicated-Profile (Allzweck D4 bis D32, speicheroptimiert E4 bis E32), GPU-Profile und das Profil Flexible ergänzen.
  2. Eine Container-App referenziert ein Image samt CPU- und Speicherzuteilung. Änderungen an der Konfiguration erzeugen neue Revisionen, zwischen denen Du Traffic für Blue/Green-Deployments oder A/B-Tests aufteilst.
  3. Skalierungsregeln steuern die Zahl der Replikate nach HTTP-Last, Ereignissen, CPU, Arbeitsspeicher oder jedem von KEDA unterstützten Scaler. Die meisten Apps skalieren auf null, Apps mit CPU- oder Speicherregel nicht.
  4. Ingress veröffentlicht die App per HTTPS oder TCP, öffentlich oder nur intern mit DNS-basierter Service Discovery. Dapr ist als Laufzeit für Microservices integriert.
  5. Jobs laufen manuell, nach Zeitplan oder ereignisgesteuert und beenden sich nach getaner Arbeit. Protokolle fließen nach Log Analytics, Geheimnisse verwaltet die App als Secrets.

Benefits

  • Kein Clusterbetrieb: Plattform, Skalierung und Ingress liefert Azure, Dein Team kümmert sich nur um Image und Konfiguration.
  • Kosten folgen der Last: Im Consumption-Profil fallen bei null Replikaten keine Ressourcenkosten an, und Verbrauch unterhalb des monatlichen Freikontingents erscheint nicht auf der Rechnung.
  • Sichere Releases: Revisionen und Traffic-Splitting erlauben schrittweise Rollouts und schnelles Zurückschalten auf die vorherige Version.
  • Ereignisgesteuertes Skalieren: KEDA-Scaler reagieren etwa auf Warteschlangenlängen, ohne dass Du eigene Skalierungslogik schreibst.
  • Passende Hardware: Dedicated- und GPU-Profile liefern isolierte Rechenleistung für dauerhaft hohe Last oder KI-Inferenz.

Practical example

Ein Maschinenbauer aus Baden-Württemberg mit 400 Mitarbeitenden betreibt ein Kundenportal für Ersatzteilanfragen, das bisher auf zwei Windows-VMs lief. Die IT packt Frontend und Bestell-API in Container, legt die Images in Azure Container Registry ab und betreibt sie in einer Container-Apps-Umgebung im bestehenden Hub-VNet. Der nächtliche Abgleich mit dem ERP läuft als geplanter Job. Neue Versionen erhalten zunächst zehn Prozent des Traffics und nach einem Tag ohne Fehler den Rest. Die Patch-Wochenenden für die beiden VMs entfallen.

Things to keep in mind

  • Lege Netzwerk und ausgehenden Verkehr vor dem Anlegen der Umgebung fest: Mit benutzerdefinierten Routen im Dedicated-Plan musst Du Egress ausdrücklich an eine Appliance wie Azure Firewall leiten.
  • Setze für Dienste, die keinen Kaltstart vertragen, eine Mindestzahl von einem Replikat. Untätige Replikate werden zum reduzierten Leerlauftarif berechnet.
  • Hinterlege Zugangsdaten und Verbindungszeichenfolgen als Secrets der App oder in Azure Key Vault, nie im Image.
  • Als HTTP-Anfragen zählen nur Aufrufe von außerhalb der Umgebung, Health Probes nicht. Interne Service-zu-Service-Aufrufe verursachen also keine Request-Kosten.
  • Brauchst Du eigene Kubernetes-Operatoren oder volle Clusterkontrolle, ist AKS die passendere Wahl.

Licensing & availability

Keine Lizenz, Abrechnung über das Azure-Abonnement nach Plan. Consumption: sekundengenau nach vCPU-Sekunden und GiB-Sekunden (bei serverlosen GPUs zusätzlich GPU-Sekunden) plus HTTP-Anfragen von außerhalb der Umgebung, mit monatlichem Freikontingent pro Abonnement und reduziertem Leerlauftarif für Mindestreplikate. Jobs und serverlose GPUs zahlen immer den aktiven Tarif. Dedicated: feste Plan-Management-Gebühr, sobald ein Dedicated-Profil genutzt wird, plus Kosten pro laufender Profilinstanz. Private Endpoints und geplante Wartung lösen die Management-Gebühr auch im Consumption-Plan aus. Das Profil Flexible ist Preview. Stand: Oktober 2026.

Conclusion

Azure Container Apps ist für die meisten Microservices und APIs in Azure der pragmatische Mittelweg zwischen App Service und AKS. Starte im Consumption-Profil und wechsle auf Dedicated-Profile, wenn die Last dauerhaft hoch ist.

Further reading

Related articles