Netzwerkisolation, private Endpunkte, Container-Registry-Abstraktion und Azure Front Door – Aspire 13 adressiert Enterprise-Anforderungen direkt im AppHost, ohne separate Infrastruktur-Konfiguration.

Enterprise-Umgebungen stellen Anforderungen, die über "Container starten und verbinden" hinausgehen: Netzwerkisolation, private Datenbankverbindungen, kontrollierter Zugriff auf Container Registries und globale Traffic-Verteilung. In Aspire 9 lagen diese Aspekte vollständig außerhalb des AppHost. Aspire 13 bringt sie hinein.

Container Registry als explizites Konzept

In Aspire 9 war die Container Registry implizit: Azure Container Apps brachte eine Registry mit, fertig. Wer eine bestehende Registry wiederverwenden, mehrere Environments auf dieselbe Registry zeigen oder Docker Hub oder GHCR nutzen wollte, hatte keine saubere Abstraktion.

Ab Aspire 13.1 ist die Registry eine eigenständige Ressource:

// Externe Registry (Docker Hub, GHCR, eigene)
var registry = builder.AddContainerRegistry("prod-registry", "registry.example.com");

// Azure Container Registry mit automatischer Provisionierung
var acr = builder.AddAzureContainerRegistry("acr");

builder.AddProject<Projects.Api>("api")
    .WithContainerRegistry(registry);

Das hat praktische Konsequenzen für den Deployment-Ablauf: Der Image-Push-Schritt ist jetzt explizit in der Pipeline und kann unabhängig von anderen Provisionierungsschritten parallel laufen. Wer eine ACR mit bestehenden Pull-Identities hat, kann diese direkt referenzieren:

env.WithAcrPullIdentity(existingAcr);

Azure Virtual Network und Private Endpoints

Ab Aspire 13.2 lässt sich Netzwerkisolation direkt im AppHost deklarieren. Statt Bicep-Templates manuell zu schreiben, entstehen VNets, Subnetze und Private Endpoints aus dem Anwendungsmodell:

var vnet = builder.AddAzureVirtualNetwork("vnet");

var appSubnet = vnet.AddSubnet("app-subnet");
var dataSubnet = vnet.AddSubnet("data-subnet");

var postgres = builder.AddAzurePostgresFlexibleServer("db")
    .RunAsContainer()
    .WithSubnet(dataSubnet)
    .AddPrivateEndpoint();

var api = builder.AddProject<Projects.Api>("api")
    .WithSubnet(appSubnet)
    .WithReference(postgres);

Aspire generiert automatisch die DNS-Zonenkonfiguration für private Endpunkte, sodass Services über ihre Aspire-Namen kommunizieren können, auch wenn sie sich in isolierten Subnetzen befinden. NAT Gateways und Network Security Groups sind als Shorthand-Methoden auf Subnetz-Ebene konfigurierbar:

vnet.AddSubnet("app-subnet")
    .WithNatGateway()
    .WithNsg(nsg => nsg
        .DenyAllInbound()
        .AllowInboundFrom(appSubnet));

Wichtig: Alle VNet-APIs sind noch als [Experimental("ASPIREAZURE003")] markiert. Man kann einen Warning-Suppressor im Projekt verwenden, um Compiler-Warnungen bewusst zu akzeptieren (auf eigenes Risiko):

#pragma warning disable ASPIREAZURE003
var vnet = builder.AddAzureVirtualNetwork("vnet");
#pragma warning restore ASPIREAZURE003

Bekannte Falle: Azure SQL Server + Private Endpoints. Wenn AddPrivateEndpoint auf einem SQL-Server gesetzt wird, deaktiviert Aspire den öffentlichen Netzwerkzugriff. Aspire muss aber gleichzeitig einen Deployment-Script (Azure PowerShell) ausführen, der sich zum SQL Server verbindet, um Managed Identity Rollen zuzuweisen. Dieser Script-Container läuft außerhalb des VNets – und kann den SQL Server nicht mehr erreichen.

Das führte bis 13.1 zu einem DeploymentFailed-Fehler ohne erklärendes Log. Aspire 13.2 löst das durch VNet-Integration des Deployment-Script-Containers plus einen automatisch provisionierten Storage Account, der als File Share für den Script-Container benötigt wird. Das passiert transparent, kostet aber einen weiteren provisionierten Azure Storage Account pro Deployment (microsoft/aspire#14421). Wer SQL Server mit Private Endpoints deployt und Aspire 13.1 oder älter nutzt, wird diesen Fehler reproduzierbar sehen.

Network Security Perimeters

Ab Aspire 13.3 sind Azure Network Security Perimeters integrierbar – ein Konzept, das es erlaubt, mehrere Azure-Ressourcen (Storage Accounts, Service Bus, Key Vault) unter einem gemeinsamen Netzwerkperimeter zusammenzufassen, der einheitliche Zugriffsregeln durchsetzt:

var perimeter = builder.AddAzureNetworkSecurityPerimeter("nsp");

builder.AddAzureStorage("storage")
    .WithNetworkSecurityPerimeter(perimeter);

builder.AddAzureServiceBus("bus")
    .WithNetworkSecurityPerimeter(perimeter);

Traffic zwischen Ressourcen innerhalb desselben Perimeters ist ohne explizite Freischaltung erlaubt; externer Zugriff wird zentral verwaltet.

Azure Front Door

Für global verteilte Deployments ist Azure Front Door ab Aspire 13.3 direkt im AppHost modellierbar:

var frontDoor = builder.AddAzureFrontDoor("cdn");

builder.AddProject<Projects.Api>("api")
    .WithExternalHttpEndpoints()
    .WithAzureFrontDoor(frontDoor, route => route
        .WithPath("/api/*")
        .WithCaching());

builder.AddProject<Projects.Frontend>("frontend")
    .WithExternalHttpEndpoints()
    .WithAzureFrontDoor(frontDoor, route => route
        .WithPath("/*"));

Aspire provisioniert das Front Door Profil, die Origins und Routing-Regeln als Teil des normalen aspire deploy-Ablaufs. Caching-Konfiguration, WAF-Policies und Health Probes sind direkt am Route konfigurierbar.

Achtung bei Upgrades auf 13.4: Front Door Naming-Konventionen änderten sich zwischen 13.3 und 13.4 auf eine Weise, die in bestehenden Deployments doppelte Ressourcennamen erzeugen kann. Vor dem Upgrade auf 13.4 sollten bestehende Front Door Ressourcen manuell überprüft werden.

Externe Helm-Charts als Deployment-Schritte

Für Kubernetes-Deployments in Enterprise-Umgebungen gibt es oft bestehende Infrastruktur: einen Ingress Controller, einen Secrets Manager, einen Monitoring-Stack. Aspire 13.4 ermöglicht es, diese als Helm-Chart-Schritte in die Deployment-Pipeline einzubinden:

builder.AddHelmChart("cert-manager", "cert-manager/cert-manager", "v1.16.0",
    values => values.Set("installCRDs", true));

builder.AddHelmChart("prometheus", "prometheus-community/kube-prometheus-stack", "65.1.0");

Diese Charts werden als Teil von aspire deploy installiert, mit denselben Abhängigkeiten wie Aspire-eigene Ressourcen. aspire destroy führt helm uninstall für alle registrierten Charts aus.

Managed Identities pro Service

Bereits in Aspire 9.x eingeführt, aber erwähnenswert: Jeder Azure Container App erhält seit Aspire 9.3 eine dedizierte Managed Identity. In Enterprise-Umgebungen ist das die Grundlage für granulares Rechtemanagement – statt einer Shared Identity mit breitem Zugriff bekommt jeder Service genau die Rechte, die er braucht. Aspire generiert die entsprechenden Role Assignments automatisch beim Deploy.

Aspire 13 für Enterprise: Netzwerk, Registry und Sicherheit