Вы проектируете spoke-виртуальную сеть в Azure для размещения многоуровневого приложения. Корпоративная IP-стратегия резервирует 10.0.0.0/8 для локальных сетей и существующих hub VNet. Новая spoke-сеть должна избегать пересечений, чтобы обеспечить пиринг с hub-сетью. Приложение будет использовать учетную запись хранения Azure, которая никогда не должна быть доступна через ее публичную конечную точку. Вы ожидаете около 500 виртуальных машин с возможностью масштабирования. Что вы должны спроектировать?

Правильный ответ предлагает VNet 172.16.0.0/16, которая не пересекается с зарезервированным диапазоном 10.0.0.0/8, что критично для пиринга. Подсети /23 и /24 предоставляют достаточно IP-адресов для 500+ VM с возможностью масштабирования. Использование Private Endpoints для учетной записи хранения с отключением публичного доступа и связыванием с частной зоной DNS обеспечивает максимальную безопасность, направляя трафик через частную сеть Azure. Неправильные варианты: VNet 172.16.0.0/24 слишком мала для 500+ VM. Service Endpoints менее безопасны, чем Private Endpoints, так как трафик все равно проходит через публичные IP-адреса Azure. VNet 10.250.0.0/16 пересекается с корпоративным диапазоном 10.0.0.0/8, что вызовет конфликты маршрутизации. Оставление публичной конечной точки включенной нарушает требование безопасности. Размещение Private Endpoints внутри производственных подсетей не является лучшей практикой; выделенная подсеть для них обеспечивает лучшую изоляцию и управление. Одна подсеть /16 для всей VNet не соответствует лучшим практикам сегментации сети и безопасности. Service Endpoints не обеспечивают такой же уровень изоляции, как Private Endpoints.