https://thedotnetblog.com/de/tags/networking/Articles, tutorials and insights from the .NET community.Hugode@thedotnetblog (The .NET Blog)@thedotnetblogTue, 19 May 2026 00:00:00 +0000https://thedotnetblog.com/de/news/emiliano-montesdeoca/aspire-azure-enterprise-networking-private-endpoints/Tue, 19 May 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/de/news/emiliano-montesdeoca/aspire-azure-enterprise-networking-private-endpoints/Der neue Azure-Unternehmensnetzwerk-Support für Aspire ermöglicht es, VNets, private Endpoints, NAT-Gateways, NSGs und Netzwerksicherheitsperimeter direkt im AppHost zu modellieren — ohne Infrastrukturdrift.<p>Ich habe dieses Szenario zu oft gesehen. Die App ist fertig. Die Demo ist großartig. Dann erscheint die Sicherheits-Checkliste: Speicher aus dem öffentlichen Internet nehmen, innerhalb eines VNets ausführen, ausgehende IPs für die Allowlist des Partners bereitstellen, nachweisen, dass nur die richtigen Subnetze mit den richtigen Diensten kommunizieren.</p> <p>An diesem Punkt beginnen das Anwendungsmodell und das Infrastrukturmodell auseinanderzudriften, auf eine Art, die schmerzhaft zu pflegen ist.</p> <p>Der neue Azure-Unternehmensnetzwerk-Support für Aspire adressiert dies direkt. Sie beschreiben die Netzwerkstruktur neben den Ressourcen, die sie verwenden, in Ihrem AppHost.</p> <h2 id="die-bausteine">Die Bausteine</h2> <p>Hier ist, wofür jedes Azure-Netzwerkkonzept verwendet wird, destilliert:</p> <table> <thead> <tr> <th>Funktion</th> <th>Verwenden Sie es wenn</th> <th>Warum es wichtig ist</th> </tr> </thead> <tbody> <tr> <td>Virtuelles Netzwerk</td> <td>Sie einen privaten Adressraum benötigen</td> <td>Die Netzwerkgrenze für Subnetze, private Endpoints und Routing</td> </tr> <tr> <td>Subnetz</td> <td>Sie Workloads innerhalb des VNets trennen müssen</td> <td>Jeder Teil des Systems erhält seinen eigenen Adressbereich und seine eigene Richtlinienoberfläche</td> </tr> <tr> <td>Delegiertes Subnetz</td> <td>Ein Plattformdienst (wie ACA) ein Subnetz verwalten muss</td> <td>Ermöglicht dem Dienst, verwaltete Infrastruktur sicher in Ihrem VNet zu platzieren</td> </tr> <tr> <td>NAT-Gateway</td> <td>Sie vorhersagbare ausgehende öffentliche IPs benötigen</td> <td>Stabile Adresse für Allowlists und Auditing</td> </tr> <tr> <td>Privater Endpoint</td> <td>Sie eine PaaS-Ressource privat erreichbar haben möchten</td> <td>Platziert eine private IP für diesen Dienst in Ihrem VNet, entfernt öffentliche Exposition</td> </tr> <tr> <td>NSG</td> <td>Sie Regeln für Datenverkehr auf Subnetz-Ebene benötigen</td> <td>Explizites Erlauben/Ablehnen für eingehenden und ausgehenden Datenverkehr pro Subnetz</td> </tr> </tbody> </table> <h2 id="beschreibung-im-apphost">Beschreibung im AppHost</h2> <p>Die wichtigste Änderung hier ist, dass Sie das Netzwerk <em>zusammen</em> mit den Ressourcen modellieren, die es verwenden, nicht in einer separaten Bicep-Datei, die mit der Zeit vom Anwendungsmodell abweicht.</p> <p>Vom AppHost aus können Sie:</p> <ul> <li>VNets und Subnetze mit <code>AddVirtualNetwork()</code> und <code>AddSubnet()</code> erstellen</li> <li>Ein NAT-Gateway an Subnetze für stabile ausgehende IPs anhängen</li> <li>Private Endpoints für Speicher, Key Vault, SQL und andere PaaS-Dienste erstellen</li> <li>NSGs mit eingehenden und ausgehenden Sicherheitsregeln definieren</li> <li>Netzwerksicherheitsperimeter für ressourcenübergreifende Richtlinien konfigurieren</li> </ul> <p>Das Ergebnis ist, dass wenn Sie <code>azd up</code> ausführen, die Infrastruktur mit dem übereinstimmt, was das Anwendungsmodell sagt, dass es benötigt. Nicht das, was eine manuell gepflegte Vorlage sagt.</p> <h2 id="warum-das-für-echte-anwendungen-wichtig-ist">Warum das für echte Anwendungen wichtig ist</h2> <p>Einige Dinge, die erheblich einfacher werden, sobald das Netzwerk in Aspire modelliert ist:</p> <p><strong>Private Endpoints für Key Vault und Speicher</strong> — Sie beschreiben <code>WithPrivateEndpoint()</code> auf diesen Ressourcen, und Aspire übernimmt die DNS-Zonenkonfiguration und das Endpoint-Anhängen. Die App ändert sich nie.</p> <p><strong>Konsistente ausgehende IPs</strong> — fügen Sie ein NAT-Gateway zum entsprechenden Subnetz hinzu, und jede ausgehende Anfrage Ihrer App geht durch eine bekannte, stabile IP. Partner können sie allowlisten. Auditoren können sie nachverfolgen.</p> <p><strong>NSG-Regeln aus Code</strong> — anstatt durch das Portal zu klicken oder ein Bicep-Snippet zu pflegen, leben Ihre Sicherheitsregeln im AppHost neben den Ressourcen, die sie schützen.</p> <p>Dies ist die Art von Integration, die Demos nicht aufregend macht, aber Produktionssysteme wartbar macht.</p> <h2 id="fazit">Fazit</h2> <p>Netzwerksicherheit, die spät im Projektlebenszyklus auftaucht, ist ein gelöstes Problem, wenn Sie sie von Anfang an zusammen mit der App modellieren. Der Unternehmensnetzwerk-Support von Aspire macht das möglich, ohne eine separate Infrastruktur-Spur zu benötigen.</p> <p>Vollständige Details im ursprünglichen Beitrag: <a href="https://devblogs.microsoft.com/aspire/aspire-azure-enterprise-networking/">Securing Azure apps with Aspire enterprise networking</a></p>