Azure Container Apps: Sichere und kostengünstige .NET…

Praxis-Tutorial · Azure Container Apps · ASP.NET Core · Kosten und Sicherheit

Wann ist Azure Container Apps sinnvoll?

Azure Container Apps (ACA) eignet sich für HTTP-APIs, Hintergrundverarbeitung und ereignisgesteuerte Dienste, die als Container laufen sollen, ohne dass du Kubernetes selbst betreiben musst. Im Unterschied zu einer ständig laufenden VM kann eine geeignete Anwendung ihre Replikate bei wenig Last reduzieren. Das spart unter bestimmten Voraussetzungen Compute-Kosten, aber nicht automatisch alle Azure-Kosten.

1. Das Architekturmodell verstehen

Client → HTTPS Ingress → Azure Container App (.NET API)
                             ↓ Managed Identity
                    Azure Key Vault / Azure-Dienste
                             ↓
                     Application Insights
Container Registry → versioniertes Image → Revision

Eine Container App wird in einer Container Apps Environment betrieben. Umgebung, Netzwerk, Logging, Registry und eventuelle Datenbank oder Queue haben eigene Einstellungen und teilweise eigene Kosten. Entscheide früh, ob der Dienst öffentlich erreichbar sein muss oder nur intern angesprochen wird.

2. .NET-API lokal vorbereiten

Für ein nachvollziehbares Beispiel erzeugen wir einen kleinen ASP.NET-Core-Dienst mit einem Health-Endpunkt.

dotnet new webapi -n ContainerDemo
cd ContainerDemo
dotnet publish -c Release

Beispiel für eine vereinfachte Program.cs:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/health", () => Results.Ok(new { status = "ok" }));
app.MapGet("/api/version", () => Results.Ok(new { version = "1.0" }));
app.Run();

Die Endpunkte dienen nur zur Veranschaulichung und enthalten noch keine API-Authentifizierung. Ein Health-Endpunkt sollte keinen Zugang zu Geheimnissen oder internen Daten bieten.

3. Container-Image erstellen

Ein Mehrstufen-Dockerfile hält SDK-Werkzeuge aus dem Laufzeit-Image heraus. Passe das .NET-Major-Release an dein Projekt an und verwende eine unterstützte Version.

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app/publish .
USER $APP_UID
EXPOSE 8080
ENV ASPNETCORE_HTTP_PORTS=8080
ENTRYPOINT ["dotnet", "ContainerDemo.dll"]

Lege eine .dockerignore an und prüfe Abhängigkeiten sowie Sicherheitsupdates. Das Beispiel nutzt .NET 8 als bekannte LTS-Basis; für neue Projekte solltest du den aktuellen Microsoft-Supportlebenszyklus prüfen und Images regelmäßig aktualisieren. Verwende im Betrieb unveränderliche Tags oder Image-Digests statt blind auf latest zu setzen.

4. Scale-to-zero und seine Grenzen

Mit minReplicas: 0 kann der Dienst bei fehlender Last auf null aktive Replikate sinken. Das funktioniert nur, wenn Skalierungsregeln, Revisionseinstellungen und Anwendungstyp geeignet sind. Neue Aufrufe können durch das Hochfahren eine höhere Anfangslatenz haben. Eine ständig laufende Hintergrundschleife oder ein ungeeigneter Trigger verhindert möglicherweise das gewünschte Skalierungsverhalten. Für zeitkritische Endpunkte kann eine Mindestanzahl von einer Replik sinnvoller sein.

5. Ingress, Identität und Secrets

Öffentlicher Ingress sollte nur eingerichtet werden, wenn Nutzer oder externe Systeme ihn benötigen. Bei internen Integrationen nutze nach Möglichkeit interne Erreichbarkeit oder eine bewusst gesicherte vorgeschaltete Schicht. HTTPS allein ist keine Autorisierung: Schütze fachliche Endpunkte etwa über Microsoft Entra ID oder API Management. Verlasse dich nicht auf einen ungeschützten URL-Pfad.

Für Azure-Ressourcen verwende eine Managed Identity, vergebe nur erforderliche Rollen und nutze Key Vault für verbleibende Geheimnisse. Hinterlege Passwörter weder in Dockerfiles noch in Images oder Git-Repositories. Eine Key-Vault-Referenz setzt weiterhin die passenden Zugriffsrechte der Identität voraus.

6. Revisionen und sichere Deployments

Jedes neue Image kann eine neue Revision erzeugen. Teste die neue Version zuerst gegen Health-, Sicherheits- und Integrationstests. Bei mehreren aktiven Revisionen lässt sich Traffic kontrolliert umstellen, sofern der gewählte Revisionsmodus und die Routingkonfiguration dies unterstützen. Ein Rollback sollte wieder auf eine funktionierende, bereits getestete Revision zeigen. Achte darauf, dass Datenbankschemata und Nachrichtenformate rückwärtskompatibel sind.

7. Kosten systematisch kalkulieren

Betrachte nicht nur CPU und RAM aktiver Container-Replikate. In ein Budget gehören mindestens Container Apps Compute, Registry, Log Analytics/Application Insights, ausgehender Datenverkehr, Key Vault, Datenbank/Queue und eventuelle Netzwerkinfrastruktur. Preise unterscheiden sich nach Region und Verbrauchsmodell. Leerlaufkosten von abhängigen Ressourcen können verbleiben, selbst wenn die App null Replikate hat.

Eine belastbare Schätzung braucht die Anzahl Requests, durchschnittliche Laufzeit pro Request, parallele Aufrufe, Containergröße, Datenvolumen und Aufbewahrungsdauer von Logs. Setze Budgets und Warnungen im Azure Cost Management, aber berücksichtige, dass Budgetwarnungen Dienste nicht automatisch stoppen.

8. Monitoring und Fehlersuche

Überwache HTTP-Fehlerquoten, Antwortzeiten inklusive Cold Starts, Replicazahlen, Neustarts, Speicherauslastung, fehlgeschlagene Revisionen und externe Abhängigkeiten. Verwende Korrelations-IDs zwischen API und Downstream-System. In Logs gehören keine Access Tokens oder vollständigen personenbezogenen Nutzdaten. Alarmiere bei dauerhaft steigender 5xx-Quote, nicht nur bei CPU-Spitzen.

9. Checkliste für einen zuverlässigen Go-live

Container startet mit nichtprivilegiertem Benutzer und korrekt gesetztem Port.
Geheimnisse werden nicht im Image gespeichert.
Ingress ist nur soweit geöffnet wie nötig; API-Endpunkte sind autorisiert.
Scaling und mögliche Cold Starts wurden mit realistischen Requests getestet.
Health-Probes und Revision-Rollback funktionieren.
Azure-Budgets umfassen alle abhängigen Dienste.
Logging, Alarmierung und Backups für zustandsbehaftete Daten sind geplant.

Fazit: Azure Container Apps ist besonders dann wirtschaftlich, wenn Last und Betrieb zum Consumption-Modell passen. Sicherheit, Skalierung und Gesamtbetriebskosten müssen gemeinsam betrachtet werden.

Azure Container Apps: Sichere und kostengünstige .NET-APIs betreiben