Последняя проверка: май 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене AZ-700. Читайте сверху вниз или переходите к нужному разделу.
Приватное подключение ресурсов между виртуальными сетями (VNet) в разных подписках или регионах.
Настройте пиринг VNet между виртуальными сетями.
Почему: Оставляет трафик в магистральной сети Microsoft. Пиринг VNet не является транзитивным; для связи требуется прямой пиринг (A->B, B->C != A->C).
Разработка адресных пространств VNet для будущих подключений.
Назначьте уникальные, непересекающиеся блоки CIDR для каждой VNet.
Почему: Пиринг VNet требует непересекающихся адресных пространств. Планируйте рост, чтобы избежать перепроектирования.
Расчет необходимого размера подсети для заданного числа хостов.
Используйте нотацию CIDR, которая предоставляет необходимое количество хостов + 5 зарезервированных IP-адресов для Azure.
Почему: Azure резервирует первые четыре и последний IP-адрес в каждой подсети. Подсеть /24 (256 IP) предоставляет только 251 используемый IP.
Развертывание служб, таких как Azure Firewall, Gateway или Bastion.
Создайте выделенные подсети с определенными именами (например, AzureFirewallSubnet, GatewaySubnet, AzureBastionSubnet) и минимальными размерами (/26, /27, /26 соответственно).
Почему: Эти службы требуют выделенных, специально названных подсетей для внедрения своих ресурсов. Определение размера критически важно для функциональности и будущего масштабирования.
Включение разрешения имен между локальными сетями и зонами Azure Private DNS.
Разверните Azure DNS Private Resolver. Используйте входящую конечную точку для запросов из локальной среды в Azure и исходящую конечную точку с правилами пересылки для запросов из Azure в локальную среду.
Почему: Предоставляет управляемое решение PaaS для гибридного DNS без необходимости использования пользовательских DNS-виртуальных машин. Локальный DNS пересылает запросы на IP-адрес входящей конечной точки.
Пиринговая VNet не может разрешать записи в зоне Private DNS.
Создайте связь виртуальной сети от зоны Private DNS к пиринговой VNet.
Почему: Доступ к зоне Private DNS не является транзитивным через пиринг. Каждая VNet, требующая разрешения, должна иметь явную связь.
Предоставление статического, предсказуемого исходящего публичного IP-адреса для виртуальных машин в подсети для списков разрешений.
Свяжите Azure NAT Gateway с публичным IP-адресом или префиксом публичных IP-адресов с подсетью.
Почему: NAT Gateway отменяет все другие методы исходящего подключения для подсети, гарантируя, что весь трафик использует его статический(ие) публичный(ые) IP-адрес(а).
Обеспечение постоянства публичного IP-адреса для такого ресурса, как Load Balancer.
Используйте публичный IP-адрес Standard SKU со статической аллокацией.
Почему: Статические IP-адреса Standard SKU по умолчанию являются зонно-избыточными и сохраняются даже при остановке или удалении связанного ресурса.
Проектирование подсети для кластера AKS с использованием сети Azure CNI.
Рассчитайте потребности в IP-адресах как (количество узлов * максимальное количество подов на узел) + количество узлов. Выделите подсеть, которая может вместить это количество.
Почему: В Azure CNI каждый под получает IP-адрес непосредственно из подсети, что требует значительного выделения IP-адресов.
Направьте весь исходящий в интернет трафик из VNet-спицы через Azure Firewall в центральной VNet.
Создайте таблицу определяемых пользователем маршрутов (UDR) с маршрутом для 0.0.0.0/0, типом следующего перехода "Виртуальное устройство" и приватным IP-адресом Azure Firewall.
Почему: Это переопределяет системный маршрут по умолчанию в интернет, заставляя весь трафик проходить через брандмауэр для проверки.
Проверка трафика между двумя VNet-спицами с использованием Azure Firewall в центральной VNet.
В каждой спице создайте UDR для адресных пространств других спиц, указывающие на брандмауэр. В брандмауэре создайте сетевые правила для разрешения трафика.
Почему: Маршрутизация должна быть настроена в обеих спицах для отправки трафика на брандмауэр, который по умолчанию запрещает межвиртуальный сетевой трафик.
Развертывание отказоустойчивого кластера NVA для инспекции или маршрутизации трафика.
Используйте Azure Route Server. NVA подключаются к Route Server через BGP и объявляют маршруты. Route Server использует ECMP для распределения нагрузки.
Почему: Route Server упрощает динамическую маршрутизацию с NVA, устраняя сложное управление UDR и обеспечивая автоматическое переключение при сбое.
NVA отбрасывает трафик, который должен маршрутизировать.
Включите "IP forwarding" (пересылку IP) на сетевом интерфейсе (NIC) NVA.
Почему: Эта настройка на уровне Azure необходима, чтобы NIC мог принимать и пересылать трафик, не предназначенный для его собственного IP-адреса.
Глобальное распределение HTTP/S трафика на бэкенд с минимальной задержкой с помощью WAF и разгрузки SSL.
Используйте Azure Front Door.
Почему: Front Door использует маршрутизацию anycast для оптимальной производительности и интегрирует WAF, маршрутизацию URL и разгрузку SSL на границе сети.
Распределение трафика на глобальные конечные точки на основе DNS с переключением при сбое, управляемым проверкой работоспособности.
Используйте Azure Traffic Manager.
Почему: Traffic Manager - это балансировщик нагрузки на основе DNS. Используйте маршрутизацию "Производительность" для минимальной задержки или "Приоритет" для активно-пассивного переключения при сбое.
Обеспечение региональной балансировки нагрузки HTTP/S уровня 7 с WAF, завершением SSL и маршрутизацией на основе URL/хоста.
Разверните Azure Application Gateway v2.
Почему: Application Gateway - это региональный балансировщик нагрузки уровня 7. Используйте правила на основе пути для маршрутизации URL и многосайтовые прослушиватели для маршрутизации на основе хоста.
Балансировка нагрузки не-HTTP/S (TCP/UDP) трафика в пределах региона.
Используйте Azure Load Balancer (Standard SKU).
Почему: Azure Load Balancer - это региональный балансировщик нагрузки уровня 4. Он сохраняет исходный IP-адрес клиента и подходит для всех протоколов TCP/UDP.
Завершение SSL на Application Gateway, но повторное шифрование трафика для бэкенда.
Настройте прослушиватель HTTPS. В параметрах HTTP бэкенда установите протокол HTTPS и загрузите доверенный корневой сертификат бэкенд-серверов.
Почему: Гарантирует, что трафик шифруется на всем пути до бэкенда, даже при использовании самоподписанных сертификатов на бэкенд-серверах.
Балансировка нагрузки трафика для прослушивателя группы доступности SQL Server Always On.
Используйте внутренний Standard Load Balancer с включенной настройкой "Floating IP (Direct Server Return)" в правиле балансировки нагрузки.
Почему: Floating IP требуется для корректной работы прослушивателя SQL AG, так как он позволяет вторичному узлу напрямую отвечать клиентам после отработки отказа.
Балансировка нагрузки трафика для кластера NVA, который должен обрабатывать все протоколы и порты.
Используйте внутренний Standard Load Balancer с правилом балансировки нагрузки "HA Ports".
Почему: Правило HA Ports перенаправляет весь TCP и UDP трафик на всех портах, упрощая настройку для NVA, которым необходимо проверять все потоки трафика.
Настройка автоматического переключения при сбое между основным и вторичным источником веб-приложения.
Разместите оба источника в одной группе источников Front Door. Назначьте основному источнику приоритет 1, а второстепенному - более низкий приоритет (например, 2).
Почему: Front Door всегда отправляет трафик на наиболее приоритетный здоровый источник. Если основной источник не проходит проверки работоспособности, трафик автоматически переключается на следующий приоритет.
Обеспечение безопасного доступа по RDP/SSH к виртуальным машинам Azure без раскрытия портов управления в интернет.
Разверните Azure Bastion (Standard SKU для расширенных функций).
Почему: Bastion действует как управляемый jump box, предоставляя доступ через портал Azure по TLS. Это устраняет необходимость в публичных IP-адресах на виртуальных машинах для управления.
Доступ к службе Azure PaaS (например, SQL, Storage) с использованием приватного IP-адреса из вашей VNet.
Создайте Private Endpoint для ресурса PaaS. Интегрируйте его с Private DNS Zone для автоматического разрешения имен.
Почему: Private Endpoint проецирует службу PaaS в вашу VNet с приватным IP-адресом, обеспечивая по-настоящему приватное подключение. Отключение доступа к публичной сети для службы PaaS обеспечивает это.
Доступ к службам Azure PaaS из VNet через магистральную сеть Azure без использования публичных IP-адресов, но без управления выделенным приватным IP-адресом.
Включите Service Endpoint для конкретной службы (например, Microsoft.Storage) в исходной подсети.
Почему: Service Endpoints предоставляют прямой маршрут к службам PaaS из VNet, но не используют приватный IP-адрес в VNet. Это проще, но менее гибко, чем Private Endpoints.
Приватное предоставление службы, работающей в вашей VNet, потребителям в других VNet (возможно, другим арендаторам).
Разместите службу за Standard Load Balancer и создайте Private Link Service, указывающий на него.
Почему: Private Link Service является компонентом на стороне провайдера. Потребители создают Private Endpoint в своих VNet для приватного подключения к вашей службе.
Упрощение правил NSG для многоуровневого приложения, где виртуальные машины могут масштабироваться или менять IP-адреса.
Создайте группы безопасности приложений (ASG) для каждого уровня (например, Web, App, DB). Определите правила NSG, используя ASG в качестве источника/назначения.
Почему: ASG действуют как теги сетевых объектов для виртуальных машин, позволяя создавать правила на основе структуры приложения, а не на хрупких IP-адресах.
Трафик неожиданно блокируется, когда NSG применяются как к сетевому адаптеру (NIC), так и к его подсети.
Вспомните порядок оценки правил NSG. Входящий трафик: сначала правила NIC, затем правила подсети. Исходящий трафик: сначала правила подсети, затем правила NIC.
Почему: Запрет на любом уровне заблокирует трафик. Обе NSG должны разрешать поток трафика, чтобы он был успешным.
Автоматическая блокировка трафика на/с известных вредоносных IP-адресов и доменов.
Включите фильтрацию на основе Threat intelligence Azure Firewall в режиме "Предупреждать и запрещать".
Почему: Это использует данные аналитики угроз Microsoft для обеспечения управляемой, актуальной защиты от известных угроз с нулевой конфигурацией.
Проверка зашифрованного HTTPS трафика на наличие угроз, таких как вредоносное ПО.
Используйте Azure Firewall Premium. Включите инспекцию TLS в политике и разверните промежуточный сертификат ЦС, которому клиенты должны доверять.
Почему: Это премиум-функция, которая выполняет расшифровку методом "человек посередине" для проверки трафика, что критически важно для модели безопасности с нулевым доверием.
Разрешить исходящий доступ к сложным службам Microsoft, таким как Windows Update, без поддержки списков IP-адресов.
В Azure Firewall создайте правило приложения, используя FQDN Tags (например, "WindowsUpdate", "AzureBackup").
Почему: Microsoft управляет FQDN, связанными с этими тегами, упрощая управление правилами брандмауэра для динамических служб.
Защита общедоступных приложений от объемных DDoS-атак и получение доступа к поддержке быстрого реагирования.
Включите DDoS Network Protection (ранее Standard) в VNet.
Почему: Обеспечивает адаптивную настройку, телеметрию атак, отчеты о снижении угроз и доступ к команде быстрого реагирования DDoS, чего нет в бесплатной базовой защите.
Диагностика сбоя подключения и определение точного перехода, где трафик отбрасывается.
Используйте Network Watcher > Connection Troubleshoot.
Почему: Он выполняет сквозную проверку, показывая полный путь от узла к узлу и выявляя сбои из-за NSG, UDR или других сетевых проблем.
Быстрая проверка, разрешает или запрещает правило NSG трафик к/от виртуальной машины.
Используйте Network Watcher > IP Flow Verify.
Почему: Это наиболее прямой инструмент для проверки конкретного 5-кортежа на соответствие правилам NSG и определения того, какое правило отвечает за результат.
Журналирование всего разрешенного и запрещенного сетевого трафика для соответствия требованиям и анализа.
Включите журналы потоков NSG и загрузите их в Traffic Analytics (через рабочую область Log Analytics).
Почему: Журналы потоков NSG предоставляют необработанные данные о трафике. Traffic Analytics обогащает и визуализирует эти данные для выявления шаблонов трафика, наиболее активных узлов и угроз безопасности.
Подключение локальной сети к Azure с помощью приватного, выделенного соединения, обеспечивающего предсказуемую задержку и высокую пропускную способность.
Создайте канал Azure ExpressRoute.
Почему: ExpressRoute полностью обходит публичный интернет, обеспечивая более надежное, быстрое и низколатентное соединение, чем Site-to-Site VPN.
Выбор правильного пиринга ExpressRoute для доступа к ресурсам Azure.
Используйте приватный пиринг Azure для подключения к VNet. Используйте пиринг Microsoft для доступа к публичным службам PaaS и Microsoft 365.
Почему: Два типа пиринга предоставляют доступ к разным наборам ресурсов. Пиринг Microsoft требует публичных IP-адресов, NAT и фильтров маршрутов.
Разрешить VNet-спицам доступ к локальным сетям через центральный VPN-шлюз или шлюз ExpressRoute в центральной VNet.
На пиринге от центра к спице включите "Разрешить транзит шлюза". На пиринге от спицы к центру включите "Использовать удаленные шлюзы".
Почему: Эта двухкомпонентная конфигурация позволяет спицам использовать шлюз центра, централизуя гибридное подключение.
Настройка VPN типа Site-to-Site в качестве резервного для подключения ExpressRoute.
Разверните шлюзы ExpressRoute и VPN. По умолчанию пути ExpressRoute предпочтительнее путей VPN для одних и тех же префиксов.
Почему: Azure автоматически отдает предпочтение ExpressRoute из-за более высокого веса маршрута по умолчанию. Если канал ExpressRoute выйдет из строя, BGP отзовет маршруты, и трафик переключится на VPN.
Влияние на трафик для предпочтения одного канала ExpressRoute другому для активно/пассивной избыточности.
Используйте BGP AS Path prepending. Добавьте свой собственный ASN несколько раз в объявления маршрутов на резервном канале, чтобы его путь казался длиннее.
Почему: BGP предпочитает кратчайший путь AS. Это делает основной канал предпочтительным путем с автоматическим переключением на резервный, если основной путь будет отозван.
Подключение двух локальных площадок через магистральную сеть Microsoft с использованием их существующих каналов ExpressRoute.
Включите ExpressRoute Global Reach.
Почему: Global Reach связывает два канала ExpressRoute, создавая частную WAN через сеть Microsoft без необходимости прохождения трафика через Azure VNet.
Упрощение управления глобальной сетью, соединяющей множество филиалов и VNet.
Разверните Azure Virtual WAN.
Почему: Virtual WAN предоставляет управляемую услугу "звезда" с автоматическим транзитивным подключением "любой-к-любому", маршрутизацией и интеграцией со службами безопасности (защищенный хаб).
В Virtual WAN централизованно проверяйте весь межвиртуальный сетевой трафик, межфилиальный трафик и трафик, направленный в интернет.
Разверните защищенный виртуальный хаб (с Azure Firewall). Настройте намерение маршрутизации для отправки приватного и интернет-трафика через брандмауэр.
Почему: Намерение маршрутизации упрощает проектирование трафика в vWAN, автоматически программируя маршруты для принудительной отправки трафика через поставщика безопасности без ручных UDR.
Обеспечение отказоустойчивого VPN-подключения к Azure.
Разверните VPN Gateway в активно-активной конфигурации. Это требует двух публичных IP-адресов и локального устройства, способного устанавливать два туннеля.
Почему: Обеспечивает избыточность на уровне экземпляра в пределах региона Azure. Для межзоновой избыточности используйте зонно-избыточные (AZ) SKU.
Выбор протокола Point-to-Site VPN для широкой совместимости клиентов без дополнительного программного обеспечения.
Используйте IKEv2. Для максимальной совместимости, включая старые устройства, используйте OpenVPN.
Почему: IKEv2 нативно поддерживается на современных Windows, macOS и iOS. SSTP только для Windows. OpenVPN требует клиента, но широко поддерживается.
Перенаправление всего исходящего в интернет трафика с виртуальных машин Azure на локальное устройство безопасности.
Из локальной сети объявите маршрут по умолчанию (0.0.0.0/0) через BGP по соединению ExpressRoute или VPN.
Почему: Это объявление BGP переопределяет маршрут Azure по умолчанию в интернет, принудительно направляя трафик обратно в локальную сеть для проверки.