Stai progettando una rete virtuale spoke in Azure per ospitare un'applicazione multi-tier. La strategia IP aziendale riserva 10.0.0.0/8 per le risorse on-premises e le VNet hub esistenti. La nuova spoke deve evitare sovrapposizioni per consentire il peering all'hub. L'applicazione utilizzerà un account Azure Storage che non deve mai essere raggiungibile tramite il suo endpoint pubblico. Ti aspetti circa 500 VM con spazio per scalare. Cosa dovresti progettare?

La risposta corretta è la migliore perché soddisfa tutti i requisiti. L'indirizzamento 172.16.0.0/16 evita la sovrapposizione con 10.0.0.0/8. Le subnet /23 e /24 forniscono spazio sufficiente per 500+ VM e la subnet /27 è adeguata per gli endpoint privati. L'uso di Private Endpoints con una zona DNS privata e la disabilitazione dell'accesso pubblico garantiscono che l'account di storage non sia mai raggiungibile tramite il suo endpoint pubblico, come richiesto. Le opzioni errate presentano i seguenti problemi: Una VNet 172.16.0.0/24 è troppo piccola per 500+ VM. Gli endpoint di servizio non disabilitano l'accesso pubblico e gli NSG non sono sufficienti per impedire l'accesso pubblico. Una VNet 10.250.0.0/16 si sovrappone potenzialmente a 10.0.0.0/8. Mantenere l'endpoint pubblico abilitato viola il requisito di non raggiungibilità pubblica. Una VNet 192.168.0.0/20 è un intervallo valido, ma posizionare gli endpoint privati direttamente nelle subnet di produzione e lasciare le policy di rete abilitate non è la pratica più sicura o scalabile. Una singola subnet /16 non è una best practice per la segmentazione e la sicurezza. Gli endpoint di servizio non disabilitano l'accesso pubblico.