Справочник

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

→Включите автоматический выключатель развертывания ECS с откатом на сервисе ECS.

Почему: Встроенная функция ECS, которая автоматически откатывается, если новые задачи не стабилизируются. Минимум операционных издержек по сравнению с пользовательским опросом CodeBuild или сложными настройками CodeDeploy.

Источник↗

Развернуть в основном регионе, проверить с помощью автоматизированных тестов, затем развернуть в других регионах параллельно.

→Используйте единый CodePipeline с последовательными этапами: (1) Развертывание в Регионе А, (2) этап тестирования CodeBuild, выполняющий проверку, (3) параллельный этап развертывания для Регионов B и C.

Почему: CodeBuild выступает в качестве автоматизированного, программного шлюза. Один конвейер проще, чем оркестровка нескольких конвейеров с помощью Step Functions.

Длительно выполняющийся скрипт валидации в хуке жизненного цикла CodeDeploy приводит к преждевременному успешному завершению развертывания.

→Увеличьте свойство `timeout` для конкретного скрипта хука жизненного цикла в файле `AppSpec.yml`.

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

Ускорить медленные сборки Docker-образов CodeBuild, вызванные повторной загрузкой зависимостей и слоев образов при каждом запуске.

→В конфигурации проекта CodeBuild включите `LOCAL_DOCKER_LAYER_CACHE` и настройте кэш S3 для каталогов зависимостей (например, `.m2`, `node_modules`).

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

Реализовать канареечное развертывание для функции Lambda с автоматическим откатом на основе метрик.

→Используйте AWS SAM с `DeploymentPreference` (например, тип `Canary10Percent5Minutes`). Добавьте CloudWatch тревогу по метрике `Errors` в качестве триггера отката.

Почему: SAM нативно интегрируется с CodeDeploy для Lambda, автоматизируя переключение трафика по алиасам, мониторинг и откат без пользовательских скриптов.

Источник↗

Настройте IAM для CodePipeline в Аккаунте A для развертывания ресурсов в Аккаунт B.

→Роль конвейера (Аккаунт A) принимает роль действия (Аккаунт B). Роль действия в B доверяет роли конвейера и имеет разрешения на развертывание. Бакет артефактов S3 и ключ KMS в A должны иметь политики ресурсов, предоставляющие доступ к роли действия в B.

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

Реализовать рабочий процесс GitOps для EKS, где состояние кластера автоматически и непрерывно согласовывается с репозиторием Git.

→Разверните контроллер GitOps (например, Flux, ArgoCD) в кластере EKS. Настройте его для мониторинга репозитория Git и применения/согласования изменений.

Почему: Это стандартный "pull-based" шаблон GitOps. Внутрикластерный контроллер обрабатывает непрерывное согласование и обнаружение дрейфа, что является основным принципом GitOps.

Разрешить проекту CodeBuild в центральном инструментальном аккаунте развертывать манифесты Kubernetes в кластерах EKS в отдельных аккаунтах рабочих нагрузок.

→В каждом аккаунте рабочей нагрузки создайте межаккаунтную роль IAM, которой доверяет роль CodeBuild. Сопоставьте эту новую роль с группой Kubernetes RBAC в `aws-auth` ConfigMap кластера EKS. Скрипт CodeBuild принимает роль перед запуском `kubectl`.

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

Выполнить сложную миграцию схемы RDS PostgreSQL или MySQL с нулевым или почти нулевым временем простоя.

→Используйте функцию Amazon RDS Blue/Green Deployments. Создайте синхронизированную промежуточную (зеленую) среду, примените к ней изменения схемы, а затем переключитесь, чтобы продвинуть ее в производство.

Почему: Это специально разработанный управляемый сервис для безопасных обновлений RDS с нулевым временем простоя. Он обрабатывает клонирование, синхронизацию и быстрое (< 1 мин) переключение со встроенными защитными механизмами.

Развернуть новую версию одностраничного приложения (SPA) в S3/CloudFront и убедиться, что пользователи немедленно получают новую версию с минимальными затратами на инвалидацию кэша.

→Используйте хеширование на основе содержимого для имен файлов активов (например, `app.a1b2c3d4.js`). После развертывания новых активов инвалидируйте только файл `index.html` в дистрибуции CloudFront.

Почему: Хешированные имена файлов уникальны, поэтому CloudFront рассматривает их как новые объекты и извлекает их из источника, минуя кэш. Только один файл точки входа (`index.html`) нуждается в инвалидации, что значительно дешевле, чем инвалидация с использованием подстановочного знака (`/*`).

Реализовать конвейер CI/CD для приложения AWS CDK, который автоматически обновляется при изменении собственного определения конвейера.

→Используйте конструкт CDK Pipelines (`pipelines.CodePipeline`). Этот конструкт создает конвейер, который по умолчанию включает этап `SelfMutate`.

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

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

→Реализуйте шаблон "расширение и сжатие" (или параллельное изменение). Сначала разверните дополнительные, обратно совместимые изменения схемы базы данных. Во-вторых, разверните новую версию приложения, которая использует новую схему. И старые, и новые версии приложения могут сосуществовать с обновленной базой данных.

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

Постепенно выкатывать новую функцию для определенных сегментов пользователей и измерять ее влияние на бизнес-метрики (например, коэффициент конверсии) с помощью A/B-тестирования.

→Используйте Amazon CloudWatch Evidently. Создайте функцию с несколькими вариантами, запуск для контроля процента развертывания и эксперимент для измерения статистического влияния на определенные метрики.

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

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

→Используйте политику управления сервисами (SCP), которая запрещает `ec2:RunInstances`, если в запросе отсутствуют требуемые ключи тегов.

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

Источник↗

Управлять и ротировать секреты (например, учетные данные БД), используемые приложениями в нескольких аккаунтах, без простоя.

→Используйте AWS Secrets Manager с включенной автоматической ротацией. Предоставьте межаккаунтный доступ, используя политики на основе ресурсов для секрета.

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

Автоматически развертывать базовые ресурсы безопасности в новые аккаунты, созданные через Control Tower Account Factory.

→Используйте событие жизненного цикла Control Tower `CreateManagedAccount` через EventBridge для запуска функции Lambda, которая развертывает CloudFormation StackSet. Альтернативно, используйте Customizations for AWS Control Tower (CfCT).

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

Включить доступ SSM Session Manager к инстансам EC2 в частной подсети без доступа к интернету.

→Создайте конечные точки интерфейса VPC (на базе PrivateLink) для сервисов `ssm`, `ssmmessages` и `ec2messages` в VPC.

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

Централизовать логи с долгосрочным хранением и защитить их от удаления или изменения, даже администраторами.

→Храните логи в бакете S3 с S3 Object Lock в режиме соответствия. Включите проверку целостности файлов логов CloudTrail.

Почему: Object Lock (режим соответствия) обеспечивает защиту WORM, которую не может обойти даже корневой аккаунт. Проверка целостности файлов логов обеспечивает криптографическую проверку на предмет изменения после доставки.

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

→Используйте AWS Service Catalog. Создайте портфель утвержденных продуктов (определенных шаблонами CloudFormation). Используйте ограничения запуска, чтобы Service Catalog развертывал ресурсы, используя привилегированную роль IAM, управляемую командой платформы.

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

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

→Создайте отдельные секреты AWS Secrets Manager для каждого сервиса. В определении задачи ECS ссылайтесь на ARNs секретов в свойстве `secrets` определения контейнера. Ограничьте политику роли IAM для выполнения задачи, разрешив только `secretsmanager:GetSecretValue` для конкретного ARN секрета этого сервиса.

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

Разрешить рабочему процессу GitHub Actions безопасно получать доступ к AWS без хранения долгосрочных учетных данных.

→Настройте поставщика идентификаторов IAM OIDC для GitHub. Создайте роль IAM с политикой доверия, ограничивающей федеративного субъекта определенной организацией GitHub, репозиторием и веткой. Используйте действие `aws-actions/configure-aws-credentials` с OIDC для принятия роли.

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

Постоянно отслеживать все политики IAM в рамках AWS Organization для выявления и оповещения о ресурсах, совместно используемых с внешними сущностями.

→Включите IAM Access Analyzer на уровне организации, определив организацию как зону доверия. Используйте EventBridge для захвата новых обнаружений и запуска уведомлений.

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

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

→Разделите архитектуру на независимые стеки, используя межстековые ссылки (CloudFormation Exports/Fn::ImportValue).

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

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

→Используйте AWS Systems Manager Patch Manager с пользовательскими базовыми уровнями исправлений, отдельными окнами обслуживания для каждой среды и Systems Manager Explorer для централизованной отчетности о соответствии.

Почему: Нативно поддерживает все требования: пользовательские определения исправлений, гибкое планирование через окна обслуживания и видимость между аккаунтами через Explorer.

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

→Создайте и просмотрите набор изменений CloudFormation для операции StackSet перед выполнением.

Почему: Наборы изменений — это нативный механизм CloudFormation для предварительного просмотра точных изменений ресурсов (добавление, изменение, удаление), которые будет выполнять обновление.

Убедитесь, что CloudFormation ожидает успешного завершения скрипта UserData инстанса EC2, прежде чем продолжить создание стека.

→Добавьте `CreationPolicy` с `ResourceSignal` к ресурсу инстанса EC2. Вызовите вспомогательный скрипт `cfn-signal` из UserData после успешного завершения.

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

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

→Периодически запускайте обнаружение дрейфа CloudFormation в стеке. Для непрерывного обнаружения используйте правило AWS Config `cloudformation-stack-drift-detection-check`.

Почему: Обнаружение дрейфа — это нативная функция для сравнения шаблона стека с фактическим состоянием его ресурсов. Использование правила Config автоматизирует эту проверку.

Защитить ресурсы с сохранением состояния (например, бакет S3 или базу данных RDS) от случайного удаления или замены через операции стека CloudFormation.

→Для ресурса установите `DeletionPolicy: Retain` (или `Snapshot` для RDS). Для стека включите `TerminationProtection`. Примените `StackPolicy`, которая запрещает действия `Update:Replace` и `Update:Delete` для критического ресурса.

Почему: Обеспечивает глубокую защиту: Termination Protection предотвращает удаление стека, DeletionPolicy сохраняет ресурс, если стек удален, а Stack Policy предотвращает разрушительные обновления.

Мигрировать CloudFormation StackSet с комплексной, самоуправляемой модели ролей IAM на более простую модель разрешений для AWS Organization.

→Обновите StackSet для использования управляемых сервисом разрешений.

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

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

→Запустите машину состояний AWS Step Functions из функции Lambda пользовательского ресурса. Машина состояний обрабатывает длительную задачу, используя состояния Wait или шаблон Task Token, и отправляет ответ обратно на предварительно подписанный URL S3 CloudFormation.

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

Централизованно применять политику (например, все бакеты S3 должны иметь версионирование) ко всему приложению AWS CDK, независимо от того, как разработчики определяют свои ресурсы.

→Создайте CDK Aspect, который реализует интерфейс `IAspect`. Аспект посещает все конструкты в дереве приложения, находит все конструкты бакетов S3 и применяет требуемую конфигурацию или добавляет ошибку валидации, если она отсутствует.

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

Предотвратить выполнение автоматизированных операций, таких как патчинг через SSM Maintenance Windows, в течение определенных, изменяющихся периодов времени (например, квартальный финансовый блэкаут).

→Используйте SSM Change Calendar для определения событий, отмечающих периоды блокировки как "закрытые". Свяжите Change Calendar с окном обслуживания.

Почему: Change Calendar выступает в качестве шлюза для автоматизации. Он автоматически блокирует выполнение в "закрытые" периоды, не требуя ручных изменений в расписании Maintenance Window, что делает его высокоэффективным для управления динамическими периодами блокировки.

Централизованно управлять установкой и версионированием пользовательского программного пакета (например, агента мониторинга) на парке инстансов EC2.

→Упакуйте программное обеспечение с помощью SSM Distributor. Используйте SSM State Manager для создания ассоциации, которая применяет пакет Distributor ко всем целевым инстансам.

Почему: Distributor управляет жизненным циклом пакета (включая версии). State Manager обеспечивает непрерывное применение желаемого состояния (например, "установлена версия 1.2 агента"), автоматически устраняя дрейф и настраивая новые инстансы.

Аварийное восстановление с низкими показателями RPO (< 1 мин) и RTO (< 5 мин) для базы данных Aurora и уровня приложений в разных регионах.

→Используйте Aurora Global Database для репликации базы данных с задержкой менее секунды. Для уровня приложений используйте "теплый резерв" с группой Auto Scaling, установленной на желаемую емкость 0, для масштабирования вверх с помощью автоматизации при отказоустойчивости.

Почему: Aurora Global Database обеспечивает RPO менее секунды и RTO менее 1 минуты. Уровень приложений в режиме "теплого резерва" экономически эффективен, при этом соответствует быстрому RTO.

Сократить время масштабирования группы Auto Scaling для инстансов с длительным временем загрузки/инициализации.

→Создайте предварительно подготовленный "золотой AMI" с установленными зависимостями. Настройте теплый пул в группе Auto Scaling, чтобы инстансы оставались предварительно инициализированными.

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

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

→Включите автомасштабирование кластера ECS, связав поставщика емкости с группой автомасштабирования EC2 и кластером ECS.

Почему: Поставщики емкости связывают масштабирование сервиса ECS с масштабированием инстансов EC2. Когда задачи не удается разместить из-за недостаточных ресурсов кластера, поставщик емкости автоматически масштабирует ASG EC2.

Динамически масштабировать парк рабочих инстансов EC2 на основе количества сообщений в очереди SQS.

→Используйте политику Auto Scaling с отслеживанием цели, основанную на пользовательской метрике: `ApproximateNumberOfMessagesVisible` / `GroupInServiceInstances` (т.е., отставание на инстанс).

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

Создавать согласованные с приложением (не только crash-consistent) снимки томов EBS для stateful-приложений.

→Используйте AWS Backup с планом резервного копирования. В плане используйте Systems Manager Run Command для выполнения скриптов перед созданием снимка, чтобы привести приложение в состояние покоя (или включить VSS для Windows).

Почему: AWS Backup оркестрирует весь процесс. Приведение приложения в состояние покоя (сброс буферов ввода-вывода на диск) перед созданием снимка обеспечивает целостность данных и восстановимое состояние приложения.

Убедиться, что критические события из правила EventBridge не теряются, когда целевой сервис (например, Lambda) временно недоступен или подвергается дросселированию.

→Для цели правила EventBridge настройте политику повторных попыток (например, максимальный срок жизни 24 часа) и очередь недоставленных сообщений (DLQ) с использованием очереди SQS.

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

Запускать оповещения в реальном времени по определенным шаблонам журналов и включать контекстную информацию (например, окружающие строки журнала) в уведомление.

→Используйте фильтр подписки CloudWatch Logs для потоковой передачи совпадающих событий журнала в функцию Lambda. Функция Lambda форматирует и отправляет подробное уведомление (например, в SNS или Chime).

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

Идентифицировать узкие места задержки в распределенном приложении на основе микросервисов.

→Включите трассировку AWS X-Ray на точках входа (например, API Gateway, ALB) и вычислительных ресурсах (например, Lambda, ECS). Используйте X-Ray SDK для последующих вызовов. Проанализируйте карту сервисов и трассировки.

Почему: X-Ray — это специально разработанный сервис AWS для распределенной трассировки. Карта сервисов визуализирует цепочку вызовов и выделяет сервисы с высокой задержкой и частотой ошибок.

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

→Создайте индивидуальные тревоги CloudWatch для каждого уровня (например, частота ALB 5xx, ЦП приложения, соединения RDS). Затем объедините их с помощью составной тревоги CloudWatch с логикой ИЛИ.

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

Анализировать петабайты логов с помощью сложных SQL-запросов (включая объединения) и хранить их годами экономически эффективным способом.

→Потоковая передача логов в Amazon S3 через Kinesis Data Firehose. Каталогизация данных с помощью AWS Glue. Запрос с помощью Amazon Athena. Использование политик жизненного цикла S3 для перехода данных в Glacier/Deep Archive для долгосрочного хранения.

Почему: Это стандартная бессерверная архитектура озера данных. Athena предоставляет мощные возможности SQL для данных S3, а S3/Glacier предлагает наиболее экономичное долгосрочное хранение.

Мониторить метрику с предсказуемыми циклическими паттернами (например, ежедневные/еженедельные всплески) и запускать тревогу только при подлинных отклонениях от паттерна.

→Настройте обнаружение аномалий CloudWatch для метрики. Создайте тревогу, которая срабатывает, когда значение метрики выходит за пределы ожидаемого диапазона модели.

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

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

→Включите Amazon CloudWatch Container Insights для кластера EKS/ECS.

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

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

→Включите Amazon CloudWatch Internet Monitor для приложения.

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

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

→Интегрируйте JavaScript-сниппет CloudWatch RUM (Real User Monitoring) в веб-приложение.

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

Выдавать пользовательские метрики приложения из функции AWS Lambda с высоким разрешением и измерениями, не добавляя задержку и стоимость прямых вызовов API CloudWatch.

→Используйте CloudWatch Embedded Metric Format (EMF), записывая специально структурированный JSON в стандартный вывод. Клиентская библиотека может упростить это.

Почему: CloudWatch Logs автоматически и асинхронно извлекает метрики из записей логов EMF, не добавляя дополнительной задержки в функции Lambda и снижая затраты за счет избегания вызовов API PutMetricData.

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

→Используйте AWS Config авто-исправление с документом Systems Manager Automation. Плейбук останавливает инстанс, создает зашифрованную копию тома, меняет тома и перезапускает инстанс.

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

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

→Используйте AWS Fault Injection Simulator (FIS) с шаблоном эксперимента. Определите условия остановки на основе CloudWatch тревог, которые отслеживают ключевые метрики приложения.

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

Стек CloudFormation застрял в состоянии `UPDATE_ROLLBACK_FAILED`, потому что ресурс был удален или изменен во время неудачного обновления, что предотвратило чистый откат.

→Используйте действие API `ContinueUpdateRollback`, указав логический ID проблемного ресурса в параметре `ResourcesToSkip`.

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

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

→Создайте правила Amazon EventBridge, которые соответствуют определенным шаблонам событий управления CloudTrail и направляют их в тему SNS для уведомления.

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

Функция Lambda с высоким трафиком подвергается дросселированию и также исчерпывает соединения с базой данных RDS при масштабировании.

→Запросите увеличение лимита параллельного выполнения Lambda. Реализуйте Amazon RDS Proxy между функциями Lambda и базой данных RDS.

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

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

→Используйте маршрутизацию отказа Route 53 с связанными проверками работоспособности. Создайте правило EventBridge, которое захватывает событие изменения статуса проверки работоспособности Route 53 и запускает плейбук автоматизации Systems Manager.

Почему: Эта архитектура сочетает автоматическое переключение трафика (Route 53) с автоматизированным реагированием на инциденты, управляемым событиями (EventBridge + SSM Automation), для полного шаблона отказоустойчивости.

Предотвратить исчерпание хранилища базой данных RDS и, как следствие, сбой приложения.

→Включите автомасштабирование хранилища RDS, установив максимальный порог хранилища. В качестве дополнительного контроля создайте тревогу CloudWatch по метрике `FreeStorageSpace`.

Почему: Автомасштабирование хранилища — это проактивная, управляемая функция, которая автоматически увеличивает выделенное хранилище. Тревога CloudWatch обеспечивает подстраховку для мониторинга и оповещения.

Необходимо повторно обработать партию событий, которые были обработаны некорректно из-за временной ошибки в потребителе.

→Предварительно настройте архив EventBridge на шине событий. После исправления ошибки создайте Replay для повторной отправки событий из конкретного временного окна инцидента.

Почему: Архив и повторное воспроизведение — это нативная функция EventBridge для хранения и повторной обработки исторических событий, что критически важно для восстановления после временных сбоев обработки.

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

→Создайте план реагирования SSM Incident Manager, который определяет все шаги взаимодействия и устранения. Настройте тревогу CloudWatch так, чтобы она запускала этот план реагирования в качестве своего действия.

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