Справочник

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

→AWS Control Tower как целевая зона. Account Factory выделяет аккаунты; обязательные и настоятельно рекомендуемые средства защиты обеспечивают базовые настройки; централизованный архив журналов + аккаунты аудита создаются автоматически.

Почему: Control Tower кодифицирует хорошо спроектированный шаблон с несколькими аккаунтами. Создание с нуля только через Organizations вручную воспроизводит ту же инфраструктуру.

Источник↗

Необходимо добавить пользовательские средства защиты и ресурсы сверх стандартных настроек Control Tower для всех аккаунтов.

→Customizations for AWS Control Tower (CfCT). Конвейер шаблонов CloudFormation + SCPs развертывается через StackSets для организационных единиц (OUs).

Почему: CfCT расширяет Control Tower, не нарушая его жизненный цикл. Пользовательские правила Config, базовые настройки безопасности, сетевые настройки — все это контролируется версиями и может быть повторно развернуто.

Источник↗

Обеспечить S3 KMS шифрование + автоматическое исправление несоответствующих бакетов в 300 аккаунтах менее чем за 15 минут.

→Пакет соответствия AWS Config для всей организации через делегированного администратора. Правило Config + документ SSM Automation для автоматического исправления.

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

Источник↗

Защищенные от подделки журналы CloudTrail по всем аккаунтам хранятся 7 лет; только команда безопасности может их читать.

→Организационный журнал, доставляемый в S3 бакет выделенного аккаунта для ведения журналов. Object Lock в режиме Compliance с 7-летним сроком хранения. SCP, ограничивающий доступ к бакету для IAM ролей безопасности.

Почему: Object Lock в режиме Compliance блокирует удаление даже для root-пользователя. Организационный журнал собирает данные со всех аккаунтов автоматически. Выделенный аккаунт для журналов изолирует радиус поражения.

Источник↗

Федерация 150 аккаунтов с корпоративным AD через SAML; назначение разрешений по группам AD.

→IAM Identity Center с внешним поставщиком идентификации SAML 2.0. Наборы разрешений, сопоставленные с группами AD через SCIM-провижининг. Назначения аккаунтов через группы.

Почему: Identity Center централизует федерацию по всем аккаунтам организации. Наборы разрешений могут быть переиспользованы между аккаунтами; SCIM поддерживает синхронизацию состояния пользователей/групп.

Источник↗

Предоставить доступ к ресурсам, помеченным центром затрат пользователя, масштабируя до тысяч пользователей.

→Управление доступом на основе атрибутов (ABAC) в Identity Center. Передача атрибутов AD через SAML; наборы разрешений ссылаются на `aws:PrincipalTag/CostCenter` по отношению к `aws:ResourceTag/CostCenter`.

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

Источник↗

Аккаунт CI/CD принимает роль развертывания в 50 аккаунтах с рабочими нагрузками для запуска CloudFormation.

→IAM роль для каждого аккаунта с рабочей нагрузкой с политикой доверия, разрешающей основной объект аккаунта CI/CD. CI/CD принимает через STS AssumeRole. Используйте внешний ID, если инициируется сторонним инструментом.

Почему: Внешний ID предотвращает проблему "запутанного заместителя". Цепочка ролей жестко ограничивает сессию одним часом, даже если роль позволяет дольше.

Источник↗

Центральная сетевая команда владеет VPC; 30 дочерних аккаунтов развертывают рабочие нагрузки в общих подсетях.

→AWS RAM предоставляет доступ к подсетям участникам. Участники запускают ресурсы, не владея VPC; центральная команда сохраняет контроль над таблицей маршрутизации и NAT.

Почему: Общие VPC устраняют разрастание VPC для каждого аккаунта + дублирование IPAM. Участники не могут удалить VPC или изменить маршрутизацию.

Источник↗

Подключение VPC в 5 регионах + локальная среда с детерминированной маршрутизацией и централизованной инспекцией.

→Transit Gateway в каждом регионе. Пиринг TGW для межрегионального соединения. Инспекционная VPC с устройствами, доступными через таблицы маршрутизации TGW.

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

Источник↗

Создание глобальной частной сети между регионами + филиалами с маршрутизацией на основе политик — за пределами пиринга TGW.

→AWS Cloud WAN. Политика базовой сети в JSON декларативно определяет сегменты, регионы, подключения, совместное использование.

Почему: Cloud WAN заменяет дизайн TGW "хаб-и-спица" единой управляемой глобальной магистралью. Сегменты обеспечивают логическую изоляцию между регионами.

Источник↗

Локальному центру обработки данных требуется соединение 10 Гбит/с с AWS с устойчивостью к сбоям соединения и без выхода в интернет.

→Два соединения Direct Connect в разных местоположениях DX. Каждое с приватным VIF, завершающимся на Direct Connect Gateway → TGW. Отказ BGP между соединениями.

Почему: Один DX является единой точкой отказа. Различные местоположения DX защищают от общесистемных сбоев. DX Gateway позволяет одному VIF достигать нескольких регионов/VPC.

Источник↗

Соединение Direct Connect как основное; требуется автоматическое переключение на VPN.

→Site-to-Site VPN, присоединенный к тому же TGW, что и DX gateway. AWS отдает предпочтение маршрутам DX BGP; VPN берет на себя управление при отзыве DX BGP.

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

Источник↗

Регулятор требует шифрования уровня 2 между локальной средой и AWS через Direct Connect.

→Direct Connect с MACsec на выделенном соединении 10 Гбит/с или 100 Гбит/с. Предварительно общий ключ настроен на обоих концах.

Почему: IPsec работает на уровне 3; MACsec шифрует на уровне 2 на скорости линии, удовлетворяя регуляторам, которые требуют шифрования физического канала.

Источник↗

Восточно-западный трафик между VPC должен проходить stateful-инспекцию.

→Централизованная инспекционная VPC с AWS Network Firewall. Таблицы маршрутизации TGW направляют трафик между VPC через VPC-фаервол, прежде чем он достигнет пункта назначения.

Почему: Network Firewall — это управляемый движок правил Suricata для stateful-инспекции. Централизация позволяет избежать разрастания фаерволов для каждой VPC.

Источник↗

Автоматическое применение базовой конфигурации WAF + Network Firewall для каждого аккаунта в организации.

→AWS Firewall Manager с делегированным администратором. Политики для WAF, Shield Advanced, Network Firewall, групп безопасности применяются по всей организации.

Почему: Firewall Manager автоматически присоединяет политики к новым ресурсам. Без него каждый аккаунт отклоняется от базовой конфигурации по мере добавления аккаунтов.

Источник↗

Централизация результатов Security Hub из более чем 100 аккаунтов в одном интерфейсе.

→Делегированный администратор Security Hub. Регион агрегации собирает результаты из всех дочерних аккаунтов + всех включенных регионов в одну консоль.

Почему: Без агрегации результаты остаются для каждого аккаунта/региона. Делегированный администратор позволяет избежать использования управляющего аккаунта для операций безопасности.

Источник↗

Включение GuardDuty для всей организации с централизованным мониторингом и видимостью выставления счетов для каждого аккаунта.

→GuardDuty с делегированным администратором. Автоматическое включение для новых аккаунтов через интеграцию с организацией. Результаты агрегируются в аккаунте администратора.

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

Источник↗

Непрерывное обнаружение PII во всех S3 бакетах в 200 аккаунтах.

→Macie с делегированным администратором. Автоматическое включение для всей организации. Результаты поступают в Security Hub для унифицированного анализа.

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

Источник↗

Исследование результатов GuardDuty путем корреляции CloudTrail + VPC Flow Logs между аккаунтами.

→Делегированный администратор Amazon Detective в выделенном аккаунте безопасности. Дочерние аккаунты вносят вклад в граф поведения.

Почему: Detective автоматически строит граф поведения из VPC Flow Logs, CloudTrail, GuardDuty. Делегированный администратор (не управляющий) соответствует лучшим практикам AWS.

Источник↗

Обнаружение случаев, когда какой-либо ресурс в организации предоставляется внешнему аккаунту.

→IAM Access Analyzer с организацией в качестве доверенной зоны, делегированной аккаунту безопасности. Результаты по меж-аккаунтному доступу в S3, IAM ролях, KMS ключах, Lambda, SQS, Secrets.

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

Источник↗

Максимизация использования Savings Plan в 50 аккаунтах с несовпадающими паттернами рабочих нагрузок.

→Консолидированный биллинг в Organizations с включенным совместным использованием Savings Plans + RI. Планы, приобретенные в аккаунте плательщика, распространяются на всю организацию.

Почему: Совместное использование объединяет потребление, так что неиспользуемая емкость в одном аккаунте компенсирует спрос в другом. Отключайте совместное использование только для изоляции распределения затрат.

Источник↗

Предоставить командам приложений возможность самостоятельного развертывания утвержденной инфраструктуры (VPC, RDS) без прав администратора IAM.

→Портфолио AWS Service Catalog. Предварительно одобренные продукты CloudFormation с ограничениями. Совместное использование портфолио между аккаунтами через Organizations.

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

Источник↗

Последовательное применение обязательных тегов `CostCenter` и `Environment` по всей организации.

→Политики тегов Organizations, привязанные к организационным единицам (OUs). Определите разрешенные значения + капитализацию. Объедините с правилом Config `required-tags` для обеспечения соблюдения.

Почему: Политики тегов проверяют; правила Config обнаруживают несоответствие. SCPs могут запрещать создание ресурсов без тегов.

Источник↗

Предотвратить действия root-пользователя в дочерних аккаунтах (требование соответствия).

→SCP, запрещающий любое действие, когда `aws:PrincipalArn` совпадает с `arn:aws:iam::*:root`.

Почему: SCPs применяются даже к root. IAM не может запретить root. Действия root никогда не должны требоваться, кроме восстановления аккаунта.

Источник↗

Обязательное использование планов AWS Backup по всем аккаунтам с согласованным сроком хранения.

→Политики резервного копирования Organizations, привязанные к организационным единицам (OUs). Определите планы + критерии выбора; применяйте автоматически к ресурсам в области действия.

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

Источник↗

100+ VPC, каждая с NAT Gateway, приводит к раздуванию затрат. Нужна одна точка выхода.

→Централизованная исходящая VPC с NAT Gateway. Дочерние VPC маршрутизируют 0.0.0.0/0 → TGW → исходящая VPC → NAT.

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

Источник↗

EC2 в VPC должен разрешать имена хостов локальной среды; локальная среда должна разрешать частные DNS-имена VPC.

→Входящие + исходящие конечные точки Route 53 Resolver. Правила перенаправления отправляют запросы `corp.local` в локальную среду; локальный DNS перенаправляет `*.compute.internal` на входящую конечную точку.

Почему: Конечные точки Resolver — это высокодоступные ENI в двух зонах доступности. Условное перенаправление обеспечивает двунаправленное разрешение без exposing DNS в интернет.

Источник↗

Внутренние сервисы нуждаются в разрешении DNS из нескольких VPC через аккаунты.

→Частная размещенная зона Route 53, связанная с VPC из нескольких аккаунтов через меж-аккаунтное связывание VPC.

Почему: Одна PHZ, совместно используемая через меж-аккаунтное связывание, лучше, чем дубликаты для каждой VPC, которые могут расходиться.

Источник↗

Рабочие нагрузки Windows нуждаются в полноценном AD с доверием к локальному лесу.

→AWS Managed Microsoft AD. Установите двустороннее доверие к лесу с локальным AD через DX/VPN.

Почему: Managed AD — это настоящий Microsoft AD (контроллеры домена в двух зонах доступности, расширяемая схема). AD Connector только проксирует; Simple AD не поддерживает доверие.

Источник↗

Приложения в AWS должны аутентифицироваться с помощью существующего локального AD без репликации идентификаторов.

→AD Connector. Действует как прокси из VPC к локальному AD через DX/VPN.

Почему: Данные каталога не покидают локальную среду; запросы аутентификации проходят через него. Задержка зависит от канала.

Источник↗

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

→AWS Outposts rack/server. Те же AWS API (EC2, EBS, ECS, EKS, подмножество RDS) работают локально. Подключается к родительскому региону.

Почему: Для субмиллисекундной локальной задержки до локальных систем или для обеспечения резидентности данных, где Local Zones не покрывают. Single-AZ — для HA сопрягите два Outposts.

Источник↗

Уменьшить задержку для конечных пользователей в крупном городе, который находится далеко от родительского региона.

→AWS Local Zones. Развертывание вычислений, хранилища близко к населенным пунктам; плоскость данных маршрутизируется обратно в родительский регион для плоскости управления.

Почему: Local Zones размещают EC2/EBS/RDS/ELB рядом с крупными городами. Дешевле, чем Outposts, когда полное владение ЦОД не требуется.

Источник↗

Приложение требует одноразрядной миллисекундной задержки для мобильных пользователей в сети 5G.

→AWS Wavelength Zones в сетях 5G операторов. Развертывание EC2/EBS на периферии оператора; трафик остается в сети мобильного провайдера.

Почему: Полностью исключает публичный интернет-переход для сценариев использования 5G, таких как AR/VR, вывод данных в реальном времени, игры.

Источник↗

Аудитор соответствия требованиям нуждается в текущей конфигурации каждого ресурса по всей организации.

→Агрегатор AWS Config в аккаунте аудита, охватывающий всю организацию во всех регионах.

Почему: Агрегатор Config — это представление всей организации только для чтения. Агрегаторы не включают Config в дочерних аккаунтах — это отдельная функция.

Источник↗

Журналы CloudWatch Logs из 50 аккаунтов должны попасть в один S3-архив для приема в SIEM.

→Фильтры подписки в каждом аккаунте → меж-аккаунтный Kinesis Data Stream / Firehose → S3 в аккаунте журналирования.

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

Источник↗

Непрерывное создание отчетов об доказательствах для SOC 2, PCI, HIPAA по всей организации.

→AWS Audit Manager. Предустановленные фреймворки сопоставляют элементы управления с доказательствами AWS (Config, CloudTrail, Security Hub). Делегированный администратор в аккаунте безопасности.

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

Источник↗

Развернуть базовую роль IAM для каждого существующего + будущего аккаунта в организации.

→CloudFormation StackSets с управляемыми сервисом разрешениями + автоматическое развертывание в новых аккаунтах. Ориентировано на всю организацию или конкретные организационные единицы.

Почему: Самоуправляемые StackSets требуют IAM в каждом аккаунте. Управляемые сервисом используют разрешения организации и являются стандартными для Organizations.

Источник↗

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

→Инициировать обнаружение расхождений в StackSet. Просмотреть результаты для каждого экземпляра стека без изменения ресурсов.

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

Источник↗

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

→Aurora Serverless v2. Установите мин/макс ACU; Aurora масштабируется за секунды без разрывов соединений.

Почему: v2 масштабируется путем добавления мощности к существующему экземпляру — без переключения. Provisioned Aurora не может масштабироваться так быстро; Serverless v1 масштабируется медленнее и приостанавливает соединения.

Источник↗

Глобальное приложение с RPO <1с и RTO <1мин для межрегионального переключения БД.

→Aurora Global Database. Репликация на основе хранилища, типичная задержка репликации <1с. Повышение вторичной базы данных за секунды.

Почему: Global DB передает страницы, а не транзакции — субсекундная межрегиональная репликация. Межрегиональные реплики чтения через логическую репликацию не могут сравниться с этим.

Источник↗

Воспроизведение производственной базы данных для тестирования без оплаты полной копии.

→Клонирование Aurora. Копирование при записи — начальный клон бесплатен; оплачиваются только измененные страницы.

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

Источник↗

Восстановление после логической ошибки (DROP TABLE в prod) за минуты, а не часы.

→Aurora MySQL Backtrack. Откатывает кластер на месте до более раннего момента времени без восстановления из резервной копии.

Почему: Backtrack работает на месте и быстро. Восстановление PITR создает новый кластер — медленнее и требует переключения приложения.

Источник↗

Направлять запросы отчетности на определенные экземпляры чтения с большим объемом памяти.

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

Почему: Конечная точка чтения по умолчанию равномерно распределяет запросы между всеми экземплярами чтения. Пользовательские конечные точки разделяют кластер по типу рабочей нагрузки.

Источник↗

Таблица DynamoDB испытывает пики "горячих" разделов, что замедляет некоторые операции чтения/записи.

→Провизионировано с автоматическим масштабированием + адаптивной емкостью (автоматически). Переработать ключ раздела, если один ключ является "горячим".

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

Источник↗

Побочный эффект при каждой записи в DynamoDB — отправка в OpenSearch для индексации поиска.

→DynamoDB Streams + триггер Lambda. Lambda пакетирует записи потока и записывает в OpenSearch.

Почему: Streams захватывают изменения на уровне элементов в течение 24 часов. Модель нативного триггера — адаптер Kinesis Data Streams существует для более длительного хранения/аналитики.

Источник↗

Двухфазная запись по нескольким элементам DynamoDB должна быть атомарной.

→TransactWriteItems / TransactGetItems. ACID-семантика для до 100 элементов.

Почему: Нативные транзакции избегают сложности распределенной саги. Стоимость в 2 раза превышает обычную емкость за элемент — используйте только при необходимости атомарности.

Источник↗

Миграция самостоятельно размещенного кластера MongoDB на управляемый сервис с сохранением API.

→Amazon DocumentDB. MongoDB-совместимый API. Используйте mongodump/mongorestore или DMS для миграции.

Почему: DocumentDB API-совместим с MongoDB 4.0/5.0 (большинство операторов, но не все). Перед принятием решения проверьте совместимость драйверов/функций.

Источник↗

Движок рекомендаций должен обходить социальный граф из 100 миллионов узлов.

→Amazon Neptune. Граф свойств (Gremlin) или RDF (SPARQL).

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

Источник↗

Парк IoT излучает 10М точек данных временных рядов/сек с смешанной частотой хранения.

→Amazon Timestream. Хранилище в памяти (недавние), магнитное хранилище (исторические) — автоматическое многоуровневое хранение.

Почему: Специально созданная база данных временных рядов — масштабирование DynamoDB/RDS слишком дорого при такой скорости. Встроенное многоуровневое хранение сокращает стоимость хранения.

Источник↗

Банковский реестр требует криптографической верификации каждого изменения записи.

→Amazon QLDB. Неизменяемый, криптографически проверяемый журнал. Используйте экспорт дайджеста SHA-256 для доказательств.

Почему: QLDB — это специально созданный реестр. DynamoDB Streams предоставляет историю изменений, но без встроенной криптографической цепочки.

Рабочая нагрузка по анализу журналов с непредсказуемыми пиками и автоматическим управлением.

→Amazon OpenSearch Serverless. Разделенные вычисления/хранилище; автоматическое масштабирование OCUs.

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

Источник↗

Аналитика петабайтного масштаба с эластичными вычислениями и совместным использованием данных между командами.

→Узлы Redshift RA3 с управляемым хранилищем. Совместное использование данных между кластерами (без копирования).

Почему: RA3 разделяет вычисления и хранилище — масштабируйте их независимо. Совместное использование данных исключает ETL между кластерами команд.

Источник↗

Существующий кластер Redshift + озеро данных S3 — запрашивать S3 из Redshift или использовать Athena?

→Redshift Spectrum, когда требуются объединения между таблицами кластера и данными S3. Athena, когда полностью бессерверный ad-hoc только на S3.

Почему: Spectrum выполняет запросы S3 через вычислительную мощность Redshift. Athena платит за каждый отсканированный ТБ. Выбирайте в зависимости от того, где находится большая часть данных.

Источник↗

Разным командам нужна разная видимость строк/столбцов в одних и тех же таблицах Glue Catalog.

→AWS Lake Formation с фильтрами на уровне строк + столбцов + ячеек. Предоставляйте доступ через теги LF.

Почему: Политики IAM/S3 не могут работать на уровне строк. Lake Formation обеспечивает детальный доступ через метаданные Glue Catalog + потребителей Athena/Redshift Spectrum/EMR.

Источник↗

Ежедневная задача Glue обрабатывает инкрементные данные; не должна повторно обрабатывать вчерашние файлы.

→Закладки Glue job. Отслеживать обработанные S3 ключи / строки БД; возобновлять с последней успешной контрольной точки.

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

Источник↗

Выбор между управляемым Kafka и Kinesis Data Streams для потоковой передачи событий.

→MSK, если существуют клиенты/экосистема Kafka. Kinesis для тесной интеграции с AWS (триггеры Lambda, Firehose, KCL) и бессерверной опции.

Почему: Оба потока надежно работают с повторным воспроизведением. MSK сохраняет API и экосистему Kafka; Kinesis стоит дешевле для небольших потоков и интегрируется нативно.

Источник↗

Переменная пропускная способность Kafka; требуется автоматическое управление кластером.

→MSK Serverless. Автоматически масштабирует разделы и пропускную способность; оплата за раздел + данные.

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

Источник↗

Соединить SQS → фильтр → Step Functions без написания связующей Lambda.

→EventBridge Pipes. Источник → опциональный фильтр → опциональное обогащение → цель.

Почему: Заменяет типичную Lambda-как-связующее звено. Уменьшает код, затраты и операционную поверхность.

Источник↗

Повторное воспроизведение событий прошлой недели через нового потребителя без повторной эмиссии из источника.

→Архив + воспроизведение EventBridge. Архив захватывает совпадающие события; воспроизводит их для целевого объекта позже.

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

Источник↗

Сотни производителей генерируют события; потребителям нужны типизированные привязки.

→Реестр схем EventBridge с автообнаружением. Генерирует строго типизированные привязки кода (Java, Python, TypeScript).

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

Источник↗

Оркестрация высокообъемных коротких рабочих процессов (<100k/сек) с оплатой за субсекунду.

→Рабочие процессы Step Functions Express. Оплата за мс выполнения; максимум 5 минут.

Почему: Стандартные рабочие процессы надежны + отслеживают историю, оплачиваются за каждый переход состояния. Express жертвует аудиторским следом ради экономии на короткоживущих потоках.

Источник↗

Параллельная обработка 10 миллионов объектов S3 через Step Function.

→Состояние распределенной карты (Distributed Map). Одновременные дочерние выполнения до 10 000 параллельных; читает источник непосредственно из S3.

Почему: Встроенная карта ограничена 40 параллельными выполнениями. Distributed Map масштабируется до задач размера S3-бакета без достижения лимитов сервиса.

Источник↗

Очередь FIFO требует >300 сообщений/сек.

→SQS FIFO с включенным режимом высокой пропускной способности. До 70 тысяч сообщений/сек на API на регион; секционирование по `MessageGroupId`.

Почему: Стандартный FIFO ограничивается 300 сообщениями/сек без пакетирования. Режим высокой пропускной способности секционирует порядок по ID группы.

Источник↗

Несколько потребителей нуждаются в полной пропускной способности чтения одного и того же потока Kinesis.

→Enhanced Fan-Out (EFO). Каждый потребитель получает выделенный канал 2 МБ/с/шард через HTTP/2 push.

Почему: По умолчанию опрос разделяет лимит 2 МБ/с/шард между потребителями. EFO устраняет конкуренцию за более высокую стоимость.

Источник↗

Firehose в S3; запросы к озеру данных сканируют слишком много, потому что секционирование происходит по времени приема, а не по времени события.

→Динамическое секционирование Firehose. Извлечение времени события / ID арендатора из JSON; запись в S3 префикс `year=YYYY/month=MM/tenant=X/`.

Почему: Обрезка разделов Athena/Spectrum по времени события резко сокращает стоимость сканирования и задержку.

Источник↗

Мобильный/веб-клиент нуждается в обновлениях в реальном времени и выборочной выборке полей.

→AWS AppSync (GraphQL) с подписками. Поддержка WebSocket.

Почему: Клиенты GraphQL получают только запрошенные поля и подписываются на дельты. REST/HTTP API Gateway принудительно извлекает слишком много данных и требует опроса.

Источник↗

Внутренний API не должен быть доступен из публичного интернета.

→Частная конечная точка API Gateway через конечную точку интерфейса VPC. Политика ресурсов ограничивает доступ к конкретным VPC.

Почему: Частные API доступны только из VPC + подключенных сетей. Публичные API требуют WAF + аутентификации для безопасности.

Источник↗

Заблокировать источник S3 так, чтобы только CloudFront мог его читать.

→Origin Access Control (OAC). Заменяет устаревший OAI; поддерживает SSE-KMS и все функции S3.

Почему: OAI не поддерживает объекты SSE-KMS. AWS рекомендует OAC для всех новых дистрибутивов.

Источник↗

Ограничить по времени доступ к конкретным платным видео в S3.

→Подписанные URL-адреса CloudFront (для каждого URL) или подписанные куки (для нескольких URL). Доверенная группа ключей подписывает запросы.

Почему: Предварительно подписанные URL-адреса S3 обходят кэширование CloudFront. Подписанные URL-адреса CloudFront кэшируются на периферии И ограничивают доступ.

Источник↗

Легкое преобразование запросов зрителей: переписывание заголовков, перенаправление, A/B-маршрутизация.

→CloudFront Functions. JS, субмиллисекундная задержка, все граничные POP.

Почему: Lambda@Edge — это полный Node/Python на региональном краю — тяжелее и дороже. Functions в 10 раз дешевле для простых манипуляций.

Источник↗

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

→Изоляция EKS Fargate для каждого пода. Каждый под работает в выделенной микро-ВМ.

Почему: Управляемые группы узлов используют общее ядро — эскалация привилегий пересекает арендаторов. Изоляция ядра Fargate является самой сильной в EKS.

Источник↗

Задержка автомасштабирования кластера EKS слишком велика; разрастание типов инстансов в группах узлов.

→Karpenter. Провизионер выбирает типы инстансов JIT на основе требований ожидающих подов.

Почему: Cluster Autoscaler масштабирует предопределенные ASG, медленно и ограничено. Karpenter масштабирует произвольные EC2 за секунды с диверсификацией.

Источник↗

EKS под требует IAM с минимальными привилегиями (избегать совместного использования роли экземпляра узла).

→IAM Roles for Service Accounts (IRSA) через провайдера OIDC. Аннотирование ServiceAccount с помощью ARN роли.

Почему: EKS Pod Identity — это новая альтернатива — более простая модель доверия. IRSA зрелая и работает между регионами.

Источник↗

Запуск задач ECS-on-EC2 занимает 5–7 минут во время масштабирования — нужно <60с.

→Поставщик емкости ECS с управляемой целью масштабирования ~80% по `CapacityProviderReservation`. Поддерживать буфер простоя.

Почему: Зарезервированный буфер означает, что новые задачи мгновенно попадают на существующую емкость, пока ASG запускает замены.

Источник↗

Lambda, вызываемая SQS, но только 5% сообщений соответствуют — пустые вызовы.

→Сопоставление источника событий с критериями фильтра. Lambda вызывается только для соответствующих сообщений.

Почему: Предварительный фильтр Lambda позволяет избежать затрат на вызов для нерелевантных сообщений. Фильтрация поддерживается для SQS, Kinesis, DynamoDB, MQ, Kafka.

Источник↗

Производственному приложению нужна конечная точка LLM с низкими операционными накладными расходами.

→Amazon Bedrock для управляемых базовых моделей (Claude, Llama, Titan). SageMaker только тогда, когда вам нужно размещать пользовательские модели или открытые модели с точной настройкой.

Почему: Bedrock работает только по API — нет инфраструктуры. SageMaker — это полноценная платформа ML — выбирайте, когда вы владеете жизненным циклом обучения/тонкой настройки.

Источник↗

Выбрать управляемый AI для зрения / NLP без обучения модели.

→Rekognition (метки изображений/видео, лица, модерация контента). Comprehend (сентимент, сущности, языки, обнаружение PII). Translate. Polly. Transcribe.

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

Источник↗

Веб-приложение поддерживает электронную почту/пароль + Google + Apple + SAML корпоративный SSO.

→Cognito User Pool с размещенным UI. Настройте OIDC + SAML IdPs. Приложение получает Cognito JWT.

Почему: User Pool агрегирует IdP в один токен. Identity Pool только обменивает токены на учетные данные AWS — для доступа к AWS API, а не для аутентификации.

Источник↗

DynamoDB Global Tables с одновременными записями одного и того же ключа в двух регионах.

→Последний записывающий выигрывает по временной метке. Приложение проектирует идемпотентные записи или разделяет записи по регионам.

Почему: Репликация GT является асинхронной мульти-мастер. Разрешение конфликтов основано на временных метках — приложения должны допускать окончательную согласованность.

Источник↗

Парк EC2 чрезмерно провизионирован по всей организации; необходимы автоматические рекомендации по оптимизации размера.

→AWS Compute Optimizer включен на уровне организации. Просмотрите рекомендации относительно окон использования; экспортируйте в S3 для отслеживания.

Почему: Compute Optimizer использует ML для метрик CloudWatch. Ручная оптимизация размера пропускает сигналы формы рабочей нагрузки.

Источник↗

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

→AWS Cost Anomaly Detection. ML отслеживает расходы по сервисам / аккаунтам; оповещения через SNS / электронную почту при превышении порога.

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

Источник↗

Когда аккаунт достигает 100% месячного бюджета, автоматически останавливать несущественные ресурсы.

→Действия AWS Budget. Примените ограничительную политику IAM + запустите Lambda через SNS для остановки несущественных EC2/RDS.

Почему: Действия бюджетов переходят от "только оповещение" к "принудительное выполнение". Сочетайте с Cost Anomaly Detection для обнаружения незапланированных расходов.

Источник↗

Видимость по всей организации возможностей оптимизации затрат S3.

→S3 Storage Lens с расширенными метриками + охват всей организации. Выявляет кандидатов на холодное хранение, возможности для IT-уровня, заброшенные многочастные загрузки.

Почему: Бесплатный уровень охватывает базовые метрики; расширенный уровень показывает репликацию, активность, рекомендации по оптимизации. Централизовано в аккаунте аудита/безопасности.

Источник↗

Счет за S3 продолжает расти, несмотря на операции удаления.

→Правило жизненного цикла отменяет `incomplete multipart uploads` через 7 дней. Проверьте с помощью `s3api list-multipart-uploads`.

Почему: Неудачные загрузки оставляют части, которые учитываются как хранилище, но не видны в списке консоли. Распространенная утечка затрат.

Источник↗

Данные холодного архива доступны не чаще одного раза в квартал.

→S3 Glacier Flexible Retrieval (восстановление 1–12 часов). Для "никогда не доступных" используйте Deep Archive (восстановление 12 часов, самая низкая стоимость).

Почему: Standard-IA сохраняет доступ с миллисекундной задержкой; уровни Glacier обменивают время доступа на снижение стоимости на ~80–95%.

Источник↗

Сокращение стоимости исходящего трафика NAT Gateway для трафика S3 + DynamoDB.

→Конечные точки Gateway VPC для S3 + DynamoDB (бесплатно). Маршрутизация трафика через конечную точку, обход NAT.

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

Источник↗

Рабочая нагрузка активно обменивается данными между зонами доступности; стоимость передачи данных доминирует в счете.

→Разместите микросервисы в одной зоне доступности, если это возможно. Используйте VPC Lattice или Service Mesh с маршрутизацией по аффинности AZ.

Почему: Передача между AZ стоит 0,01 долл. США/ГБ в каждом направлении. Обмен данными микросервисов в масштабе суммируется. Обменяйте часть HA на стоимость, где достаточно 99,95%.

Источник↗

Исходящий трафик в интернет является самой большой статьей расходов.

→Всегда используйте CloudFront. Исходящий трафик CloudFront в интернет дешевле, чем прямой исходящий трафик EC2/ALB.

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

Источник↗

Выбрать между Compute Savings Plan, EC2 Instance Savings Plan и Reserved Instances.

→Compute SP: наиболее гибкий (любой регион, семейство, ОС) — немного меньшая скидка. EC2 Instance SP: привязан к семейству в регионе — более глубокая скидка. RI: редкие случаи, требующие резервирования мощности.

Почему: Compute SP покрывает Lambda + Fargate + EC2. RI превосходят SP только тогда, когда важно резервирование мощности; в большинстве случаев SP выигрывают.

Источник↗

Бессерверный пакетный флот работает на Spot — слишком высокая частота прерываний.

→Spot Fleet с оптимизированной по емкости стратегией по многим типам инстансов + AZ.

Почему: Стратегия самой низкой цены концентрируется на одном пуле — высокая частота прерываний. Оптимизированная по емкости выбирает пулы с самой глубокой доступной емкостью.

Источник↗

Сократить стоимость вычислений на бессерверном веб-уровне примерно на 20% без переписывания.

→Миграция на Graviton (ARM) — `c7g`, `m7g`, Lambda ARM, Aurora Graviton. Тест совместимости для скомпилированных бинарных файлов.

Почему: Graviton предлагает примерно на 20% лучшую цену/производительность для большинства рабочих нагрузок. Java/Python/Node "просто работают"; нативный код может потребовать перекомпиляции.

Источник↗

Снижение стоимости долго работающего, но толерантного к прерываниям сервиса Fargate.

→Fargate Spot через стратегию поставщика емкости. Смешивание Spot + по требованию для задач HA.

Почему: Fargate Spot примерно на 70% дешевле. Задачи получают 2-минутное предупреждение перед завершением — сочетайте с graceful drain.

Источник↗

Стоимость хранения CloudWatch Logs растет месяц за месяцем.

→Установите срок хранения для каждой группы журналов (по умолчанию — навсегда). Для долгосрочного хранения экспортируйте в S3 + удалите в CW. Используйте класс Logs Infrequent Access.

Почему: CloudWatch Logs стоит $0.03/ГБ за прием + хранение навсегда. S3 Standard-IA по $0.0125/ГБ дешевле для архивного доступа.

Источник↗

Заменить фрагментированный мониторинг унифицированной наблюдаемостью по всем сервисам.

→CloudWatch ServiceLens для карты сервисов; X-Ray для трассировок; CloudWatch Logs Insights для ad-hoc; Container Insights для ECS/EKS; RUM для браузера; Synthetics для канареечных развертываний.

Почему: Нативный стек AWS избегает агентов для каждого хоста. Сочетайте с OpenTelemetry SDK для переносимости.

Источник↗

Трассировка запроса через сервисы в 5 аккаунтах.

→Меж-аккаунтная наблюдаемость X-Ray. Исходные аккаунты делятся трассировками с центральным аккаунтом мониторинга через OAM.

Почему: Без OAM трассировки фрагментируются по аккаунтам. Меж-аккаунтная агрегация централизует представление пути запроса.

Источник↗

Просмотр метрик + журналов + трассировок из нескольких аккаунтов в одной консоли CloudWatch.

→CloudWatch Observability Access Manager (OAM). Исходные аккаунты связываются с аккаунтом мониторинга через sink + link.

Почему: OAM — это каноническая многоаккаунтная структура наблюдаемости. Устраняет необходимость переключения между консолями аккаунтов.

Источник↗

Медленная работа кластера Aurora — определение лучших SQL-запросов по событию ожидания.

→Performance Insights включены на кластере. Анализ лучших SQL-запросов по нагрузке + ожиданию без выгрузки журнала запросов.

Почему: PI собирает события ожидания с низкими накладными расходами. Метрики CloudWatch говорят вам, что что-то медленно, PI говорит вам, что именно.

Источник↗

Автоматическое обнаружение аномалий в DynamoDB / RDS / Lambda / ECS без написания порогов тревоги.

→Amazon DevOps Guru. Обнаружение аномалий на основе ML по операционным метрикам + коррелированным событиям.

Почему: Статические пороги пропускают редкие режимы. DevOps Guru изучает базовые показатели и предупреждает об отклонениях от нормы.

Источник↗

Плановое обновление 5000 экземпляров EC2 без скриптов для каждого экземпляра.

→SSM Patch Manager с базовыми показателями исправлений + окнами обслуживания. Целевое таргетирование на основе тегов; автоматическое одобрение исправлений безопасности через N дней.

Почему: Patch Manager централизует весь жизненный цикл исправлений. Самоуправляемые скрипты расходятся и пропускают новые экземпляры.

Источник↗

Автоматическое устранение сбоев правил Config (например, открытая группа безопасности) без участия человека.

→Действие по исправлению Config, вызывающее документ SSM Automation. Предварительно созданные `AWS-DisablePublicAccessForSecurityGroup` и т.д.

Почему: Config обнаруживает; SSM Automation действует. Более быстрый цикл, чем SNS → человек → тикет.

Источник↗

Золотой конвейер AMI/образов контейнеров должен быть воспроизводимым и актуальным по исправлениям.

→Конвейер EC2 Image Builder. Исходный AMI → рецепт (компоненты) → тест → распространение по регионам/аккаунтам.

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

Источник↗

Непрерывное сканирование CVE по EC2 + образам ECR + Lambda.

→Amazon Inspector v2 с включением по всей организации. Результаты поступают в Security Hub.

Почему: Inspector v2 охватывает EC2 + образы контейнеров + зависимости Lambda в одном сервисе. Ручное сопоставление CVE невозможно в масштабе.

Источник↗

Проверить, что многоуровневое приложение может соответствовать RTO 1 час / RPO 15 минут.

→AWS Resilience Hub. Определить политику → оценить приложение → рекомендации + автоматизированные планы действий.

Почему: Resilience Hub формализует заявки RTO/RPO с конкретными тестами. Ручные планы DR расходятся.

Источник↗

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

→AWS Fault Injection Service (FIS). Шаблонизированные эксперименты — уничтожение инстансов, дросселирование API, внедрение задержек. Запуск во время Дней Игр.

Почему: Chaos-engineering как услуга. Реальный сбой выявляет хрупкие предположения; чтение планов действий — нет.

Источник↗

Межрегиональное переключение — автоматическая проверка готовности + эвакуация зон.

→Route 53 Application Recovery Controller. Проверки готовности + элементы управления маршрутизацией для переключения на основе ячеек.

Почему: Простые проверки работоспособности Route 53 оценивают конечные точки. ARC добавляет активные/резервные плоскости управления для явного, аудируемого переключения.

Источник↗

Обновление основной версии RDS с возможностью отката.

→Развертывания RDS Blue/Green. Запуск зеленого клона с новой версией; повторное воспроизведение binlog; переключение менее чем за 1 минуту.

Почему: На месте основное обновление необратимо. Blue/Green сохраняет старую БД в рабочем состоянии до успешного переключения.

Источник↗

Уменьшить радиус поражения неудачных развертываний с автоматическим откатом.

→CodeDeploy с конфигурацией Canary (например, `CodeDeployDefault.ECSCanary10Percent5Minutes`). Тревога CloudWatch запускает откат.

Почему: Canary ограничивает сбой до 10% в течение 5 минут. "Все сразу" — максимальный радиус поражения; "постепенный" распространяет, но без проверки на основе трафика.

Источник↗

Функции Lambda чрезмерно провизионированы по памяти.

→Compute Optimizer для Lambda. Рекомендации по настройке памяти на основе профилей вызовов.

Почему: Конечный автомат AWS Lambda Power Tuning является альтернативой — Compute Optimizer работает автоматически.

Источник↗

Генерация политики IAM с минимальными привилегиями на основе наблюдаемой активности CloudTrail.

→Генерация политики IAM Access Analyzer. Анализирует CloudTrail для роли; выдает политику только используемых действий.

Почему: Лучше, чем вручную перебирать `iam:Get*` и т.д. Используйте сгенерированную политику как отправную точку, затем проверьте.

Источник↗

Неудачное соединение от EC2 к RDS — выяснить причину без захвата пакетов.

→VPC Reachability Analyzer. Статический анализ таблиц маршрутизации, SG, NACL, NAT, пиринга. Возвращает блокирующий фактор.

Почему: Быстрее, чем tcpdump. Идентифицирует конкретную конфигурацию (какое правило SG, какое отклонение NACL).

Источник↗

Аудит того, какие пути из интернета могут достигать внутренних ресурсов.

→VPC Network Access Analyzer. Выражения области действия описывают запрещенные пути (например, интернет → уровень БД). Возвращает соответствующие пути.

Почему: Reachability Analyzer работает "точка-точка"; Network Access Analyzer — это соответствие в масштабе всей области действия.

Источник↗

Быстрые победы в оптимизации затрат по всей организации.

→Проверки Trusted Advisor по оптимизации затрат (требуется поддержка Business/Enterprise). Простаивающие ELB, EC2 с низкой загрузкой, неиспользуемые EIP, использование RI.

Почему: Бесплатный уровень TA ограничен; Business+ открывает все проверки. Обзор организации с делегированным администратором показывает агрегированные результаты.

Источник↗

Lambda → RDS штормы подключений истощают соединения БД.

→RDS Proxy. Пул соединений между Lambda и RDS/Aurora. Более быстрое переключение (~66% сокращение).

Почему: Параллелизм Lambda создает одно соединение на вызов в худшем случае. Proxy мультиплексирует на небольшой пул.

Источник↗

Коэффициент промахов кэша для длиннохвостого контента на источнике слишком высок — источник под нагрузкой.

→CloudFront Origin Shield в регионе, близком к источнику. Дедублирует запросы по периферии, прежде чем они достигнут источника.

Почему: Без Origin Shield каждый POP независимо отправляет запросы к источнику. Shield снижает частоту обращений к источнику примерно на 70%.

Источник↗

Перенести 200 локальных серверов в EC2 с минимальным временем простоя.

→AWS Application Migration Service (MGN). Непрерывная блочная репликация; переключение для каждого сервера за минуты.

Почему: MGN — это рекомендованный AWS инструмент для повторного размещения (заменил SMS + CloudEndure). Переключение для каждого сервера позволяет волновую миграцию.

Источник↗

Миграция локальной Oracle на Aurora PostgreSQL с минимальным временем простоя.

→Schema Conversion Tool (SCT) для перезаписи схемы + процедур. AWS DMS для полной загрузки + CDC.

Почему: SCT занимается кодом; DMS — данными. CDC поддерживает синхронизацию источника до переключения.

Источник↗

Обнаружить все локальные базы данных и оценить сложность миграции.

→AWS DMS Fleet Advisor. Инвентаризация + оценка разнородных флотов в масштабе.

Почему: Fleet Advisor объединяет обнаружение + определение размера в один рабочий процесс перед запуском задач DMS.

Источник↗

Категоризировать 500 приложений для стратегии миграции.

→Фреймворк Seven Rs: Retire (вывести из эксплуатации), Retain (оставить локально), Relocate (перенос в VMware Cloud), Rehost (MGN), Replatform (RDS вместо самостоятельно управляемой БД), Repurchase (отказ от приложения и использование SaaS), Refactor (микросервисы).

Почему: Большие портфели смешивают все 7. Раннее сопоставление для каждого приложения позволяет избежать долга миграции по принципу "один размер для всех".

Источник↗

Создать инвентаризацию миграции с зависимостями перед началом волн.

→AWS Application Discovery Service. Без агента (сканирование vCenter) или на основе агента (для каждого сервера). Выводит карту зависимостей.

Почему: Без карты зависимостей планирование волн пропускает тесные связи. Discovery автоматически выявляет их.

Источник↗

Отслеживание сотен текущих миграций серверов + БД через MGN, DMS, вручную.

→AWS Migration Hub как единый интерфейс. Агрегирует статус из MGN, DMS, Refactor Spaces.

Почему: Консоли для каждого инструмента фрагментируют статус. Migration Hub консолидирует и поддерживает отчетность по портфелю.

Источник↗

Перемещение 100 ТБ с удаленной площадки без доступной WAN-пропускной способности.

→AWS Snowball Edge Storage Optimized. Отправьте устройство, скопируйте локально, верните в AWS. Несколько устройств параллельно для >80 ТБ.

Почему: Snowmobile (45 ПБ) для экзабайтов; Snowcone (8 ТБ) для небольших объемов. Edge — это рабочая лошадка петабайтного масштаба.

Источник↗

Непрерывная репликация данных локальной NFS → S3 с ограничениями пропускной способности.

→Агент AWS DataSync. Запланированные задачи; ограничение пропускной способности для каждой задачи; режим верификации для целостности.

Почему: DataSync специально разработан и в 10 раз быстрее, чем самоуправляемый rsync по WAN. Snowball работает в автономном режиме; DataSync — в режиме онлайн.

Источник↗

Локальное приложение ожидает NFS/SMB, но данные должны попасть в S3.

→File Gateway в Storage Gateway. Локальный кэш + S3-бэкенд; объекты также доступны через S3 API.

Почему: Volume Gateway предоставляет iSCSI; Tape Gateway эмулирует VTL. File Gateway — это мост NAS-to-S3.

Источник↗

Компания, активно использующая VMware, хочет получить мощности AWS без перенастройки vSphere/NSX.

→VMware Cloud on AWS. Тот же стек vSphere на bare-metal хостах AWS. Используйте HCX для живой миграции.

Почему: Сохраняет операционные инструменты. Мост перед рефакторингом. Затем постепенно перейдите на нативные сервисы AWS.

Источник↗

Контейнеризация унаследованных монолитов Java/.NET без переписывания.

→CLI AWS App2Container. Инспектирует работающее приложение, генерирует артефакты контейнера + манифесты ECS/EKS.

Почему: A2C захватывает конфигурацию времени выполнения (среда, порты, зависимости) в рабочий образ. Ручная контейнеризация пропускает неочевидные зависимости.

Источник↗

Модернизация мейнфрейма COBOL — конвертация в Java-микросервисы.

→Сервис AWS Mainframe Modernization с Blu Age (рефакторинг) или Micro Focus (переплатформирование). Выбирайте на основе толерантности к эмуляции во время выполнения.

Почему: Рефакторинг открывает облачные нативные паттерны; переплатформирование быстрее, но эмулирует мейнфрейм. Оба уменьшают стоимость лицензии мейнфрейма.

Источник↗

Декомпозиция монолита в течение 18 месяцев без замораживания разработки.

→Паттерн "Strangler Fig". Перед монолитом разместите API Gateway/ALB; маршрутизируйте конкретные конечные точки на новые микросервисы по мере их выделения.

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

Хочу инкрементально извлекать микросервисы, не владея плоскостью маршрутизации.

→AWS Migration Hub Refactor Spaces. Управляемая абстракция приложений/маршрутов/сервисов поверх API Gateway + VPC.

Почему: Экономит написание инфраструктуры "Strangler Fig". Предварительно настроенная маршрутизация + подключение VPC для инкрементального извлечения.

Источник↗

Самостоятельно управляемый PostgreSQL на EC2 → RDS для управляемых операций.

→DMS для переключения с CDC. Используйте RDS Custom только если вам нужен доступ к ОС или специфические для поставщика расширения.

Почему: RDS управляет резервными копиями/патчами/HA. RDS Custom — это запасной выход для унаследованных потребностей, но он вновь вводит операционную нагрузку.

Источник↗

Переход с RDS MySQL на Aurora MySQL для повышения производительности + снижения затрат.

→Aurora read replica из RDS, затем продвижение. Или DMS для нулевого времени простоя, когда важны расхождения версий.

Почему: Путь read-replica является самым простым внутри движка. DMS обрабатывает различия версий и гетерогенные перемещения.

Источник↗

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

→Программа ускорения миграции AWS (MAP). Фазы: Оценка (MRA), Мобилизация (партнер MAP + инструменты), Миграция и Модернизация.

Почему: MAP открывает финансирование и структурированную методологию. Пропуск MAP упускает и то, и другое.

Источник↗

Предварительная оценка стоимости миграции для исполнительного спонсора.

→AWS Pricing Calculator (спроектированная конфигурация) + Migration Evaluator (управляемый данными из локальной инвентаризации).

Почему: Pricing Calculator предоставляет ценообразование по принципу "что, если". Migration Evaluator принимает данные vSphere/Hyper-V для прогнозирования фактической экономии.

Источник↗

Вывод из эксплуатации самоуправляемых SFTP-серверов; партнерам-поставщикам необходимо продолжать использовать SFTP.

→AWS Transfer Family (SFTP/FTPS/FTP) с поддержкой S3 или EFS.

Почему: Управляемый протокольный сервис. Пользователи, сопоставленные с IAM; конечные точки только VPC. Избегает запуска демонов SSH на EC2.

Источник↗

Подъем и перенос файловых ресурсов Windows с интеграцией AD.

→Amazon FSx for Windows File Server. Присоединение к AD; SMB; DataSync для онлайн-синхронизации из локальной среды; Snowball для массовой передачи.

Почему: FSx for Windows — это нативная для AD целевая зона. EFS только для Linux; S3 не хватает семантики SMB.

Источник↗

Миграция рабочих нагрузок NetApp ONTAP с сохранением всех функций NetApp (снимки, FlexClone).

→Amazon FSx for NetApp ONTAP. Нативные API ONTAP; мультипротокольные NFS+SMB; репликация SnapMirror из локальной среды.

Почему: Другие варианты FSx не предоставляют специфические для ONTAP функции. Подъем и перенос NetApp без перепроектирования резервного копирования/репликации.

Источник↗

Переключение на основе DNS рискует остаточными данными в кэше DNS.

→Переключение за CloudFront / ALB / Global Accelerator. Переключение бэкенда без изменения публичного DNS.

Почему: Кэши уважают TTL, но клиенты/брандмауэры агрессивно кэшируют. Стабильный публичный адрес изолирует от остаточных данных DNS.

Источник↗

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

→Маршрутизация по весу Route 53. Начать 1% → AWS, постепенно увеличивать. Проверки работоспособности для автоматического отката.

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

Источник↗

Отслеживание лицензий Windows / Oracle / SQL Server BYOL по мигрированным рабочим нагрузкам.

→AWS License Manager. Определить правила; применять при запуске; делиться через RAM по всей организации.

Почему: Несоблюдение BYOL обходится дорого. License Manager предотвращает случайное чрезмерное развертывание.

Источник↗

После миграции, dev/test экземпляры RDS чрезмерно провизионированы на ночь.

→Мигрировать dev/test на Aurora Serverless v2 с низким минимальным ACU. Автоматически масштабироваться вниз в простое.

Почему: Экономит ночные затраты на простой без сложности планировщика инстансов.

Источник↗

Запуск Kubernetes локально с теми же инструментами, что и EKS во время миграции.

→EKS Anywhere на локальном оборудовании. Те же версии Kubernetes + интеграция ECR + AWS Outposts.

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

Источник↗