다중 계층 애플리케이션을 호스팅하기 위해 Azure에서 스포크 가상 네트워크를 설계하고 있습니다. 회사 IP 전략은 온프레미스 및 기존 허브 VNet을 위해 10.0.0.0/8을 예약합니다. 새 스포크는 허브에 피어링할 수 있도록 중복을 피해야 합니다. 앱은 퍼블릭 엔드포인트를 통해 절대 연결할 수 없는 Azure Storage 계정을 사용합니다. 약 500개의 VM과 확장할 공간이 예상됩니다. 무엇을 설계해야 합니까?

정답은 172.16.0.0/16 VNet을 생성하고, 앱 및 DB 계층에 /23 서브넷, 웹에 /24 서브넷, 프라이빗 엔드포인트에 전용 /27 서브넷을 할당하며, 스토리지 계정에 Private Endpoints를 사용하고 프라이빗 DNS 영역을 연결하며, 계정의 퍼블릭 네트워크 액세스를 비활성화하는 것입니다. 이는 회사 IP 전략(10.0.0.0/8 충돌 방지)을 준수하고, 약 500개의 VM을 수용할 수 있는 충분한 IP 공간(/16 VNet 및 /23, /24 서브넷)을 제공하며, 스토리지 계정에 대한 퍼블릭 액세스를 금지하고 프라이빗 연결을 보장하는 요구 사항을 충족합니다. 오답인 172.16.0.0/24 VNet은 500개 이상의 VM에 충분한 IP 공간을 제공하지 않으며, 서비스 엔드포인트는 퍼블릭 엔드포인트를 통해 연결할 수 없다는 요구 사항을 충족하지 못합니다. 10.250.0.0/16 VNet은 10.0.0.0/8 IP 공간과 충돌할 수 있으며, 퍼블릭 엔드포인트를 활성화된 상태로 두는 것은 요구 사항에 위배됩니다. 192.168.0.0/20 VNet은 충분한 IP 공간을 제공하지만, 프라이빗 엔드포인트를 프로덕션 서브넷 내에 배치하는 것은 보안 및 관리 측면에서 전용 서브넷보다 좋지 않습니다. 단일 /16 서브넷은 서브넷 분리를 제공하지 않으며, 서비스 엔드포인트는 퍼블릭 액세스 금지 요구 사항을 충족하지 못합니다.