Справочник

Полносвязное соединение для множества VPC, некоторые с перекрывающимися CIDR.

→Разверните Transit Gateway. Устраните перекрывающиеся CIDR, добавив уникальные, вторичные блоки CIDR к затронутым VPC.

Почему: Transit Gateway обеспечивает масштабируемую, транзитивную маршрутизацию, но не может маршрутизировать между перекрывающимися диапазонами IP-адресов. Требуется исправление IP.

Гибридное подключение с высокой пропускной способностью, низкой задержкой и отказоустойчивостью.

→Предоставьте два выделенных соединения Direct Connect в двух разных местоположениях Direct Connect.

Почему: Использование двух разных местоположений защищает от сбоев на уровне местоположения (обрывы оптоволокна, отключения электроэнергии), обеспечивая максимальную отказоустойчивость. Одно местоположение, даже с несколькими соединениями, является единой точкой отказа.

Двунаправленное разрешение DNS между локальными и частными размещенными зонами AWS.

→Используйте Route 53 Resolver. Создайте входящие конечные точки (Inbound Endpoints) для запросов AWS из локальной среды. Создайте исходящие конечные точки (Outbound Endpoints) с правилами пересылки для запросов локальной среды из AWS.

Почему: Входящие конечные точки предоставляют доступные IP-адреса для локальных DNS-форвардеров. Исходящие конечные точки обеспечивают условную пересылку из VPC. Разрешитель по умолчанию для VPC (VPC+2) недоступен из локальной среды.

Предоставьте доступ на уровне сервиса между двумя VPC без создания маршрутов на сетевом уровне.

→Используйте AWS PrivateLink. Создайте сервис конечной точки VPC (VPC Endpoint Service) (поддерживаемый NLB) в VPC поставщика и интерфейсную конечную точку VPC (Interface VPC Endpoint) в VPC потребителя.

Почему: PrivateLink обеспечивает однонаправленное, специфичное для сервиса подключение с использованием ENI в VPC потребителя, полностью избегая проблем маршрутизации на сетевом уровне и перекрытия CIDR.

Предоставьте только исходящий доступ в интернет для экземпляров с поддержкой IPv6 в частных подсетях.

→Создайте Egress-Only Internet Gateway (EIGW) и добавьте маршрут для `::/0` в таблицу маршрутизации частной подсети, указывающий на EIGW.

Почему: EIGW является stateful для исходящих соединений IPv6, позволяя ответный трафик, но предотвращая нежелательные входящие соединения, аналогично NAT Gateway, но для IPv6.

Проверяйте весь меж-VPC трафик с помощью AWS Network Firewall в централизованной модели с Transit Gateway.

→Создайте выделенную VPC для инспекции с Network Firewall. Настройте таблицы маршрутизации TGW для отправки всего меж-VPC трафика в VPC для инспекции. Внутри VPC для инспекции таблицы маршрутизации должны направлять трафик через конечные точки NFW для симметричной маршрутизации.

Почему: Эта архитектура требует тщательной маршрутизации: TGW отправляет трафик в VPC для инспекции; таблицы маршрутизации VPC отправляют его на конечную точку брандмауэра; брандмауэр отправляет его обратно в ENI присоединения TGW; TGW маршрутизирует его к конечному пункту назначения.

Сегментирование VPC (например, prod против dev) с использованием Transit Gateway, при этом позволяя обоим получать доступ к общей VPC сервисов.

→Используйте несколько таблиц маршрутизации Transit Gateway. Создайте таблицу маршрутизации для каждого сегмента (prod, dev, shared). Свяжите VPC с соответствующими таблицами. Распространяйте маршруты для создания топологии "звезда", где "спицы" видят только "хаб".

Почему: Связи и распространения таблиц маршрутизации TGW являются основным механизмом для сегментации сети и изоляции трафика на сетевом уровне.

Уменьшите задержку для динамического, некэшируемого глобального приложения (например, API, игры), размещенного в одном регионе.

→Используйте AWS Global Accelerator. Он предоставляет Anycast IP-адреса, которые маршрутизируют пользователей к ближайшей точке присутствия AWS, а затем трафик проходит по оптимизированной магистрали AWS к источнику.

Почему: Global Accelerator оптимизирует "первую милю" и "среднюю милю" через сеть AWS, уменьшая задержку и джиттер для TCP/UDP трафика. CloudFront лучше подходит для кэшируемого контента.

Предоставьте частный доступ из VPC к S3 и DynamoDB без прохода через интернет.

→Создайте конечные точки шлюза VPC (Gateway VPC Endpoints) для S3 и DynamoDB. Это добавляет записи списка префиксов в указанные таблицы маршрутизации подсетей.

Почему: Конечные точки шлюза являются специфическим, высокопроизводительным и бесплатным механизмом для частного доступа к S3 и DynamoDB. Другие сервисы используют интерфейсные конечные точки (Interface Endpoints, PrivateLink).

Получите доступ к VPC в нескольких регионах AWS из одного локального соединения Direct Connect.

→Используйте шлюз Direct Connect Gateway с транзитным виртуальным интерфейсом (Transit Virtual Interface, T-VIF). Свяжите DX Gateway с Transit Gateways в каждом требуемом регионе.

Почему: T-VIF с DX Gateway является масштабируемым решением для подключения к нескольким Transit Gateways в разных регионах. Private VIF с DX Gateway имеет более низкие ограничения.

Интегрируйте виртуальный брандмауэр стороннего производителя для прозрачной инспекции трафика.

→Используйте Gateway Load Balancer (GWLB). Он работает на уровне 3 и использует протокол GENEVE для инкапсуляции трафика, сохраняя исходный IP-адрес источника/назначения.

Почему: Инкапсуляция GENEVE в GWLB делает его "врезкой в провод", прозрачно вставляя устройства в сетевой путь без необходимости Source NAT, что критически важно для устройств безопасности.

Управляйте выделением IP-адресов для сотен VPC в многоаккаунтной организации, чтобы предотвратить наложения и отслеживать использование.

→Используйте Amazon VPC IP Address Manager (IPAM). Создайте пул верхнего уровня и делегируйте региональные пулы для автоматизации выделения CIDR для VPC.

Почему: VPC IPAM — это специализированный, масштабируемый сервис AWS для централизованного управления IP-адресами, заменяющий подверженные ошибкам ручные методы.

Интегрируйте стороннее устройство SD-WAN с Transit Gateway, используя GRE-туннели и динамическую маршрутизацию BGP.

→Используйте присоединение Transit Gateway Connect.

Почему: TGW Connect специально разработан для интеграции SD-WAN. Он поддерживает GRE для более высокой пропускной способности (до 5 Гбит/с на пир) и BGP для динамической маршрутизации.

VPC только с IPv6 должна взаимодействовать с ресурсами только с IPv4 в интернете.

→Включите DNS64 в настройках Route 53 Resolver для VPC и настройте NAT Gateway в публичной подсети. Направьте `64:ff9b::/96` на NAT Gateway.

Почему: DNS64 синтезирует записи AAAA для IPv4-назначений. NAT Gateway выполняет трансляцию протокола NAT64 с синтезированного адреса IPv6 на реальный адрес IPv4.

Подключите сотни VPC в разных регионах со строгими требованиями к сегментации (prod, dev, общие сервисы).

→Используйте AWS Cloud WAN. Определите сегменты и действия сегментов в единой политике основной сети для глобального управления маршрутизацией между сегментами.

Почему: Cloud WAN предоставляет централизованную, декларативную глобальную сетевую политику, которая более масштабируема и менее сложна, чем управление полной сеткой пирингов Transit Gateway и таблиц маршрутизации в каждом регионе.

Объединение нескольких соединений Direct Connect в одном местоположении для увеличения пропускной способности и избыточности канала.

→Настройте группу агрегации каналов (LAG). Все соединения должны иметь одинаковую пропускную способность и заканчиваться на одном и том же устройстве AWS.

Почему: LAG объединяет физические каналы в один логический канал. Это обеспечивает отказ при сбое на уровне канала, но не защищает от сбоев устройства или местоположения. Используйте `minimum links` для определения порога отказа.

Обеспечьте переключение DNS менее чем за 60 секунд для многорегионального приложения.

→Используйте маршрутизацию Route 53 failover с проверками работоспособности. Настройте быстрые проверки работоспособности (интервал 10 секунд) с низким порогом отказа (1). Используйте записи Alias или очень низкие TTL (например, 10-60 секунд).

Почему: Быстрое переключение требует быстрого обнаружения (быстрые проверки работоспособности) и быстрых обновлений на стороне клиента (низкие TTL или записи Alias, которые имеют динамические TTL).

Увеличьте общую пропускную способность VPN, используя оба туннеля соединения Site-to-Site VPN одновременно.

→Присоедините VPN к Transit Gateway. Включите поддержку ECMP на присоединении VPN Transit Gateway.

Почему: По умолчанию VPN к TGW может использовать только один туннель. Включение ECMP на присоединении TGW распределяет трафик по обоим туннелям, если маршруты BGP имеют одинаковую стоимость.

Убедитесь, что внутренние сервисы TCP за Network Load Balancer видят исходный IP-адрес клиента.

→Регистрируйте цели по ID экземпляра. Если цели зарегистрированы по IP, включите Proxy Protocol v2 в группе целей.

Почему: Когда цели зарегистрированы по ID экземпляра, NLB сохраняет IP клиента по умолчанию. Если зарегистрированы по IP, IP-адрес NLB становится источником, и для передачи исходного IP требуется Proxy Protocol v2.

Влияйте на то, как AWS маршрутизирует трафик обратно в локальную сеть, когда существует несколько путей Direct Connect.

→Используйте BGP AS path prepending на менее предпочтительном пути от локального маршрутизатора.

Почему: Для исходящего трафика из AWS основной контролируемый клиентом механизм — это длина AS path. AWS предпочитает путь с кратчайшим AS path. Вы не можете настроить локальное предпочтение на стороне AWS.

Разрешите дочерним аккаунтам (spoke accounts) в AWS Organization присоединять свои VPC к Transit Gateway, принадлежащему центральному сетевому аккаунту.

→Используйте AWS Resource Access Manager (RAM). Сетевой аккаунт предоставляет общий доступ к Transit Gateway для Organization или конкретных OU.

Почему: RAM — это специализированный сервис AWS, разработанный для совместного использования ресурсов, таких как Transit Gateways, между аккаунтами. Это позволяет централизованное управление, одновременно обеспечивая самостоятельное присоединение для дочерних аккаунтов.

Агрегируйте пропускную способность, превышающую лимит 1,25 Гбит/с для одного VPN-туннеля.

→Создайте несколько подключений Site-to-Site VPN к Transit Gateway с включенным ECMP.

Почему: Каждый VPN-туннель ограничен примерно 1,25 Гбит/с. Для масштабирования необходимо использовать несколько туннелей/соединений и задействовать ECMP на Transit Gateway для балансировки нагрузки между ними.

Настройте проверки работоспособности Route 53 для внутреннего, не выходящего в интернет ресурса, такого как внутренний ALB.

→Создайте оповещение CloudWatch, которое отслеживает метрику для внутреннего ресурса (например, `HealthyHostCount` для ALB). Настройте проверку работоспособности Route 53 для отслеживания состояния оповещения CloudWatch.

Почему: Проверки работоспособности Route 53 являются внешними. Для мониторинга внутренних ресурсов они должны отслеживать прокси-сигнал, такой как состояние оповещения CloudWatch, которое может быть вызвано внутренними метриками.

Автоматически переключайте трафик CloudFront на вторичный источник (например, статический сайт S3), когда основной источник (например, ALB) возвращает ошибки 5xx.

→Создайте CloudFront Origin Group с ALB в качестве основного и S3 в качестве вторичного. Настройте его для переключения при указанных кодах состояния (например, 500, 502, 503, 504).

Почему: Origin Groups — это встроенный механизм CloudFront для высокой доступности, обеспечивающий бесшовное переключение на периферии без необходимости изменений DNS.

Обеспечьте переключение менее чем за секунду для соединения Direct Connect на резервный VPN или вторичный путь DX.

→Включите Bidirectional Forwarding Detection (BFD) на виртуальном интерфейсе Direct Connect. Настройте BFD на локальном маршрутизаторе.

Почему: BFD обеспечивает гораздо более быстрое обнаружение сбоев канала (до 300 мс) по сравнению с таймерами BGP keepalive (по умолчанию 90 с), что позволяет быстро восстанавливать маршрутизацию трафика.

Включите подключение между Transit Gateways в двух разных регионах.

→Установите пиринговое соединение Transit Gateway. Вручную добавьте статические маршруты в каждую таблицу маршрутизации TGW, указывающие на CIDR удаленного региона через пиринговое присоединение.

Почему: Важно отметить, что пиринг между регионами Transit Gateway не поддерживает динамическое распространение маршрутов. Все межрегиональные маршруты должны быть настроены статически.

Устраняйте проблемы с подключением в AWS, определяя конкретный блокирующий компонент (например, маршрут, NACL, SG).

→Используйте VPC Reachability Analyzer. Укажите источник и назначение, и он выполнит статический анализ конфигурации сетевого пути.

Почему: Reachability Analyzer предоставляет окончательный, пошаговый анализ сетевых конструкций AWS, что более эффективно, чем traceroute (который может не работать) или ручная проверка каждого компонента.

Долгосрочное хранение и специальные запросы к подробным логам VPC Flow Logs для соответствия требованиям.

→Публикуйте логи потоков напрямую в S3 в формате Parquet с настраиваемой структурой полей. Используйте Amazon Athena для специальных SQL-запросов.

Почему: S3 — это наиболее экономичное хранилище. Формат Parquet очень эффективен для запросов Athena, снижая затраты на сканирование и повышая производительность. Это бессерверный, масштабируемый шаблон для анализа логов потоков.

Централизованно применяйте обязательные правила групп безопасности ко всем VPC в AWS Organization и автоматически устраняйте несоответствия.

→Используйте AWS Firewall Manager с политикой аудита групп безопасности. Определите требуемые правила и настройте политику для автоматического устранения несоответствующих групп.

Почему: Firewall Manager — это централизованный инструмент управления политиками безопасности (WAF, SG, NFW) в рамках Organization. Его политика аудита с автоматическим исправлением обеспечивает принудительное применение.

Визуализируйте и отслеживайте глобальную сетевую топологию, включая Transit Gateways, VPN и Direct Connect, в разных регионах и аккаунтах.

→Используйте AWS Network Manager. Зарегистрируйте Transit Gateways в единой глобальной сети, чтобы получить централизованную панель мониторинга, карту топологии и мониторинг состояния.

Почему: Network Manager специально разработан для предоставления единой точки обзора для сложных, глобальных сетей AWS, консолидируя мониторинг и управление.

Диагностируйте периодическую потерю пакетов или ошибки на соединении Direct Connect.

→Проверьте метрики Direct Connect CloudWatch (`ConnectionErrorCount`). На маршрутизаторе клиента проверьте уровни оптического сигнала (Tx/Rx) и счетчики ошибок интерфейса (ошибки CRC, входные ошибки).

Почему: Потеря пакетов может быть проблемой физического уровня. Для изоляции проблем, таких как деградация оптоволоконного кабеля или трансивера, необходимы как метрики со стороны AWS, так и диагностика маршрутизатора со стороны клиента.

Автоматически обнаруживайте и устраняйте несоответствующие сетевые конфигурации, например, группу безопасности, разрешающую публичный доступ по SSH.

→Используйте AWS Config с управляемым правилом (например, `restricted-ssh`) и настройте автоматическое действие по устранению с помощью документа SSM Automation.

Почему: Это обеспечивает замкнутую систему соответствия. AWS Config обнаруживает нарушение, а его действие по устранению запускает документ SSM для автоматического исправления конфигурации.

Проактивно выявляйте непреднамеренные пути сетевого доступа к конфиденциальным ресурсам из интернета или других недоверенных сетей.

→Используйте VPC Network Access Analyzer. Определите область доступа и запустите анализ, чтобы получить список всех возможных сетевых путей, которые соответствуют критериям.

Почему: Этот инструмент выполняет формальную проверку сети, анализируя все компоненты (SG, NACL, TGW, IGW) для поиска потенциальных путей, что более всеобъемлюще, чем ручные проверки или реактивный мониторинг.

Собирайте логи VPC Flow Logs, DNS Query Logs и Network Firewall из множества дочерних аккаунтов в центральный аккаунт для логирования.

→Настройте сервисы в дочерних аккаунтах для публикации логов напрямую в централизованный S3 бакет (для Flow Logs/NFW) или группу логов CloudWatch Log Group (для DNS-логов) в аккаунте логирования, используя политики бакета и IAM роли для кросс-аккаунтного доступа.

Почему: Прямая публикация логов между аккаунтами является наиболее эффективным и масштабируемым шаблоном, использующим нативные возможности AWS без необходимости в агентах или сложных конвейерах данных.

Оптимизируйте сетевые затраты для высокообъемного трафика между конкретными парами VPC в архитектуре "звезда" Transit Gateway.

→Для высокотрафиковых пар VPC создайте прямое пиринговое соединение VPC, чтобы обойти Transit Gateway. Сохраните TGW для всего остального трафика "звезда".

Почему: Пиринг VPC не имеет платы за обработку данных за ГБ (только стандартная передача данных), в то время как Transit Gateway имеет. Перемещение высокообъемного трафика точка-точка на пиринг значительно снижает затраты.

Шифруйте трафик Direct Connect на Уровне 2 для производительности на скорости линии.

→Включите MACsec (IEEE 802.1AE). Требуется выделенное соединение 10 Гбит/с или 100 Гбит/с в местоположении, поддерживающем MACsec.

Почему: MACsec обеспечивает пошаговое шифрование между маршрутизатором клиента и устройством AWS, защищая физический канал с минимальными накладными расходами на производительность.

Защитите веб-приложение от распространенных атак (SQLi, XSS) и ограничьте доступ по странам.

→Используйте AWS WAF. Присоедините веб-ACL к ALB/CloudFront. Используйте управляемые группы правил AWS (например, `AWSManagedRulesSQLiRuleSet`, `AWSManagedRulesCommonRuleSet`) и создайте правило гео-совпадения.

Почему: Управляемые правила AWS обеспечивают готовую защиту от распространенных угроз, а правила гео-совпадения предоставляют географический контроль. Это стандартный шаблон реализации WAF.

Реализуйте многоуровневую изоляцию приложений (например, web -> app -> db) внутри VPC.

→Создайте группу безопасности для каждого уровня. Используйте ссылки на ID групп безопасности в правилах (например, `app-sg` разрешает входящий трафик от `web-sg`).

Почему: Ссылка на группы безопасности более динамична и безопасна, чем использование диапазонов CIDR. Она автоматически адаптируется при добавлении или удалении экземпляров из уровня.

Мониторинг и обнаружение угроз, основанных на DNS, таких как DNS-туннелирование и связь с C2-серверами.

→Включите логирование запросов Route 53 Resolver. Включите Amazon GuardDuty, который анализирует логи запросов DNS как источник данных.

Почему: GuardDuty имеет встроенную аналитику угроз, которая анализирует DNS-логи для обнаружения известных вредоносных доменов, DGA и аномальных шаблонов запросов, указывающих на эксфильтрацию данных.

Убедитесь, что к содержимому S3 можно получить доступ только через CloudFront, а не напрямую через URL S3, при этом разрешая доступ другим субъектам IAM.

→Используйте Origin Access Control (OAC). Обновите политику бакета S3, чтобы разрешить доступ от субъекта сервиса OAC и любых других необходимых ролей/пользователей IAM.

Почему: OAC — это современная замена OAI. Он создает сервисный субъект, который может быть указан в политиках бакета, обеспечивая более гранулированный и гибкий контроль доступа.

Предотвратите обход CloudFront пользователями и прямой доступ к источнику ALB.

→Настройте CloudFront для добавления пользовательского HTTP-заголовка с секретным значением к запросам источника. Создайте правило слушателя ALB, которое проверяет этот заголовок и значение, блокируя запросы, не содержащие его.

Почему: Это обеспечивает более надежную защиту, чем ограничения на основе IP (с использованием управляемого списка префиксов), поскольку оно проверяет, что запрос поступил от вашего конкретного дистрибутива. Используйте оба метода для многоуровневой защиты.

Захватывайте полные данные сетевых пакетов с конкретного экземпляра EC2 для криминалистического анализа без установки агентов.

→Используйте VPC Traffic Mirroring. Настройте сессию зеркалирования на ENI экземпляра для копирования трафика на цель (например, NLB, находящийся перед инструментами анализа).

Почему: Traffic Mirroring обеспечивает захват полного пакета без агентов, что важно для глубокого криминалистического анализа. Логи потоков предоставляют только метаданные.

Обеспечьте комплексную защиту от DDoS для общедоступных приложений.

→Подпишитесь на AWS Shield Advanced. Свяжите защиту с критически важными ресурсами (CloudFront, ALB, EIPs, Route 53). Используйте AWS WAF для минимизации на Уровне 7. Привлекайте команду реагирования Shield (SRT) во время атак.

Почему: Shield Advanced обеспечивает улучшенное обнаружение, защиту от затрат, вызванных масштабированием из-за DDoS, и доступ к SRT для экспертной помощи, что критически важно для бизнес-критических приложений.

Выпускайте и автоматически ротируйте TLS-сертификаты для внутренних микросервисов из частного центра сертификации.

→Используйте AWS Private Certificate Authority (Private CA) для создания CA. Используйте AWS Certificate Manager (ACM) для выпуска и управления жизненным циклом (включая автоматическое продление) частных сертификатов от этого CA.

Почему: Эта комбинация предоставляет полностью управляемое решение для частной PKI, автоматизируя сложный жизненный цикл внутренних сертификатов без публичного раскрытия.

Запретите любому пользователю в любом дочернем аккаунте AWS Organization создавать или присоединять интернет-шлюз.

→Примените политику управления сервисами (Service Control Policy, SCP) на корневом уровне Organization, которая запрещает действия `ec2:CreateInternetGateway` и `ec2:AttachInternetGateway`.

Почему: SCP предоставляют превентивные ограждения, которые не могут быть переопределены политиками IAM в дочерних аккаунтах, что делает их окончательным инструментом для принудительного применения общеорганизационных политик безопасности.

Расшифруйте и проверьте HTTPS-трафик на наличие угроз с помощью AWS Network Firewall, затем повторно зашифруйте его.

→Создайте или импортируйте CA-сертификат в ACM. Создайте конфигурацию инспекции TLS в политике брандмауэра, которая ссылается на этот CA. Распространите CA-сертификат на клиентские системы как доверенный корневой CA.

Почему: Network Firewall выполняет инспекцию TLS с помощью подхода "человек посередине", используя предоставленный вами CA для переподписи сертификатов на лету. Клиенты должны доверять этому CA, чтобы избежать ошибок сертификатов.

Блокируйте DNS-запросы к известным вредоносным доменам во всех VPC в AWS Organization.

→Создайте группы правил DNS Firewall в центральном аккаунте, используя управляемые списки доменов AWS. Предоставьте общий доступ к группам правил через RAM и свяжите их с VPC в дочерних аккаунтах.

Почему: DNS Firewall предоставляет управляемую, централизованно обновляемую информацию об угрозах для блокировки вредоносных доменов на уровне разрешения DNS, что является критически важным средством контроля безопасности.

Шифруйте весь сетевой трафик между экземплярами EC2 в одной VPC без изменений в приложении.

→Используйте типы экземпляров на базе AWS Nitro System.

Почему: Экземпляры Nitro автоматически шифруют весь трафик между экземплярами на аппаратном уровне, обеспечивая прозрачное шифрование на скорости линии без необходимости настройки.