Microsoft Azure Solutions Architect Expert
Последняя проверка: май 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене AZ-305. Читайте сверху вниз или переходите к нужному разделу.
Гибридная аутентификация, при которой хэши паролей должны оставаться локально, с отказоустойчивостью.
Azure AD Connect со сквозной аутентификацией (PTA) и синхронизацией хэшей паролей (PHS), включенной в качестве резервной копии.
Почему: PTA сохраняет хэши локально, проверяя их по локальному AD. PHS обеспечивает отказоустойчивость аутентификации, если локальный AD или агент Connect недоступны.
Реализовать Zero Trust, обеспечивая детальный контроль доступа на основе пользователя, местоположения, состояния устройства и риска.
Политики условного доступа Microsoft Entra, объединяющие именованные расположения, соответствие устройств (Intune) и риск входа (Identity Protection) с элементами управления предоставлением доступа, такими как MFA.
Почему: Условный доступ — это механизм обеспечения Zero Trust, оценивающий несколько сигналов для каждого запроса перед предоставлением доступа. Единая политика не может применять различные элементы управления к различным условиям.
Применять согласованные политики (например, тегирование, разрешенные регионы) для десятков или сотен подписок.
Иерархия групп управления с инициативами Azure Policy, назначенными на уровне корневой или родительской группы управления.
Почему: Группы управления обеспечивают область управления выше подписок, позволяя наследовать политики. Инициативы объединяют несколько политик для упрощенного назначения.
Предоставление администраторам привилегированного доступа "точно в срок" (JIT) с рабочими процессами утверждения и аудитом.
Microsoft Entra Privileged Identity Management (PIM), чтобы пользователи имели право на роли вместо постоянной активности.
Почему: PIM обеспечивает принцип наименьших привилегий, требуя от пользователей активации ролей на ограниченный период времени, с опциональным MFA, обоснованием и утверждением, создавая полный журнал аудита.
Собирать журналы со всех ресурсов Azure в нескольких подписках для централизованного анализа и запросов.
Единая централизованная рабочая область Log Analytics с RBAC на основе контекста ресурса для контроля доступа.
Почему: Централизованная рабочая область позволяет выполнять запросы между подписками, упрощает управление и предотвращает дублирование данных. RBAC на основе контекста ресурса гарантирует, что пользователи запрашивают журналы только из ресурсов, к которым у них есть доступ.
Ресурс Azure (например, App Service, Function, VM) должен безопасно получать доступ к другим ресурсам Azure (Key Vault, SQL, Storage) без хранимых учетных данных.
Назначьте управляемое удостоверение (назначаемое системой или пользователем) вычислительному ресурсу и предоставьте ему роли RBAC на целевых ресурсах.
Почему: Управляемые удостоверения устраняют управление учетными данными (секреты, сертификаты), автоматически обрабатывая получение и ротацию токенов. Используйте назначаемое пользователем удостоверение для совместного использования удостоверения несколькими ресурсами.
Автоматически исправлять существующие, несоответствующие ресурсы Azure, идентифицированные Azure Policy.
Используйте эффект политики "DeployIfNotExists" или "Modify". Для существующих ресурсов необходимо создать задачу исправления для назначения политики, что требует управляемого удостоверения с достаточными разрешениями.
Почему: Политики с этими эффектами по умолчанию применяются только к новым/обновленным ресурсам. Задача исправления требуется для сканирования и исправления существующих несоответствующих ресурсов.
Обеспечить обязательные теги для всех ресурсов и автоматически наследовать теги (например, CostCenter) от родительской группы ресурсов.
Используйте Azure Policy с эффектом "Deny" для обязательных тегов и отдельную политику с эффектом "Modify" для наследования тегов от группы ресурсов, если они отсутствуют.
Почему: Deny обеспечивает соответствие при создании. Эффект Modify автоматизирует распространение тегов, уменьшая ручные усилия и обеспечивая согласованность.
Мониторить многоуровневое или микросервисное приложение для сквозной трассировки транзакций и выявления узких мест в производительности.
Инструментируйте все службы с помощью Application Insights. Используйте карту приложений для визуализации зависимостей и распределенную трассировку для сквозного анализа запросов.
Почему: Application Insights — это нативное решение APM, которое автоматически коррелирует телеметрию между компонентами для предоставления унифицированного представления транзакции, выявляя проблемы с задержкой.
Управлять доступом для внешних партнеров, включая запросы, утверждения, ограниченный по времени доступ и периодические проверки.
Управление правами Microsoft Entra ID Governance. Создайте пакеты доступа, которые объединяют ресурсы, определяют рабочие процессы утверждения, устанавливают политики истечения срока действия и планируют проверки доступа.
Почему: Обеспечивает полный, автоматизированный жизненный цикл для внешнего доступа, снижая административные накладные расходы и риски безопасности по сравнению с ручным управлением гостевыми учетными записями.
Поставщику управляемых услуг или центральной ИТ-команде необходимо управлять ресурсами в нескольких Azure AD-клиентах клиентов/отделов.
Azure Lighthouse. Подключите подписки клиентов, чтобы предоставить управляющему клиенту делегированный доступ с определенными ролями RBAC.
Почему: Lighthouse предоставляет единую панель управления для межклиентского управления без переключения каталогов или управления гостевыми учетными записями, при этом клиент сохраняет полный контроль и владение.
Обеспечить безопасный удаленный доступ к локальному веб-приложению для внешних пользователей без VPN или exposing приложения в интернет.
Microsoft Entra Application Proxy.
Почему: Application Proxy использует легкий локальный коннектор, который устанавливает исходящее соединение с Azure. Он действует как обратный прокси, позволяя предварительную аутентификацию Entra ID и безопасный доступ без входящих правил брандмауэра или публичного IP-адреса на приложении.
Глобально распределенное приложение требует базу данных с задержкой чтения/записи менее 10 мс, гибкой схемой и доступностью 99,999%.
Azure Cosmos DB с включенной записью в несколько регионов. Ключ секционирования должен быть выбран для равномерного распределения нагрузки.
Почему: Cosmos DB специально разработан для глобального распределения с готовой записью в несколько регионов, обеспечивая гарантированно низкую задержку и высочайший SLA доступности. Другие базы данных требуют ручной репликации и не могут соответствовать задержке записи.
Прием большого объема телеметрии IoT в Cosmos DB, обеспечивая эффективные запросы по устройству и автоматическое архивирование старых данных.
Используйте `/deviceId` в качестве ключа секционирования. Настройте TTL на контейнере для автоматического удаления старых документов. Используйте Change Feed для захвата данных перед удалением для архивирования в холодное хранилище (например, Blob Storage).
Почему: Секционирование по `deviceId` размещает данные для одного устройства, делая запросы эффективными. TTL обеспечивает бесплатное, автоматическое удаление. Change Feed позволяет создать реактивный конвейер архивации.
Выберите экономически эффективную модель ценообразования Azure SQL DB для рабочей нагрузки с непредсказуемым, всплесковым трафиком и значительными периодами простоя.
Используйте модель на основе vCore с уровнем вычислений Serverless.
Почему: Serverless автоматически масштабирует вычисления в зависимости от спроса и автоматически приостанавливается в периоды простоя, взимая плату только за используемые вычисления в секунду. Это гораздо более экономично для прерывистых рабочих нагрузок, чем заранее выделенные уровни.
Решение для хранения данных для крупномасштабной платформы аналитики данных, требующее иерархического пространства имен и ACL на уровне каталогов.
Azure Data Lake Storage Gen2 (учетная запись с включенным иерархическим пространством имен).
Почему: ADLS Gen2 оптимизирован для аналитики больших данных, сочетая масштабируемость объектного хранилища с истинной иерархической файловой системой и POSIX-совместимыми ACL для гранулированной безопасности.
Выберите избыточность хранилища на основе многоуровневых требований: максимальная долговечность с доступом на чтение, только для DR и защита от сбоев центра обработки данных в регионе.
1. Макс. долговечность/чтение: RA-GZRS. 2. Только для DR: GRS. 3. В регионе: ZRS.
Почему: Сопоставьте опцию избыточности с конкретными RPO/RTO и потребностями в доступе. RA-GZRS - самый высокий уровень. GRS предназначен только для аварийного переключения. ZRS защищает от сбоев центра обработки данных в пределах региона.
Запрашивать большие структурированные данные в хранилище данных и полуструктурированные данные в озере данных с использованием унифицированной аналитической платформы.
Azure Synapse Analytics. Используйте выделенный пул SQL для структурированных данных и бессерверный пул SQL для специальных запросов к озеру данных.
Почему: Этот гибридный подход оптимизирует как производительность, так и стоимость. Выделенный пул обеспечивает высокую производительность для управляемого хранилища данных, в то время как бессерверный пул предоставляет доступ с оплатой за запрос к необработанным данным в озере.
Решение для кэширования состояния сеанса и данных о продуктах, требующее >100 ГБ памяти и высокой доступности.
Azure Cache for Redis Enterprise или Premium с включенным кластеризацией.
Почему: Кластеризация в уровнях Premium/Enterprise позволяет кэшу масштабироваться за пределы ограничений памяти одного узла путем сегментирования данных по нескольким узлам, а также улучшает пропускную способность.
Архитектура базы данных для SaaS-приложения, которая изолирует клиентов, оптимизируя затраты для множества небольших, всплесковых рабочих нагрузок.
Azure SQL Elastic Pools. Группируйте клиентов в пулы для совместного использования ресурсов, с выделенными базами данных для больших клиентов с "шумными соседями".
Почему: Эластичные пулы обеспечивают экономические преимущества совместного использования ресурсов, одновременно применяя ограничения производительности для каждой базы данных, предлагая баланс между проблемой "шумного соседа" и высокой стоимостью одной базы данных на клиента.
Миграция сложной локальной базы данных SQL Server, использующей такие функции, как SQL Agent, кросс-базовые запросы и CLR, на службу PaaS.
Azure SQL Managed Instance.
Почему: SQL Managed Instance предлагает почти 100% совместимость с локальным движком SQL Server, поддерживая функции на уровне экземпляра, которые Azure SQL Database не поддерживает. Это идеально подходит для lift-and-shift с минимальными изменениями кода.
Убедитесь, что все данные и управляемые клиентом ключи шифрования остаются в пределах определенной географической границы (например, ЕС).
Разверните все ресурсы в регионах внутри границы. Используйте Azure Policy с эффектом "Allowed locations" для обеспечения этого. Храните управляемые клиентом ключи (CMK) в Azure Key Vault, также расположенном в пределах границы.
Почему: Для соблюдения строгих правил суверенитета данных требуется комбинация физического местоположения развертывания, принудительного применения на основе политик и резидентности ключей.
Обнаруживать, классифицировать и отслеживать происхождение данных в гибридной среде данных (Azure, локально, другие облака).
Microsoft Purview.
Почему: Purview предоставляет унифицированное решение для управления данными с автоматическим сканированием, бизнес-глоссарием, классификацией и отслеживанием происхождения для широкого спектра источников данных.
Храните данные (например, финансовые записи) в неизменяемом, немодифицируемом (WORM) состоянии в течение определенного периода хранения.
Azure Blob Storage с неизменяемой политикой на основе времени для контейнера, которая затем блокируется.
Почему: Заблокированные неизменяемые политики предотвращают удаление или изменение больших двоичных объектов любым пользователем, включая администраторов, до истечения срока хранения, отвечая строгим требованиям соответствия нормативным актам.
Разработайте решение DR для веб-приложения (App Service + SQL DB) с RPO в минуты и RTO менее часа.
Группа автоматического переключения Azure SQL Database, вторичное развертывание App Service и Azure Front Door или Traffic Manager для маршрутизации.
Почему: Этот шаблон решает DR для каждого уровня. Группа переключения SQL обрабатывает репликацию и переключение данных. Предварительно развернутый App Service позволяет избежать задержек развертывания. Глобальный маршрутизатор (Front Door/Traffic Manager) направляет трафик в активный регион.
Композитный SLA последовательного приложения (A -> B -> C) слишком низок. Как его улучшить?
Определите компонент с наименьшим индивидуальным SLA ("слабое звено") и сделайте его избыточным, развернув параллельные экземпляры (например, в разных регионах или зонах с балансировщиком нагрузки).
Почему: Композитный SLA для последовательной цепочки рассчитывается путем умножения SLA (SLA_A * SLA_B * SLA_C). Добавление параллельных экземпляров к компоненту улучшает его эффективный SLA, что оказывает наибольшее положительное влияние на композитный.
Достичь максимально возможной доступности для виртуальных машин в одном регионе Azure.
Разверните несколько виртуальных машин во всех доступных зонах доступности в регионе.
Почему: Зоны доступности — это физически отдельные центры обработки данных с независимым питанием, охлаждением и сетевой инфраструктурой. Это защищает от сбоев на уровне центра обработки данных и обеспечивает высочайший SLA в регионе - 99,99%.
Предоставить решение для аварийного восстановления для локальных виртуальных машин VMware или Hyper-V в Azure.
Azure Site Recovery (ASR). Настройте репликацию в Azure, создайте планы восстановления для оркестрированного переключения и используйте тестовые переключения для неразрушающих учений по DR.
Почему: ASR — это специально разработанная служба Azure для репликации DR локальных (и Azure) виртуальных машин, обеспечивающая непрерывную репликацию, оркестрированное восстановление и возможности изолированного тестирования.
Достичь максимально возможной доступности в регионе для Azure SQL Database с нулевой потерей данных (RPO=0) и возможностью масштабирования чтения.
Используйте уровень обслуживания Business Critical с включенной зонной избыточностью.
Почему: Уровень Business Critical использует группу доступности Always On с синхронной репликацией между несколькими репликами, обеспечивая RPO равный 0. Зонная избыточность размещает реплики в разных AZ для SLA 99,995%. Он включает читаемую вторичную реплику.
Глобальное приложение должно обслуживать пользователей из ближайшего региона и автоматически и мгновенно переключаться на другой регион.
Используйте шаблон активного-активного развертывания в нескольких регионах с Azure Front Door для маршрутизации на основе задержки и отказоустойчивости на основе проверки работоспособности.
Почему: Azure Front Door обеспечивает глобальную любую маршрутизацию к бэкенду с наименьшей задержкой. Его проверки работоспособности обнаруживают региональные сбои и автоматически перенаправляют трафик в здоровые регионы в течение нескольких секунд, обеспечивая бесшовную активно-активную архитектуру.
Резервное копирование приложений с сохранением состояния на AKS, включая как определения объектов Kubernetes, так и данные постоянных томов.
Используйте Azure Backup для AKS.
Почему: Azure Backup для AKS — это нативное решение, которое обеспечивает интегрированное, основанное на политиках резервное копирование как состояния кластера (etcd), так и данных постоянных томов (через снимки CSI) в безопасное, централизованное хранилище резервных копий.
Защитите резервные копии от случайного или злонамеренного удаления, в том числе администраторами, для соблюдения нормативных требований.
Включите неизменяемые хранилища на хранилище Azure Backup или Recovery Services.
Почему: Неизменяемость — это настройка на уровне хранилища, которая гарантирует, что точки восстановления резервных копий, после создания, не могут быть удалены кем-либо до истечения срока их действия, обеспечивая высочайший уровень защиты резервных копий.
Среда службы приложений версии 3 (ASEv3) размещает критически важное приложение в одном регионе и требует решения для аварийного восстановления в другом регионе.
Разверните вторую ASEv3 в регионе DR. Используйте Azure Front Door для глобальной балансировки нагрузки и отказоустойчивости. Реплицируйте данные с использованием соответствующей технологии (например, группы автоматического переключения SQL).
Почему: ASEv3 — это региональные развертывания. Для DR необходимо развернуть вторую ASE и использовать глобальный маршрутизатор, такой как Front Door, для управления трафиком. ASR не используется для DR App Service.
Разработать масштабируемую сеть для предприятия с централизованным подключением (ExpressRoute/VPN), общими службами и изоляцией рабочих нагрузок.
Топология "звезда". Виртуальная сеть-концентратор содержит шлюз, Azure Firewall и другие общие службы. Виртуальные сети-лучи содержат рабочие нагрузки приложений и объединены с концентратором.
Почему: Это стандартный, рекомендуемый корпоративный шаблон. Он централизует безопасность и подключение, снижая затраты и сложность, в то время как лучи обеспечивают надежную изоляцию рабочих нагрузок.
Глобальное веб-приложение требует балансировки нагрузки уровня 7, брандмауэра веб-приложений (WAF), выгрузки SSL и маршрутизации на основе URL-адресов.
Azure Front Door (Standard или Premium).
Почему: Front Door — это современный облачный CDN и глобальный балансировщик нагрузки, который объединяет эти возможности в единую службу, обеспечивая лучшую производительность и более простое управление, чем комбинация Traffic Manager с региональными шлюзами приложений.
Разработать кластер AKS производственного уровня для нескольких команд с различными типами рабочих нагрузок (интенсивные для ЦП, ГП, памяти).
Используйте выделенный пул системных узлов и несколько пулов пользовательских узлов с различными SKU ВМ (например, F-серии для ЦП, E-серии для памяти, N-серии для ГП). Используйте автомасштабирование кластера и включите уровень Standard/Premium для SLA времени безотказной работы.
Почему: Несколько пулов узлов позволяют подобрать подходящее оборудование для соответствующей рабочей нагрузки для повышения производительности и экономичности. Разделение системных подов улучшает стабильность. Уровень Standard/Premium требуется для SLA с финансовой поддержкой.
Управляемый событиями бессерверный рабочий процесс требует времени выполнения, превышающего 10-минутное ограничение плана потребления Functions.
Используйте Azure Functions на плане Premium или плане App Service, либо используйте Azure Durable Functions для оркестрации.
Почему: План Premium поддерживает выполнение до 60 минут (по умолчанию 30) и избегает "холодных" запусков. Durable Functions идеально подходят для оркестрации долгосрочных, с сохранением состояния рабочих процессов, которые могут включать взаимодействие с человеком или длительные ожидания.
Выберите службу обмена сообщениями для системы уведомлений о событиях с "веерной" рассылкой по сравнению с надежной, упорядоченной системой обработки команд.
Используйте Azure Event Grid для "веерной", реактивной обработки событий. Используйте очереди Azure Service Bus (с сессиями для упорядочивания) для надежной, транзакционной обработки команд.
Почему: Event Grid — это легковесный, основанный на push-уведомлениях сервис маршрутизации событий, оптимизированный для реактивного программирования. Service Bus — это надежный брокер сообщений с такими функциями, как FIFO (сессии), "мертвые" сообщения и транзакции для корпоративного обмена сообщениями.
Безопасно предоставить API, работающий в частной виртуальной сети, внешним партнерам, с политиками ограничения скорости и аутентификации.
Разверните Azure API Management (APIM) в режиме внутренней виртуальной сети, перед которой находится Azure Application Gateway с WAF для публичного входящего трафика.
Почему: Этот шаблон обеспечивает эшелонированную защиту. APIM в виртуальной сети может получить доступ к частному бэкэнду. App Gateway завершает SSL, проверяет трафик с помощью WAF и перенаправляет его в частный экземпляр APIM. Политики APIM обрабатывают аутентификацию, ограничения скорости и т.д.
Подключить сотни филиалов и виртуальных сетей по всему миру с автоматизированным, "любой-к-любому" подключением.
Azure Virtual WAN.
Почему: Virtual WAN — это управляемое решение Microsoft для крупномасштабной, глобальной транзитной сети. Оно автоматизирует сложную маршрутизацию и предоставляет унифицированный хаб для подключения VPN, ExpressRoute и списков виртуальных сетей.
Запустить крупномасштабное, параллельное пакетное задание (например, моделирование CFD), которое требует тысяч ядер и низколатентной MPI-коммуникации.
Azure Batch с пулом виртуальных машин с поддержкой InfiniBand (например, серии HB) с использованием ценообразования с низким приоритетом (Spot).
Почему: Azure Batch — это планировщик заданий, разработанный для HPC. Виртуальные машины с поддержкой InfiniBand обеспечивают высокопроизводительную, низколатентную RDMA-сеть, необходимую для MPI. Виртуальные машины с низким приоритетом значительно снижают стоимость для отказоустойчивых рабочих нагрузок.
Приложение в виртуальной сети должно получать доступ к службам PaaS (SQL, Storage) без прохождения трафика через публичный интернет.
Создайте частные конечные точки для служб PaaS. Это дает службе частный IP-адрес в вашей виртуальной сети.
Почему: Частные конечные точки — самый безопасный метод частного подключения к PaaS. Они гарантируют, что трафик остается в магистрали Microsoft и позволяет полностью отключить публичную конечную точку службы PaaS.
Разместить современное одностраничное приложение (SPA) с бессерверным API-бэкендом, интеграцией CI/CD и пользовательским доменом.
Azure Static Web Apps.
Почему: Это специально разработанный, оптимизированный сервис для этого конкретного шаблона. Он объединяет хостинг статического контента, интегрированные функции Azure для API, интеграцию с GitHub/Azure DevOps и управляемые пользовательские домены с бесплатными SSL-сертификатами.
Управление и применение политик (Azure Policy) к серверам, работающим локально и в других облаках (например, AWS) из Azure.
Установите агент Azure Arc на не-Azure серверы, чтобы спроецировать их как серверы с поддержкой Azure Arc.
Почему: Azure Arc расширяет панель управления Azure на любую инфраструктуру. Как только сервер становится Arc-enabled, им можно управлять с помощью Azure Policy, Monitor, Defender for Cloud и т.д., так же, как и нативной виртуальной машиной Azure.
Постепенно переносить функциональность из устаревшего монолитного приложения в новые микросервисы без "большого взрыва" перехода.
Примените шаблон Strangler Fig с использованием обратного прокси, такого как Azure API Management или Application Gateway.
Почему: Обратный прокси перехватывает вызовы к монолиту и выборочно маршрутизирует трафик для определенных функций к новым микросервисам. Со временем прокси "душит" монолит, перенаправляя все больше и больше трафика, пока старая система не будет выведена из эксплуатации.
Виртуальные машины находятся в виртуальной сети с принудительным туннелированием (весь интернет-трафик маршрутизируется локально), но они не могут получить доступ к службам Azure PaaS.
Принудительное туннелирование нарушает прямой доступ к общедоступным конечным точкам Azure. Используйте служебные конечные точки или частные конечные точки для доступа к PaaS. В качестве альтернативы, добавьте UDR для конкретных тегов службы Azure со следующим переходом "Интернет", чтобы обойти туннель.
Почему: Службы PaaS имеют общедоступные конечные точки. Принудительное туннелирование отправляет этот трафик локально. Вы должны создать путь исключения, либо сделав службу PaaS частной (конечные точки), либо создав конкретные исключения маршрутов (UDR с тегами службы).
Сети типа "звезда" необходимо разрешать локальные DNS-имена из Azure и частные зоны Azure DNS из локальной среды.
Разверните Azure DNS Private Resolver в виртуальной сети-концентраторе. Настройте входящую конечную точку для локального разрешения Azure DNS и исходящую конечную точку с наборами правил пересылки для разрешения локального DNS из Azure.
Почему: Это современное PaaS-решение для гибридного разрешения DNS, заменяющее необходимость управления пользовательскими виртуальными машинами DNS-серверов. Оно нативно интегрируется с частными зонами DNS и локальными пересыльщиками DNS.
Несколько виртуальных сетей нуждаются в предсказуемом, статическом публичном IP-адресе для всего исходящего трафика для добавления в белый список внешними службами.
В топологии "звезда" маршрутизируйте весь исходящий трафик (0.0.0.0/0) из "лучей" через Azure Firewall или NAT Gateway в виртуальной сети "концентратора".
Почему: Централизация исходящего трафика в "концентраторе" гарантирует, что весь исходящий трафик использует публичные IP-адреса брандмауэра/NAT Gateway "концентратора", упрощая управление и внешнее добавление в белый список. NAT Gateway проще для чистого SNAT, в то время как Firewall добавляет проверку безопасности.
Обработка конфиденциальных данных таким образом, чтобы они были зашифрованы даже при использовании в памяти, защищая их от облачного оператора.
Используйте виртуальные машины Azure Confidential Computing (серии DCsv3/ECsv3) с Intel SGX или AMD SEV-SNP для выполнения кода в аппаратной доверенной среде выполнения (TEE) или зашифрованной памяти.
Почему: Конфиденциальные вычисления решают проблему "данных в использовании", которую не решают традиционные шифрование в покое и в пути. Они обеспечивают проверяемую изоляцию на аппаратном уровне.
Поставщику SaaS необходимо предоставить свой сервис, работающий в его виртуальной сети, клиенту в виртуальной сети клиента, полностью через частную сеть Azure.
Поставщик создает Azure Private Link Service на своем Standard Load Balancer. Клиент создает Private Endpoint в своей виртуальной сети, который подключается к сервису.
Почему: Private Link — это определенный шаблон для безопасного, частного межклиентского доступа к службам. Он позволяет избежать доступа через публичный интернет, проблем с перекрытием IP-адресов и сложных конфигураций пиринга виртуальных сетей.
