Amazon SAA-C03: Высокая доступность, отказоустойчивость и аварийное восстановление — Руководство по подготовке

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

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

Развертывания Multi-AZ и репликация

Архитектуры Multi-AZ предназначены для защиты от сбоя одного центра обработки данных или зоны доступности — и не более того. Это различие — самый частый источник недопонимания при проектировании высокодоступных систем. Развертывание Multi-AZ выдерживает потерю одной зоны доступности в пределах одного региона; оно не выдерживает сбой всего региона, нарушение работы регионального сервиса или случайное удаление ресурса, которое немедленно реплицируется на резервный экземпляр. Репликация добросовестно распространяет и неверные данные — логические повреждения, ошибки в схеме, запись данных программами-вымогателями. Именно поэтому репликация и резервное копирование дополняют друг друга, а не заменяют.

Для Amazon RDS в режиме Multi-AZ создается синхронная резервная реплика в другой зоне доступности. Записи фиксируются на обоих экземплярах до получения подтверждения, что обеспечивает RPO, фактически равный нулю, и RTO обычно в пределах 60–120 секунд при автоматическом переключении на резерв. В классическом развертывании Multi-AZ с одним экземпляром (instance) резервная реплика недоступна для чтения — она существует исключительно для обеспечения долговечности и аварийного переключения. Кластерные развертывания Multi-AZ (с двумя читаемыми резервными репликами) еще больше сокращают время переключения и обеспечивают некоторое масштабирование чтения, но по-прежнему ограничены одним регионом.

Для масштабирования чтения добавляйте реплики для чтения (read replicas). Реплики для чтения используют асинхронную репликацию и служат для снятия нагрузки с основного экземпляра, связанной с запросами для отчетов, аналитики и дашбордов. Рассматривать реплику для чтения как механизм отказоустойчивости (HA) неверно по трем причинам: репликация асинхронна (потеря данных при «повышении» реплики), «повышение» выполняется вручную или по скрипту (не автоматически), и основная конечная точка не сохраняется. Когда растущей рабочей нагрузке требуется больше мощностей для чтения без усложнения архитектуры, добавляйте реплику для чтения; когда требуется автоматическое переключение на резерв с нулевой потерей данных, используйте Multi-AZ. Когда RPO/RTO для реляционной СУБД должны выдерживать сбой целого региона, Aurora Global Database обеспечивает межрегиональную задержку репликации менее секунды и управляемое аварийное переключение с RTO менее минуты.

Amazon ElastiCache следует той же схеме с группами репликации. Группа репликации Redis с включенным Multi-AZ поддерживает основной узел (primary) и одну или несколько реплик в разных зонах доступности; если основной узел выходит из строя, ElastiCache «повышает» одну из реплик и обновляет основную конечную точку. Для горизонтального масштабирования Redis (в режиме кластера) разделяет данные по шардам (shards), каждый из которых является отдельной группой репликации. В отличие от него, Memcached не выполняет репликацию — потеря узла означает потерю данных для этого раздела.

Amazon FSx предлагает типы развертывания Multi-AZ для FSx for Windows File Server и FSx for ONTAP, используя синхронную репликацию между основным (preferred) и резервным (standby) файловыми серверами. FSx for Lustre, как правило, работает в одной зоне доступности (в режиме scratch или persistent); долговечность для Lustre обеспечивается за счет связи с репозиторием данных в S3, а не за счет репликации между зонами доступности.

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

Автоматическое резервное копирование RDS и восстановление на определенный момент времени

Автоматическое резервное копирование RDS сочетает ежедневный снимок с непрерывной выгрузкой логов транзакций в S3 каждые 5 минут, обеспечивая восстановление на определенный момент времени (PITR) с точностью до секунды в пределах окна хранения от 1 до 35 дней. Если ваш RPO составляет 2 часа, встроенное резервное копирование RDS уже удовлетворяет этому требованию — не нужно настраивать дополнительное расписание для снимков, а использование AWS Backup поверх этого будет избыточным, если только вам не нужны межрегиональные копии, изоляция между аккаунтами или семантика Vault Lock, выходящая за рамки возможностей копирования снимков RDS. Автоматическое резервное копирование по умолчанию часто является самым дешевым и правильным решением для умеренных требований к RPO.

AWS Backup как централизованная плоскость управления

AWS Backup — это управляемая политиками плоскость управления для резервного копирования таких сервисов, как EBS, EC2 (в виде AMI), RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway, S3 и других. Вместо написания скриптов для создания снимков в каждом конкретном сервисе, вы определяете планы резервного копирования (backup plans), которые группируют правила, описывающие частоту, окно резервного копирования, окна начала/завершения, переходы жизненного цикла в холодное хранилище, срок хранения и целевые хранилища. Ресурсы включаются в план через назначения ресурсов (resource assignments) по тегу или ARN, поэтому соглашение о тегировании, например Backup=Daily, становится операционным контрактом, определяющим охват. Для парка из сотен экземпляров EC2 выбор на основе тегов является наименее трудоемким подходом — просто примените тег и позвольте AWS Backup составить список ресурсов, вместо того чтобы создавать расписания для каждого экземпляра.

Хранилище резервных копий (backup vault) — это зашифрованный с помощью KMS контейнер, в котором хранятся точки восстановления. Доступ к нему контролируется политиками ресурсов самого хранилища.

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

Межрегиональное и меж-аккаунтное копирование

Блок CopyActions — это механизм для создания межрегиональных копий для аварийного восстановления (DR). AWS Backup управляет копированием снимка, повторно шифрует его с помощью KMS-ключа в целевом регионе (целевое хранилище должно ссылаться на ключ в этом регионе) и применяет независимый жизненный цикл. Снимки EBS и RDS по умолчанию хранятся в исходном регионе — если весь регион выйдет из строя, то же самое произойдет и со снимками. Любое нормативное или бизнес-требование, упоминающее региональную отказоустойчивость, должно включать явный шаг межрегионального копирования, будь то через действия копирования в AWS Backup, межрегиональное копирование автоматических снимков RDS или политики DLM с межрегиональными назначениями.

Для меж-аккаунтного копирования AWS Organizations делегирует административный аккаунт для AWS Backup; политика исходного хранилища разрешает доступ целевому аккаунту, а целевое хранилище разрешает копирование из источника. Это экономически эффективный способ централизации аварийного восстановления: один управляющий аккаунт хранит точки восстановления из многих рабочих аккаунтов и может восстанавливать их в любом из регионов. Для EC2 копия AMI во второй регион плюс предоставление общего доступа к снимку позволяют запускать там экземпляры без «прогретой» инфраструктуры. Для зашифрованных снимков требуется предоставить доступ к CMK — целевой аккаунт или регион нуждается в разрешении kms:CreateGrant и доступе к ключу. Именно из-за отсутствия этого разрешения восстановление между аккаунтами молча завершается неудачей.

Требование RPO в 24 часа легко и дешево удовлетворяется ежедневным автоматическим снимком, копируемым в другой регион — это гораздо дешевле, чем межрегиональная реплика для чтения или «прогретый» резервный кластер. Переходить к непрерывной репликации следует только тогда, когда требуемый RPO становится меньше, чем может обеспечить частота создания снимков.

Жизненный цикл AMI и резервное копирование EC2

Два механизма автоматизируют резервное копирование EC2: Data Lifecycle Manager (DLM) и AWS Backup. DLM появился раньше AWS Backup и позволяет создавать по расписанию снимки EBS или AMI на основе политик, с возможностью копирования в другие регионы и аккаунты. AWS Backup включает в себя эти функции и добавляет централизованное управление политиками, Vault Lock и поддержку множества сервисов. Предпочитайте AWS Backup, если вы уже используете его для других сервисов; используйте DLM для сценариев, ограниченных только EBS/AMI, где вам не нужны функции хранилища (vault).

Для stateless веб-уровней за Auto Scaling группой, не имеющих постоянных локальных данных, резервное копирование запущенных инстансов EC2 является избыточным. Правильный подход — создать «закаленный» (hardened) AMI (с помощью EC2 Image Builder или CI-пайплайна), указать его в шаблоне запуска и позволить ASG управлять заменой инстансов. Усилия по резервному копированию следует сосредоточить на stateful-уровнях, чьи нативные автоматизированные бэкапы соответствуют RPO.

Неизменяемость: Vault Lock и Object Lock

Обычный снимок в вашем аккаунте может быть удален любым, у кого есть соответствующее разрешение IAM — сами по себе снимки не удовлетворяют требованиям неизменяемости. Нормативные режимы (SEC 17a-4, FINRA, HIPAA, GDPR) часто требуют хранения данных по принципу «однократная запись, многократное чтение» (WORM), которое не могут обойти даже администраторы. В AWS это обеспечивается двумя механизмами.

AWS Backup Vault Lock применяет WORM-политику к хранилищу резервных копий (backup vault):

В режиме Compliance, после истечения периода «остывания», ни один пользователь, включая root-аккаунт, не может сократить срок хранения, удалить точки восстановления до их истечения или снять саму блокировку. Это защищает как от удаления инсайдером, так и от действий оператора программы-вымогателя, который полностью скомпрометировал аккаунт.

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

S3 Object Lock обеспечивает WORM на уровне объектов в режиме Governance (привилегированные пользователи с разрешением s3:BypassGovernanceRetention могут обойти блокировку) или в режиме Compliance (никто, включая root, не может удалить или сократить срок хранения). Legal Hold (блокировка по юридическим причинам) не зависит от периодов хранения. Для полной защиты Object Lock требует включения версионирования и должен быть активирован при создании бакета.

Резервирование мощностей для региона аварийного переключения

План аварийного восстановления (DR), который предполагает, что в регионе для переключения будут доступны мощности EC2 в день крупномасштабного сбоя, — это не план. Когда отказывает один регион, все одновременно переключаются на резервный, и ресурсы инстансов — особенно больших, с GPU или специализированных — могут закончиться. On-Demand Capacity Reservations (ODCRs) в целевом регионе гарантируют наличие мощностей для конкретного типа инстанса, платформы и зоны доступности, и оплачиваются независимо от того, используются они или нет. Для компенсации затрат их можно сочетать с Savings Plan. Для долгосрочных обязательств по GPU/ML применяются Capacity Blocks; для гибкости в выборе семейств инстансов — Capacity Reservation Fleet. Принцип таков: если бизнес требует гарантированных вычислительных мощностей в DR-регионе, зарезервируйте их — не полагайтесь на доступность On-Demand по принципу «best-effort».

Выбор стратегии аварийного восстановления (DR)

AWS определяет четыре канонических уровня DR, каждый из которых имеет свой компромисс между стоимостью и скоростью восстановления:

Правильный уровень определяется бизнес-требованиями к RPO и RTO, а не архитектурными предпочтениями. RPO в 24 часа допускает ежедневное копирование снимков между регионами (Резервное копирование и восстановление). RPO в несколько секунд требует непрерывной репликации — межрегиональные реплики чтения, Aurora Global Database, DynamoDB Global Tables или S3 Cross-Region Replication. Попытка достичь RPO в 5 минут с помощью ночных снимков архитектурно невозможна, независимо от бюджета. И наоборот, использование по умолчанию актив-активной архитектуры для каждой рабочей нагрузки — это антипаттерн с точки зрения затрат: он требует глобально согласованных данных (DynamoDB Global Tables или Aurora Global с перенаправлением записи), дублирования вычислительных мощностей в полном объеме и сложного управления трафиком через Route 53 или Global Accelerator. Выбирайте самый дешевый паттерн, который соответствует заявленным RPO/RTO — для RPO в 2 часа обычно достаточно резервного копирования и восстановления или «пилотного света», а «теплый резерв» будет избыточным усложнением.

Защита от удаления и многоуровневые меры безопасности

Устойчивость — это не просто вопрос «есть ли у нас бэкапы?», а «может ли одно действующее лицо, одна ошибка или одна атака уничтожить их?». Многоуровневые средства контроля предотвращают катастрофу «одного неверного клика»:

• RDS: включите DeletionProtection и требуйте создания финального снимка при удалении.
• EC2: включите DisableApiTermination и DisableApiStop для критически важных инстансов.
• DynamoDB: включите защиту от удаления и восстановление на определенный момент времени (point-in-time recovery).
• S3: Версионирование + MFA Delete + Object Lock для неизменяемости.
• CloudFormation: DeletionPolicy: Retain для stateful-ресурсов и защита стека от удаления.
• IAM SCPs: запретите backup:DeleteRecoveryPoint, backup:DeleteBackupVault, rds:DeleteDBInstance и ec2:DeleteSnapshot для всех, кроме ролей для экстренного доступа (break-glass).

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

В сочетании с Vault Lock в режиме Compliance эти меры создают глубокоэшелонированную оборону (defense in depth): даже скомпрометированные учетные данные администратора не смогут уничтожить точки восстановления последнего рубежа обороны.

Распространенные ошибки

Считать Multi-AZ решением для DR. RDS Multi-AZ, ElastiCache Multi-AZ и FSx Multi-AZ работают в пределах одного региона. Сбой API в регионе, случайное удаление таблицы или некорректно примененная миграция схемы затронут оба узла. Любое требование, упоминающее «другой регион», «сбой региона» или «межрегиональный RPO», требует межрегиональной репликации или копирования — один лишь Multi-AZ не удовлетворяет этому требованию.

Путать реплики чтения (read replicas) с высокой доступностью (HA). Реплики чтения асинхронны, требуют ручного повышения (promote) и меняют эндпоинт. Они решают задачу масштабирования чтения, а не автоматического аварийного переключения.

Считать, что снепшоты обеспечивают соответствие требованиям (compliance). Снепшоты без Vault Lock (в режиме compliance) или Object Lock могут быть удалены любым субъектом (principal) с соответствующим разрешением IAM, а также root-аккаунтом. Нормативные требования к хранению данных по модели WORM требуют явной настройки неизменяемости (immutability) с истекшим заблокированным периодом ожидания (cooling-off period).

Использовать только локальные снепшоты для регионального RPO. Снепшоты EBS и RDS по умолчанию создаются в исходном регионе. Устойчивость на уровне региона требует явного действия по межрегиональному копированию.

Резервные копии без тестирования восстановления и зарезервированной ёмкости. Снепшот, который вы никогда не восстанавливали, — это гипотеза, а не резервная копия. Учения по восстановлению выявляют отсутствующие роли IAM, проблемы с доступом к ключам KMS в целевом регионе и аккаунте, а также недоступность нужных типов инстансов. Без резервирования ёмкости (Capacity Reservations) для критически важных рабочих нагрузок в DR-регионе может просто не оказаться нужных вам ресурсов, когда все одновременно начнут аварийное переключение, — и RTO станет неограниченным.

Избыточное проектирование по схеме active-active. Дублирование глобальных вычислительных мощностей, глобально согласованная репликация данных и сложная маршрутизация трафика — это дорого. Если показатели RPO/RTO этого не требуют, правильной архитектурой будет pilot light или warm standby.

Резервное копирование stateless-уровней. Создание снепшотов для эфемерных веб-серверов за ASG — это пустая трата денег и усложнение восстановления. Создавайте «запечённые» AMI, ссылайтесь на них в шаблонах запуска (launch templates) и концентрируйте инвестиции в резервное копирование на stateful-данных.

← Управление · Все домены

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

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