Справочник - SAP-C02 AWS Certified Solutions Architect Professional

Развернуть инфраструктуру 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 позже - это перемещение рабочей нагрузки, а не переписывание инструментов.

Источник