Amazon ANS-C01: Гибридная связность: VPN и Direct Connect — Руководство по подготовке
Часть AWS Advanced Networking Specialty ANS-C01 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.
Основные концепции
Гибридное подключение в AWS — это комбинация частных выделенных сетевых каналов и зашифрованных IP-туннелей для расширения локальных сетей в облако AWS. Site-to-Site VPN предоставляет туннели IPsec (IKEv1/IKEv2), которые терминируются на шлюзе виртуальной частной сети (Virtual Private Gateway, VGW) или на Transit Gateway. Для обеспечения отказоустойчивости AWS создает два независимых туннеля на каждое VPN-соединение и поддерживает BGP для динамической маршрутизации или, при необходимости, статические маршруты. Client VPN — это управляемая конечная точка на основе OpenVPN, которая поддерживает взаимную аутентификацию по сертификатам (ACM Private CA или загруженные клиентские сертификаты) или федерацию SAML для идентификации пользователей, распространение маршрутов в VPC или Transit Gateway, а также раздельное туннелирование на стороне клиента для ограничения трафика, поступающего в AWS.
AWS Direct Connect предлагает выделенное физическое соединение между вашими помещениями и AWS. Соединения могут быть выделенными (предоставляются AWS) или размещенными (предоставляются партнером); вы можете объединять несколько соединений с помощью группы агрегации каналов (Link Aggregation Group, LAG), чтобы представить их как единый логический интерфейс и увеличить пропускную способность. Direct Connect поддерживает частные виртуальные интерфейсы (private VIF) для VPC, публичные VIF для публичных конечных точек AWS и транзитные VIF для подключения к Direct Connect Gateway для межрегиональной связи или подключения к Transit Gateway. Для защиты данных на физическом канале в поддерживаемых местоположениях доступен MACsec, обеспечивающий шифрование фреймов на уровне 2 между пограничным устройством клиента и пограничным устройством AWS; при этом шифрование при передаче на уровне 3 остается зоной ответственности конечных точек IPsec или TLS.
Надежность и маршрутизация требуют явного контроля над аварийным переключением и выбором пути. Атрибуты BGP (local-preference, добавление AS path) используются для предпочтения Direct Connect перед VPN для достижения низкой задержки и высокой пропускной способности, при этом Site-to-Site VPN или вторичное соединение DX выступают в качестве автоматического резервного канала. Когда требуется сквозное шифрование TLS, или когда приложениям необходимо сохранение исходного IP-адреса клиента и очень большое количество долгоживущих TCP-соединений (например, gRPC через TLS на порту 443), используйте шаблоны сквозной передачи TCP/TLS (passthrough), такие как Network Load Balancer (NLB) или прямые публичные конечные точки на узлах EKS с соответствующими мерами безопасности. Если терминирование на границе сети приемлемо, Application Load Balancer (ALB) поддерживает HTTP/2 и gRPC, терминирует TLS и вставляет заголовки X-Forwarded-For, чтобы бэкенд-поды могли регистрировать IP-адреса клиентов.
Ключевые сервисы и конфигурация
При создании Site-to-Site VPN вы используете API EC2 CreateVpnConnection (aws ec2 create-vpn-connection) и обычно присоединяете полученное соединение vpn-connection к шлюзу виртуальной частной сети (create-vpn-gateway и attach-vpn-gateway) или к transit gateway, указывая transit-gateway-id. Настройте устройство клиентского шлюза с помощью сгенерированных параметров туннеля: версия IKE, алгоритмы шифрования (AES-GCM), хеширование (SHA-2), группа Диффи-Хеллмана, время жизни и предварительно согласованный ключ. Для динамической маршрутизации включите BGP и настройте ASN и IP BGP-соседа; для более быстрого обнаружения сбоев на уровне маршрутизатора используйте BFD, если он поддерживается между локальными устройствами и пограничным оборудованием AWS.
Конечные точки Client VPN создаются с помощью API EC2 CreateClientVpnEndpoint (aws ec2 create-client-vpn-endpoint). Вы предоставляете сертификат сервера из ACM, выбираете опцию аутентификации (сертификат или SAML) и связываете конечную точку с одной или несколькими подсетями VPC для создания эластичных сетевых интерфейсов. Используйте authorize-client-vpn-ingress, чтобы открыть разрешенные сети для каждого правила авторизации, и create-client-vpn-route, чтобы добавить маршруты в VPC. Для большого количества пользователей и условного доступа интегрируйте Client VPN с AWS Directory Service или поставщиками удостоверений SAML, и масштабируйте количество одновременных подключений, назначая достаточные диапазоны CIDR-адресов конечной точке Client VPN.
Для подготовки Direct Connect используются API Direct Connect, такие как create-connection, или, в случае партнерских соединений, партнер предоставляет размещенное соединение, а вы используете API allocate-hosted-connection или accept-virtual-interface. Чтобы агрегировать физические каналы, вызовите create-lag, а затем create-private-virtual-interface или create-transit-virtual-interface для подключения виртуального интерфейса к VPC или Direct Connect Gateway. Для MACsec обратитесь к партнеру или в портал заказов AWS, чтобы запросить MACsec для соединения; конфигурация включает обмен ключами и согласование набора шифров на граничном коммутаторе клиента, а операционные команды обычно согласовываются во время подготовки. Для архитектур с несколькими VPC предпочтительнее использовать Direct Connect Gateway с транзитным VIF для подключения к Transit Gateway — это лучше масштабируется, чем создание множества private VIF, и позволяет централизовать маршрутизацию через таблицы маршрутов TGW.
Шаблоны проектирования и компромиссы
Выбирайте архитектуру active-active для высокой пропускной способности и малого времени переключения при сбое, размещая два подключения Direct Connect в разных местоположениях, анонсируя одинаковые префиксы по BGP и используя LAG для агрегации каналов на одной площадке. Конфигурация active-active с BGP multipath обеспечивает превосходную производительность и настоящую балансировку нагрузки; однако для этого требуется симметричная маршрутизация, совместимая локальная реализация BGP и тщательная настройка AS-path и local-preference. Используйте Site-to-Site VPN в качестве автоматического резервного подключения в режиме active-passive, поскольку туннели IPsec отказоустойчивы и глобально доступны, но будьте готовы к более высокому джиттеру, меньшей пропускной способности и более длительному времени переключения по сравнению с Direct Connect. Там, где требуется детерминированное подключение с низкой задержкой, второе подключение DX предпочтительнее, несмотря на более высокую стоимость.
Для требований TLS на уровне приложения выбор архитектуры зависит от того, разрешено ли балансировщику нагрузки видеть расшифрованный трафик. Если требуется сквозное взаимное шифрование (mutual TLS), терминируйте TLS на бэкенде, используя NLB в режиме сквозной передачи TCP/TLS (passthrough), и позвольте подам Kubernetes Ingress обрабатывать mTLS; используйте target type ip для EKS, чтобы поды могли масштабироваться, а Cluster Autoscaler — добавлять узлы без изменения конфигурации NLB, и включите proxy protocol v2, если вам нужен исходный IP-адрес клиента на уровне пода. Если терминирование TLS на ALB приемлемо, используйте ALB с HTTPS listener, настройте сертификаты в ACM, включите HTTP/2 для поддержки gRPC и используйте заголовок X-Forwarded-For для получения IP-адресов клиентов; ALB обеспечивает маршрутизацию на основе пути (path-based routing) к нескольким целевым группам для диспетчеризации по URL.
Для организации связи между несколькими аккаунтами и VPC, где требуются гранулярная безопасность и масштабируемость, шаблон «звезда» (hub-and-spoke) с Transit Gateway и централизованным Direct Connect Gateway обеспечивает наилучшее масштабирование. Подключите VPC каждого бизнес-подразделения к Transit Gateway (TGW) и свяжите TGW с Direct Connect Gateway через transit VIF. Используйте таблицы маршрутизации TGW для обеспечения изоляции, а для гранулярного контроля применяйте политики на уровне ресурсов, Security Groups и Network ACLs. Компромиссом является операционная сложность в управлении таблицами маршрутизации TGW и необходимость тщательно проектировать границы IAM и аккаунтов.
Распространенные ошибки и критерии принятия решений
Частая ошибка — использование одного VIF на каждый VPC без учета ограничений VIF и усложнения эксплуатации по мере роста количества VPC; используйте Direct Connect Gateway и транзитные VIF, если вы ожидаете большое количество VPC или работу в нескольких регионах. Еще одна распространенная ошибка — предполагать, что VPN и Direct Connect ведут себя одинаково: пересоздание ключей IPsec, особенности MTU и различия в пропускной способности каждого туннеля означают, что VPN является надежным резервным каналом, но не эквивалентом по производительности. Неправильная настройка терминирования TLS и ожиданий по IP-адресам нижестоящих клиентов — еще один источник ошибок: выбирайте сквозной режим (passthrough) NLB для настоящего сквозного TLS с mTLS или терминирование на ALB с обработкой X‑Forwarded‑For, если пограничное устройство может терминировать TLS.
Наконец, мониторинг и прозрачность имеют решающее значение. Включите метрики CloudWatch для Direct Connect (ConnectionBpsEgress/Ingress), журналы потоков (flow logs) для видимости в VPC и используйте оповещения CloudWatch для запуска автоматизации, которая переключает трафик или уведомляет сетевых инженеров. Для детального анализа трафика, когда несколько бизнес-подразделений совместно используют пропускную способность LAG, сопоставляйте статистику VIF и журналы потоков VPC, а также рассмотрите возможность контроля пропускной способности для каждого VPC на пограничном оборудовании, чтобы избежать проблемы «шумного соседа».
Практическая задача: сценарий использования
Компания: Meridian Medical Analytics. Задача: Meridian управляет глобальным парком медицинских устройств для визуализации, которые используют gRPC через TCP-порт 443 для загрузки больших объемов зашифрованных потоков данных в бэкенд, размещенный в кластере Amazon EKS в регионе us-east-1. Устройствам требуется взаимная аутентификация TLS (mTLS) для двусторонней аутентификации клиентов и поддержки тысяч одновременных, долгоживущих соединений. Кластер EKS масштабируется автоматически с помощью Cluster Autoscaler и HPA. Meridian требуется детерминированная низкая задержка от их основного центра обработки данных и автоматическое переключение на облачный VPN в случае сбоя.
Подход:
- Развернуть Network Load Balancer (NLB) перед сервисом EKS с TCP-прослушивателями на порту 443 и типом цели (target type), установленным в IP, чтобы конечные точки подов могли быть целями напрямую; настроить NLB на сквозную передачу TLS (TLS passthrough), не терминируя TLS на NLB, чтобы взаимная аутентификация TLS согласовывалась с бэкенд-подами. Используйте
undefined
и
undefined
для настройки NLB и целевых групп. 2. Настроить контейнеры подов EKS (Ingress или sidecar) для терминирования mTLS с использованием серверных и клиентских сертификатов из частного центра сертификации (ACM Private CA для выпуска серверных сертификатов; клиентские сертификаты предоставляются устройствам). Убедитесь, что поды поддерживают HTTP/2 gRPC и масштабируются с помощью HPA и Cluster Autoscaler; используйте задержку отмены регистрации целевой группы (target group deregistration delay), настроенную для долгоживущих соединений. 3. Для подключения к локальной инфраструктуре развернуть выделенное соединение Direct Connect (
undefined
), агрегированное с помощью LAG, если доступно несколько физических каналов, и создать частный виртуальный интерфейс (
undefined
) к Direct Connect Gateway, подключенному к вашему Transit Gateway для маршрутизации в VPC кластера EKS. Включите MACsec при развертывании, если оператор связи и местоположение поддерживают это, для защиты транспорта на уровне 2. 4. Реализовать Site‑to‑Site VPN (
undefined
к Transit Gateway) в качестве пути для автоматического аварийного переключения; управляйте переключением с помощью атрибутов BGP, отдавая предпочтение Direct Connect (более высокий local‑preference) и позволяя VPN наследовать более низкий приоритет. Используйте BFD, где это поддерживается, для более быстрого обнаружения сбоев пути. Отслеживайте метрики Direct Connect и VPN в CloudWatch и настраивайте оповещения для запуска изменений в инженерии трафика или уведомлений.
Обоснование со стороны AWS: Сквозной режим TCP (passthrough) в NLB сохраняет сквозное шифрование mTLS, поэтому сертификаты клиентов-устройств проверяются бэкенд-подами, что удовлетворяет требованию не расшифровывать трафик на пограничном устройстве. Тип цели IP и поддержка NLB обеспечивают масштабирование для тысяч одновременных долгоживущих соединений, сохраняя IP-адрес клиента с помощью proxy protocol или, при необходимости, путем чтения IP-адреса клиента из сессии TLS. Direct Connect обеспечивает детерминированное высокоскоростное подключение к us‑east‑1 с использованием LAG для увеличения пропускной способности и MACsec для шифрования на физическом уровне; Site‑to‑Site VPN предоставляет глобально доступный, зашифрованный резервный путь с переключением при сбое, управляемым через BGP. Эта архитектура обеспечивает баланс между безопасностью, производительностью и масштабируемостью, соответствуя лучшим практикам настройки AWS Direct Connect и VPN.
← Проектирование VPC и расширенные сетевые возможности · Все домены · Transit Gateway и сетевая топология →
Отработать эти вопросы → · Тесты на время на ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Сдайте экзамен →