Sie entwerfen ein Spoke-VNet in Azure, um eine mehrschichtige Anwendung zu hosten. Die IP-Strategie des Unternehmens reserviert 10.0.0.0/8 für lokale und bestehende Hub-VNets. Das neue Spoke-VNet muss Überschneidungen vermeiden, um Peering zum Hub zu ermöglichen. Die Anwendung wird ein Azure Storage-Konto verwenden, das niemals über seinen öffentlichen Endpunkt erreichbar sein darf. Sie erwarten etwa 500 VMs mit Skalierungsmöglichkeiten. Was sollten Sie entwerfen?

Die korrekte Option erstellt ein VNet im nicht überlappenden Adressbereich 172.16.0.0/16, was Peering ermöglicht. Die Subnetzgrößen (/23, /24) sind für die erwartete VM-Anzahl von 500 mit Skalierung ausreichend und folgen Best Practices für die Schichtentrennung. Ein dediziertes /27-Subnetz für Private Endpoints ist eine bewährte Methode für die Verwaltung und Sicherheit. Die Verwendung von Private Endpoints für das Speicherkonto in Kombination mit einer privaten DNS-Zone und der Deaktivierung des öffentlichen Netzwerkzugriffs erfüllt die Anforderung, dass das Speicherkonto niemals über seinen öffentlichen Endpunkt erreichbar sein darf, und bietet eine sichere und private Verbindung. Die anderen Optionen sind ungeeignet: 172.16.0.0/24 VNet ist zu klein für 500 VMs. Service Endpoints schützen den Speicher, aber der öffentliche Endpunkt bleibt erreichbar. 10.250.0.0/16 VNet überlappt mit dem reservierten 10.0.0.0/8 Bereich. Das Aktivieren des öffentlichen Endpunkts für Verwaltung widerspricht der Anforderung. 192.168.0.0/20 VNet ist ein gültiger Adressbereich, aber das Platzieren von Private Endpoints direkt in Produktions-Subnetzen ist weniger isoliert als ein dediziertes Subnetz. 172.16.0.0/16 VNet mit einem einzigen /16-Subnetz bietet keine Schichtentrennung. Service Endpoints lassen den öffentlichen Endpunkt erreichbar.