Amazon ANS-C01: Проектирование VPC и расширенные сетевые возможности — Руководство по подготовке
Часть AWS Advanced Networking Specialty ANS-C01 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.
Архитектура VPC и основы работы с подсетями
VPC является фундаментальной сетевой границей в AWS, и структура выделенных вами CIDR-блоков определяет всё остальное. Планируйте CIDR-блоки с учётом будущего роста и межсетевого взаимодействия между аккаунтами: выделяйте большие, непересекающиеся адресные пространства для каждого аккаунта/региона (например, /16 для каждой среды) и разбивайте их на подсети /20–/24 для изоляции рабочих нагрузок по функциям и зонам доступности. Помните, что EKS и другие контейнерные платформы потребляют IP-адреса для ENI подов или в качестве вторичных IP-адресов; AWS VPC CNI назначает IP-адреса подам из подсети VPC, а лимиты ENI/IP для каждого инстанса (DescribeInstanceTypes) ограничивают максимальную плотность подов. Для внедрения IPv6 предпочитайте двухстековую архитектуру, чтобы перенести общедоступные сервисы на IPv6, сохранив IPv4 для интеграции с устаревшими системами; свяжите предоставленный Amazon CIDR-блок IPv6 с помощью API-вызова
undefined
и включите назначение IPv6 на уровне подсети с помощью
undefined
и опции
undefined
. Планируйте ресурсы NAT для исходящего трафика IPv4, а для IPv6 используйте Egress-Only Internet Gateway, созданный с помощью CreateEgressOnlyInternetGateway и подключенный к VPC.
Таблицы маршрутизации и размещение подсетей — это способы обеспечения топологии и отказоустойчивости. Создавайте отдельные таблицы маршрутизации для каждой цели подсети (публичная, приватная с NAT, приватная с Direct Connect и изолированная) с помощью CreateRouteTable и CreateRoute. Используйте несколько NAT Gateway (или NAT-инстансов с автомасштабированием) в разных зонах доступности, чтобы избежать отказа исходящего трафика в одной зоне; явно указывайте распространяемые маршруты при использовании Transit Gateway (CreateTransitGateway, CreateTransitGatewayRouteTable), чтобы префиксы из локальной сети добавлялись только там, где это необходимо. Для обнаружения сервисов внутри аккаунта используйте приватные хостинг-зоны Route 53 и связывайте их с VPC, которым требуются эти записи, чтобы избежать утечки DNS-запросов за пределы границ.
Ключевые сервисы и детали конфигурации
Для организации приватного подключения необходимо понимать три основных механизма: VPC Peering, AWS Transit Gateway и AWS PrivateLink (интерфейсные VPC-эндпоинты). VPC Peering (CreateVpcPeeringConnection, AcceptVpcPeeringConnection) — это простое, недорогое соединение точка-точка, которое требует записей в таблицах маршрутизации и не поддерживает транзитную маршрутизацию. Transit Gateway (CreateTransitGateway, CreateTransitGatewayVpcAttachment) — это масштабируемый центральный узел (хаб), который поддерживает тысячи VPC, централизованное управление маршрутами и интеграцию с Direct Connect Gateway для гибридного подключения; используйте распространение маршрутов и ассоциации таблиц маршрутизации в Transit Gateway для контроля трафика «восток-запад». PrivateLink (CreateVpcEndpointServiceConfiguration для регистрации сервиса за NLB и CreateVpcEndpoint для создания интерфейсных эндпоинтов) предоставляет доступ к сервисам между аккаунтами, не открывая VPC для маршрутизации, обеспечивая гранулярную безопасность на уровне каждого сервиса и упрощённое управление группами безопасности; он хорошо масштабируется, поскольку потребители создают интерфейсные эндпоинты, и трафик остаётся на уровне сетевых карт (NIC).
Балансировка нагрузки и сохранение IP-адреса клиента — это распространённые проектные решения, которые важно реализовать правильно. Application Load Balancer (ALB) терминирует TLS, маршрутизирует на уровне L7 (CreateLoadBalancer с типом application) и добавляет заголовки X-Forwarded-For/X-Forwarded-Proto, которым должны доверять бэкенды для логирования IP-адресов клиентов. Network Load Balancer (NLB) сохраняет исходные IP-адреса для целевых групп и поддерживает миллионы соединений; для настоящей сквозной передачи TLS (pass-through) на бэкенды используйте NLB с TCP-прослушивателем (CreateListener с протоколом TCP) и регистрируйте цели по IP, чтобы зашифрованные сессии достигали подов или инстансов в неизменном виде. Для gRPC и очень большого количества соединений предпочтительнее использовать NLB перед EKS с типом цели ip и аннотацией AWS Load Balancer Controller
undefined
для прямой регистрации IP-адресов подов; такая комбинация сохраняет исходный IP-адрес, поддерживает mTLS-терминацию на уровне пода и масштабируется вместе с автомасштабировщиками.
VPC-эндпоинты устраняют необходимость в исходящем интернет-трафике для доступа к API AWS и популярным сервисам. Шлюзовые эндпоинты (Gateway endpoints) для S3 и DynamoDB (CreateVpcEndpoint с
undefined
) добавляют маршруты к списку префиксов эндпоинта и являются бесплатными. Интерфейсные эндпоинты (Interface endpoints) (CreateVpcEndpoint с
undefined
) создают эластичные сетевые интерфейсы с приватными IP-адресами и группами безопасности; они оплачиваются почасово и за гигабайт трафика, но обеспечивают потребление в стиле PrivateLink и доступ между аккаунтами при использовании с сервисом за NLB.
Паттерны проектирования и компромиссы
Для централизованного общего сервиса, используемого многими бизнес-подразделениями в разных аккаунтах, PrivateLink и сервисы конечных точек (endpoint services) являются наиболее безопасным и масштабируемым паттерном, когда требуется контроль и изоляция на уровне каждого соединения. Разместите сервис за Network Load Balancer в VPC общих сервисов, создайте сервис конечной точки VPC (CreateVpcEndpointServiceConfiguration) и попросите аккаунты-потребители создать интерфейсные конечные точки, которые вы одобрите. Это позволяет избежать полносвязной топологии (full mesh) и предотвращает транзитивную маршрутизацию, а группы безопасности на интерфейсных конечных точках позволяют ограничить круг потребителей, которые могут подключаться. Компромисс заключается в стоимости за каждую конечную точку и некоторых накладных расходах на управление для подтверждения и аудита подключений конечных точек.
Transit Gateway идеально подходит, когда у вас много VPC, которым требуется широкая связность, централизованная инспекция и единое место для анонсирования локальных префиксов через Direct Connect (CreateTransitGatewayRoute, CreateTransitGatewayRouteTable). Используйте сегментацию таблиц маршрутизации и управление распространением маршрутов, чтобы избежать случайного горизонтального перемещения (lateral movement); Transit Gateway поддерживает приоритизацию маршрутов и ассоциации таблиц маршрутизации, что позволяет изолировать производственный трафик от сетей с более низким уровнем доверия. Компромисс заключается в том, что Transit Gateway централизует трафик и может повлечь расходы за трафик между VPC, который в ином случае был бы локальным; он также изменяет домены отказа и требует тщательного планирования CIDR для предотвращения пересечения адресных пространств.
Для гибридных архитектур с ограниченным повторным использованием CIDR рассмотрите возможность объединения Direct Connect с Transit Gateway и Direct Connect Gateway (CreateDirectConnectGateway), чтобы уменьшить количество виртуальных интерфейсов. Если вам нужна изоляция пропускной способности для каждого бизнес-подразделения на общем физическом канале, создайте несколько частных виртуальных интерфейсов и отслеживайте метрики CloudWatch для каждого VIF (имена метрик, такие как AWS/DX: BytesIn, BytesOut), а также используйте оповещения CloudWatch на уровне VIF. Чтобы выявить активных потребителей, включите VPC Flow Logs (CreateFlowLogs) с отправкой в S3 или CloudWatch Logs и анализируйте данные с помощью Athena или CloudWatch Logs Insights; для захвата пакетов на уровне отдельных VM используйте Traffic Mirroring (CreateTrafficMirrorSession) на короткие промежутки времени.
Внедрение IPv6 и двухстековые (dual-stack) архитектуры снижают зависимость от NAT, уменьшают затраты на пропускную способность NAT Gateway и упрощают адресацию для клиентов. Используйте вызов API aws ec2 associate-vpc-cidr-block для назначения предоставленного Amazon префикса IPv6 и создайте подсети с блоками IPv6 CIDR. Учтите, что некоторые сервисы и сторонние устройства могут быть не готовы к работе с IPv6; используйте режим dual-stack на балансировщиках нагрузки (CreateLoadBalancer с IpAddressType dualstack), чтобы поддерживать как IPv4, так и IPv6 клиентов, в то время как внутренние системы остаются на IPv4.
Распространенные ошибки и критерии принятия решений
Игнорирование потребления IP-адресов подами Kubernetes — частая причина сбоев в работе сервиса. Учитывайте лимиты на ENI и вторичные IP-адреса для каждого типа инстансов и используйте настройки VPC CNI, такие как WARM_IP_TARGETS или делегирование префиксов, для повышения доступности IP-адресов. Несохранение IP-адресов клиентов на уровне L7 — еще одна распространенная ошибка: если TLS необходимо терминировать на балансировщике нагрузки, вы должны убедиться, что приложение считывает заголовок X-Forwarded-For, а средства контроля безопасности ALB ограничивают прямой доступ, чтобы этим заголовкам можно было доверять. Предположение о том, что VPC-пиринг будет масштабироваться бесконечно, часто приводит к созданию неуправляемых полносвязных топологий; для сценариев «многие-ко-многим» предпочитайте Transit Gateway, а для предоставления сервиса по модели «один-ко-многим» — PrivateLink, когда вам требуется гранулярная безопасность и изоляция трафика.
Политики безопасности должны использовать группы безопасности и сетевые ACL в сочетании с контролем на уровне пространств имен (namespaces). Для строгого принудительного доступа через Global Accelerator вместо прямых URL-адресов ALB, используйте комбинацию наборов IP-адресов AWS WAF, которые заполняются диапазонами IP-адресов Global Accelerator (автоматизированно через публикуемый файл ip-ranges.json), или спроектируйте ALB как внутренний и разместите перед ним NLB, на который будет нацелен Global Accelerator, а затем предоставляйте доступ только через «входную дверь» Global Accelerator. Всегда автоматизируйте обновления любых средств контроля на основе IP-адресов и проверяйте их с помощью DescribePrefixLists и регулярной обработки ip-ranges.json.
Практическая задача: сценарий использования
Компания: Equinox Payments. Задача: Equinox управляет gRPC-сервисом на базе EKS, которому требуется сквозное шифрование mTLS для тысяч одновременных подключений, автомасштабирование с помощью Cluster Autoscaler и HPA, а также сохранение IP-адресов клиентов для логирования. Подход: 1) Развернуть сервис за Network Load Balancer, настроенным с TCP-прослушивателем на порту 443 через AWS Load Balancer Controller, используя аннотацию service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip", чтобы IP-адреса подов регистрировались в качестве целей (targets); 2) терминировать TLS на подах (а не на NLB) и реализовать mutual TLS в приложении (проверка сертификатов сервера и клиента), используя Kubernetes Secrets для сертификатов и проверки готовности (readiness probes) для управления регистрацией целей; 3) использовать тип цели ip для сохранения исходных IP-адресов клиентов, включать proxy protocol только при необходимости для промежуточных устройств и полагаться на логирование на стороне пода для захвата IP-адреса клиента из TCP-соединения; 4) настроить проверки состояния как TCP или gRPC-совместимые readiness probes и убедиться, что политики Cluster Autoscaler и типы инстансов узлов имеют достаточную емкость ENI и IP-адресов; 5) внедрить CloudWatch Container Insights и VPC Flow Logs (CreateFlowLogs) для мониторинга количества подключений и телеметрии на уровне VPC. Обоснование со стороны AWS: NLB с TCP-прослушивателями сохраняет зашифрованные сессии и исходные IP-адреса, масштабируясь до миллионов подключений; тип цели ip позволяет подам получать исходный IP-адрес напрямую, без NAT; терминирование mTLS на подах удовлетворяет требованиям сквозного шифрования и двусторонней аутентификации; автомасштабирование работает, потому что готовность пода напрямую влияет на регистрацию цели, а NLB прозрачно масштабируется вместе с нагрузкой по соединениям.
Все домены · Гибридная связность: VPN и Direct Connect →
Отработать эти вопросы → · Тесты на время на 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.
Сдайте экзамен →