Amazon SAA-C03: Сети и подключения — Руководство по подготовке

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Часть AWS SAA-C03 — Полное руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

Проектирование VPC и планирование CIDR

Каждый VPC начинается с CIDR-блока, и выбор, сделанный во время создания, имеет последующие последствия для пиринга, подключений Transit Gateway и гибридной связности. Основной CIDR должен быть в диапазоне от /16 до /28, выбран из пространства RFC 1918 и не должен пересекаться с сетями, с которыми вы планируете устанавливать пиринг, маршрутизировать через Transit Gateway или соединяться через Direct Connect или VPN. Пересекающиеся CIDR-блоки — самая частая причина неработающих гибридных архитектур, поскольку AWS не может маршрутизировать трафик между двумя сетями с общим адресным пространством. Transit Gateway примет подключение, но распространение маршрутов завершится ошибкой или трафик будет тихо отбрасываться.

Когда в VPC заканчивается адресное пространство, его не нужно пересоздавать. К нему можно присоединить до четырех вторичных CIDR-блоков IPv4 (и дополнительные диапазоны из более широкого пула, всего по умолчанию пять, с возможностью увеличения квоты). Вторичные блоки могут быть из того же диапазона RFC 1918 или из общего адресного пространства 100.64.0.0/10, что полезно, когда диапазон 10.0.0.0/8 исчерпан или требуется пространство для NAT операторского класса (carrier-grade NAT). Вторичные CIDR-блоки позволяют выделять новые подсети для расширения — например, для сетевого взаимодействия подов EKS или для нового уровня (tier) — без перенумерации существующих рабочих нагрузок.

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

Надежная архитектура резервирует /17 или /18 для будущего роста, выравнивает границы подсетей по зонам доступности (распространенный паттерн — /20 на каждую AZ для каждого уровня) и оставляет запас для ENI, используемых интерфейсными эндпоинтами, NAT-шлюзами и балансировщиками нагрузки.

VPC — это региональный ресурс, разделенный на подсети, каждая из которых привязана к одной зоне доступности (AZ). Различие между «публичной» (public) и «частной» (private) подсетью — это исключительно вопрос маршрутизации: публичная подсеть имеет маршрут 0.0.0.0/0 → igw-xxxx, указывающий на Internet Gateway, в то время как частная подсеть либо не имеет маршрута по умолчанию, либо ее маршрут 0.0.0.0/0 указывает на NAT-устройство. Экземплярам в публичной подсети также необходим публичный или Elastic IP для доступности извне; IGW выполняет преобразование адресов 1:1 (NAT) между частным и публичным IP.

NAT-шлюзы, NAT-экземпляры и исходящий трафик IPv6

Для исходящего доступа в интернет по IPv4 из частных подсетей правильным примитивом являются NAT-шлюзы (NAT gateways). Управляемый NAT-шлюз автоматически масштабируется до 45–100 Гбит/с, поддерживает 55 000 одновременных подключений к одному уникальному месту назначения, обновляется AWS и обладает высокой доступностью в пределах своей AZ. Оплата за NAT-шлюзы взимается почасово и за каждый обработанный гигабайт.

NAT-экземпляры (NAT instances) — самостоятельно управляемые EC2 с отключенной проверкой источника/назначения (source/destination check) — являются устаревшим решением. Их пропускная способность ограничена одним экземпляром, для отказоустойчивости требуются скрипты, и они становятся узким местом при постоянной нагрузке. Они подходят только для нетипичных задач, таких как кастомная фильтрация, но даже в этих случаях обычно предпочтительнее использовать устройство Gateway Load Balancer.

Канонический высокодоступный паттерн — это один NAT-шлюз на каждую AZ, каждый в публичной подсети своей зоны, с отдельной таблицей маршрутизации для частных подсетей каждой AZ, где маршрут по умолчанию указывает на локальный NAT-шлюз:

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

Развертывание одного общего NAT-шлюза для нескольких AZ — это ловушка по двум причинам. Во-первых, это единая точка отказа: сбой в одной AZ приведет к потере исходящего доступа для всех частных подсетей. Во-вторых, каждый пакет от экземпляров в других AZ пересекает границу зоны доступности, что влечет за собой плату за передачу данных между AZ (в настоящее время $0.01/ГБ в каждую сторону) вдобавок к плате за обработку трафика NAT-шлюзом. На рабочих нагрузках с сотнями терабайт исходящего трафика эти расходы значительно превышают стоимость дополнительных NAT-шлюзов. Вторая частая ошибка конфигурации — размещение самого NAT-шлюза в частной подсети. В этом случае у него нет пути к IGW, и он не функционирует.

Для IPv6 NAT не нужен и не предоставляется, поскольку каждый IPv6-адрес является глобально маршрутизируемым. Чтобы разрешить только исходящий трафик IPv6, блокируя при этом нежелательные входящие подключения, подключите интернет-шлюз только для исходящего трафика (egress-only internet gateway) и направьте на него маршрут ::/0 из частных подсетей. Обычный IGW является двунаправленным и сделал бы экземпляры доступными извне.

Конечные точки VPC: шлюзовые и интерфейсные

Конечные точки VPC (VPC endpoints) обеспечивают передачу трафика между вашим VPC и сервисами AWS по магистральной сети AWS, полностью исключая использование интернета, NAT-шлюзов и интернет-шлюзов. Существует две принципиально разные реализации, и их путаница — одна из самых распространенных архитектурных ошибок.

Шлюзовые конечные точки (Gateway endpoints) существуют только для Amazon S3 и DynamoDB. Они представляют собой запись в таблице маршрутизации — список префиксов (например, pl-63a5400a для S3 в us-east-1), указывающий на саму конечную точку. Здесь нет ENI, изменений в DNS, почасовой оплаты и групп безопасности (доступ контролируется таблицей маршрутизации и политикой конечной точки). Поскольку они основаны на маршрутизации, они работают только для ресурсов внутри VPC — локальные сети, обращающиеся к S3 через Direct Connect, не могут их использовать.

Интерфейсные конечные точки (Interface endpoints) (AWS PrivateLink) — это ENI с частными IP-адресами, размещенные в ваших подсетях, с почасовой оплатой за каждую AZ и за гигабайт трафика. Они работают почти со всеми остальными сервисами — SQS, KMS, Secrets Manager, ECR, STS, SSM, SNS и сотнями других, — а также со сторонними сервисами, опубликованными как endpoint services. Интерфейсные конечные точки поддерживают частный DNS (private DNS), который переопределяет публичное имя хоста сервиса, чтобы оно разрешалось в частный IP-адрес конечной точки, поэтому SDK и CLI не требуют изменений в коде. Поскольку они основаны на ENI, к ним применяются группы безопасности.

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

Логика затрат имеет значение: любой трафик, выходящий из частной подсети к публичному сервису AWS, по умолчанию проходит через NAT-шлюз по цене примерно $0.045/ГБ. Для контейнеризированной рабочей нагрузки, отправляющей 1 ТБ данных в день в S3, разница между использованием NAT-шлюза и шлюзовой конечной точки составляет тысячи долларов в месяц. Интерфейсные конечные точки оправданы, когда они заменяют исходящий трафик через NAT в больших объемах или когда требования комплаенса запрещают маршрутизацию через интернет.

Ловушки: привязка группы безопасности к шлюзовой конечной точке (у них нет ENI); предположение, что шлюзовая конечная точка доступна из локальной сети (это не так — используйте интерфейсную конечную точку или гибридную схему EC2 → шлюзовая конечная точка S3 → отдельный путь через DX); отключение частного DNS на интерфейсной конечной точке и ожидание, что вызовы SDK без изменений будут работать (они будут обращаться к публичной конечной точке через интернет, что полностью сводит на нет смысл использования конечной точки); создание шлюзовой конечной точки, но без привязки таблицы маршрутизации частной подсети (трафик будет незаметно продолжать идти по публичному пути); попытка использовать шлюзовую конечную точку для сервиса, у которого ее нет (например, KMS) — подходят только S3 и DynamoDB.

Связность между VPC: пиринг и Transit Gateway

Пиринг VPC (VPC peering) — это прямое, нетранзитивное соединение уровня 3 между двумя VPC в одном или разных аккаунтах, в одном или разных регионах. Трафик проходит по магистральной сети AWS, узких мест по пропускной способности нет, и отсутствует почасовая оплата — вы платите только за передачу данных между зонами доступности (cross-AZ) или регионами. Пиринг ограничивают два свойства: (1) он нетранзитивен — если VPC A соединен с B, а B соединен с C, то A не может достичь C через B; и (2) диапазоны CIDR не должны пересекаться. Для соединения N VPC по полносвязной схеме (full-mesh) требуется N(N-1)/2 пиринговых соединений с редактированием таблиц маршрутизации в обоих направлениях для каждого из них; при 30 VPC это 435 пирингов. Ожидать, что пиринг будет масштабироваться на сотни VPC — это ловушка.

Transit Gateway (TGW) — это региональный облачный маршрутизатор. Каждый VPC, VPN или шлюз Direct Connect является подключением (attachment), а таблицы маршрутизации TGW контролируют, какое подключение может достичь какого префикса. Это превращает полносвязную сеть O(n²) в O(n) подключений и позволяет создавать топологии «звезда» (hub-and-spoke), где в VPC безопасности размещаются файрволы, проверяющие весь трафик между VPC. TGW поддерживает транзитивную маршрутизацию, нативно терминирует ассоциации VPN и шлюзов Direct Connect и может быть разделен между аккаунтами в AWS Organizations с помощью Resource Access Manager, что позволяет центральным командам по сетям контролировать маршрутизацию, в то время как аккаунты с рабочими нагрузками владеют своими VPC. TGW добавляет почасовую плату за каждое подключение и примерно $0.02 за обработанный ГБ.

Для межрегиональной связности пиринг TGW (TGW peering) соединяет TGW в разных регионах по глобальной магистральной сети AWS с шифрованием трафика — по одному TGW на регион, соединенных пирингом по схеме «сетка» или «звезда». Это позволяет избежать проблемы N-квадрат, которая вновь возникает при межрегиональном пиринге VPC.

Неправильная настройка таблиц маршрутизации — частая и незаметная причина проблем. Создание пирингового соединения или подключения TGW ничего не дает до тех пор, пока в таблицы маршрутизации подсетей обоих VPC не будут добавлены явные маршруты CIDR, указывающие на цель pcx- или tgw-, а группы безопасности не разрешат этот трафик. Сбои подключения, происходящие без явных ошибок, почти всегда связаны с отсутствующим маршрутом или неявным запретом в группе безопасности, которая ссылается на неверный исходный CIDR.

Гибридное подключение: Site-to-Site VPN в сравнении с Direct Connect

Выбор между Site-to-Site VPN и Direct Connect — это компромисс между скоростью развертывания и встроенным шифрованием с одной стороны, и стабильно низкой задержкой, выделенной пропускной способностью и предсказуемой производительностью с другой.

Site-to-Site VPN устанавливает два туннеля IPsec между шлюзом клиента (локальным маршрутизатором) и Virtual Private Gateway или Transit Gateway. Пропускная способность каждого туннеля ограничена примерно 1,25 Гбит/с. Трафик шифруется на сетевом уровне, что в сочетании с TLS удовлетворяет требованиям к шифрованию на сетевом и сеансовом уровнях. Он проходит через публичный интернет, поэтому задержка и джиттер могут меняться, но он доступен за минуты и стоит центы в час. Используйте его, когда подключение требуется немедленно, при скромных требованиях к пропускной способности или в качестве резервного пути.

Direct Connect (DX) предоставляет выделенное оптоволоконное соединение (1, 10 или 100 Гбит/с) от локального маршрутизатора до точки присутствия AWS Direct Connect. Оно обходит публичный интернет, обеспечивая стабильную задержку и более высокую пропускную способность. Стоимость исходящего трафика через DX значительно ниже, чем через интернет, что важно при перемещении сотен гигабайт данных в день. Подготовка занимает недели — кросс-коммутации, получение разрешительных писем (LOA), настройка BGP.

Здесь есть две основные ловушки. Во-первых, Direct Connect сам по себе не шифрует трафик. Частный канал не является криптографически защищенным каналом. Чтобы выполнить требование шифрования поверх DX, необходимо настроить поверх него Site-to-Site VPN или использовать MACsec для шифрования на уровне 2 на поддерживаемых выделенных портах. Во-вторых, «сырое» соединение DX само по себе не обеспечивает маршрутизацию в несколько VPC. Private VIF подключается к одному Virtual Private Gateway, присоединенному к одному VPC. Чтобы получить доступ ко многим VPC, особенно в разных аккаунтах и регионах, используйте Direct Connect Gateway, связанный с Transit Gateway через transit VIF, и подключите каждый VPC к TGW:

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

Канонический производственный паттерн использует два подключения DX в двух разных точках присутствия DX, терминируемых на разных маршрутизаторах клиента, с Site-to-Site VPN в качестве автоматического резервного канала через BGP. Атрибуты BGP, такие как AS-path prepending или MED, направляют трафик на DX, пока он активен; в случае сбоя BGP отзывает маршруты DX, и трафик переключается на VPN.

Балансировщики нагрузки: ALB, NLB и GWLB

ALB работает на уровне 7 и понимает семантику HTTP — маршрутизация по хосту и пути, WebSockets, перенаправления, привязка сессий на основе cookie. Это неподходящий инструмент для всего, что не является HTTP: MQTT, «сырой» TCP, syslog по UDP, SMTP. ALB использует адресацию на основе DNS с IP-адресами, которые со временем меняются; ему нельзя назначить Elastic IP. Когда клиенты вносят IP-адреса назначения в белый список, один лишь ALB не подходит — используйте NLB с EIP или поставьте перед ALB сервис Global Accelerator с его двумя статическими anycast IP. «Просто разрешить DNS-имя ALB один раз и закрепить IP-адреса в правилах файрвола» — это ловушка: AWS меняет их без предупреждения.

NLB работает на уровне 4 и масштабируется до миллионов потоков в секунду. По умолчанию он сохраняет истинный IP-адрес источника клиента (целевые объекты видят реального клиента), поддерживает назначение статического Elastic IP на каждую AZ и обрабатывает высокопроизводительные нагрузки TCP/UDP. Исторически NLB не поддерживал security groups на самом балансировщике — CIDR клиентов нужно было разрешать непосредственно в SG целевого объекта. AWS добавила опциональные security groups для NLB в 2023 году, но многие архитектуры все еще предполагают классическое поведение.

Канонический паттерн для публичных приложений:

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

Ссылка на security group балансировщика ALB в качестве источника трафика для бэкенда — вместо указания CIDR — является паттерном наименьших привилегий и автоматически покрывает трафик проверок состояния, который исходит от ENI самого ALB. Сам ALB размещается в публичных подсетях как минимум в двух AZ (с маршрутами к IGW); целевые объекты размещаются в приватных подсетях. Размещение интернет-ориентированного ALB в приватной подсети — это классическая ошибка конфигурации: регистрация целевых объектов проходит успешно, но клиенты не могут до него добраться.

Gateway Load Balancer (GWLB) специально создан для прозрачной вставки сторонних виртуальных устройств (файрволов, IDS/IPS, DPI). Он работает на уровне 3, пересылая все IP-протоколы с использованием инкапсуляции GENEVE в UDP 6081. Трафик достигает GWLB через GWLB endpoint (GWLBe) — это интерфейсный эндпоинт, который находится в подсети и отображается в таблицах маршрутизации как цель:

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

Эндпоинт пересылает пакеты через PrivateLink на GWLB, который балансирует нагрузку между парком устройств, используя привязку потока (flow stickiness), чтобы оба направления одного потока попадали на одно и то же устройство. В архитектуре инспекции трафика «звезда» (hub-and-spoke) spoke-VPC подключаются к TGW, чьи таблицы маршрутизации принудительно направляют трафик «восток-запад» через инспекционный VPC (содержащий GWLB и устройства), прежде чем он достигнет целевых VPC. Инспекция входящего трафика использует пограничные таблицы маршрутизации (edge route tables), которые перенаправляют трафик от IGW к веб-уровню сначала через GWLBe:

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

Это правильное решение для централизованной меж-аккаунтной инспекции — самодельные решения на EC2, хаки с таблицами маршрутизации и скрипты для отказоустойчивости лишь заново изобретают то, что GWLB предоставляет нативно.

PrivateLink для сервисов типа «потребитель-поставщик»

Помимо обеспечения работы интерфейсных конечных точек для сервисов AWS, PrivateLink позволяет устанавливать приватные соединения с сервисами, опубликованными третьими сторонами или другими аккаунтами AWS. Поставщик размещает свой сервис за NLB и создает сервис конечной точки VPC (VPC endpoint service). Потребители создают в своих VPC интерфейсные конечные точки (interface endpoints), которые нацелены на этот сервис.

Критически важное правило направленности: соединение всегда инициируется потребителем в сторону поставщика. Поставщик не может инициировать соединения в VPC потребителя. Трафик никогда не выходит в интернет, доступен только конкретный целевой сервис (а не весь VPC поставщика, как в случае пиринга), и не возникает проблем с пересечением CIDR-блоков, поскольку с каждой стороны видны только IP-адреса конечных точек. Это стандартное решение для шаблона доступа к SaaS или базе данных вендора, когда в VPC потребителя нет IGW, VPN или Direct Connect. VPC-пиринг открывает доступ ко всему диапазону CIDR и требует непересекающихся IP-адресов; подключение через TGW обеспечивает широкую маршрутизацию; публичный API через интернет не является приватным.

Global Accelerator и Route 53

AWS Global Accelerator назначает два статических anycast IPv4-адреса, которые анонсируются из пограничных точек присутствия (edge locations) AWS по всему миру. Трафик клиента входит в ближайшую пограничную точку и перемещается по магистральной сети AWS к ближайшей работоспособной региональной конечной точке (ALB, NLB, EIP или EC2). Это решает сразу две проблемы: предоставление статических IP-адресов для ALB (устраняя проблему с добавлением в белые списки) и уменьшение джиттера/задержки для глобально распределенных пользователей за счет сокращения пути через публичный интернет. Он ускоряет некэшируемый TCP/UDP-трафик к источникам, для которых CloudFront (кэширующий контент) не подходит.

Route 53 решает другую задачу — управление трафиком на уровне DNS. Global Accelerator влияет на саму плоскость данных (data plane); Route 53 влияет только на разрешение DNS-имён, после чего TCP-соединение устанавливается с тем IP-адресом, который был получен в результате разрешения. Эти два сервиса часто используются вместе: Alias-запись в Route 53 указывает на Global Accelerator, который находится перед региональными ALB.

Политики маршрутизации Route 53:

Политики на основе задержки и геолокации часто путают: первая минимизирует воспринимаемое пользователем время приема-передачи (RTT); вторая обеспечивает размещение данных в определённом месте (data residency) независимо от задержки. Для межрегионального аварийного восстановления требуются проверки состояния основного ресурса. Alias-записи — это специфичная для AWS функция; они разрешаются напрямую в конечные точки ALB, NLB, CloudFront, веб-сайтов S3 и API Gateway без платы за запросы и, в отличие от CNAME, работают для корневого домена (zone apex).

Route 53 Resolver отвечает на DNS-запросы внутри VPC через адрес .2 (базовый адрес CIDR VPC + 2). Для гибридного DNS входящие конечные точки (inbound endpoints) позволяют локальным резолверам запрашивать частные хостинг-зоны в AWS; исходящие конечные точки (outbound endpoints) с правилами перенаправления позволяют ресурсам в VPC разрешать локальные имена. Без них инстансы EC2 не смогут разрешить corp.internal, а локальные серверы — db.prod.internal. Это незаметная проблема, которая проявляется только тогда, когда приложения начинают делать межсетевые запросы. Для интерфейсных конечных точек необходимо включить опцию Enable Private DNS, чтобы вызовы SDK попадали на ENI конечной точки; без этого вызовы по-прежнему будут направляться на публичную конечную точку через интернет, что делает использование приватной точки бессмысленным.

Группы безопасности, NACL и принцип наименьших привилегий

Группы безопасности (Security groups) сохраняют состояние (stateful) — ответный трафик разрешается автоматически — и действуют на уровне ENI. Списки контроля доступа к сети (NACL) не сохраняют состояние (stateless) и действуют на границе подсети. Любое правило для TCP в NACL требует явного разрешающего правила как для входящего, так и для исходящего трафика; поскольку клиенты выбирают исходный порт из эфемерного диапазона, правило для ответного трафика должно разрешать порты 1024–65535 (Linux по умолчанию использует 32768–60999; более широкий диапазон охватывает Windows и другие стеки). Отсутствие правила для эфемерных портов — классическая причина, по которой соединение устанавливается (проходит SYN), но зависает в ожидании ответа.

Для реализации принципа наименьших привилегий между уровнями приложения правила групп безопасности должны ссылаться на ID других групп безопасности, а не на CIDR-блоки. Это позволяет масштабироваться с помощью Auto Scaling и избегать хрупких белых списков IP-адресов:

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

NACL — это инструмент грубого ограничения радиуса поражения (blast radius), а не замена группам безопасности. Ужесточение NACL «для глубокоэшелонированной обороны» без соответствующих изменений в группах безопасности часто нарушает исходящие потоки, например, обновления через yum/apt через NAT-шлюз, поскольку ответный трафик без сохранения состояния будет молча отброшен. В конечном счёте, доступность определяется таблицами маршрутизации: даже разрешающая группа безопасности не сможет доставить трафик, если в таблице маршрутизации отсутствует запись для пункта назначения. И наоборот, шлюзовая конечная точка (gateway endpoint) эффективна только тогда, когда маршрут к списку префиксов S3 действительно добавлен в таблицы маршрутизации подсетей, где работает нагрузка.

← Передача и миграция данных · Все домены · Доставка контента →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Amazon →