В современных условиях цифровой трансформации и непрерывного роста объемов данных защита информации становится одной из ключевых задач для бизнеса. Компаниям важно не только создавать резервные копии, но и обеспечить их хранение в изолированных средах — в разных аккаунтах AWS и регионах, чтобы минимизировать риски потери данных из-за сбоев, инцидентов безопасности или природных катастроф. Однако решение такой задачи на практике сопряжено с определёнными сложностями, связанными с ограничениями функционала сервиса AWS Backup. Несмотря на то, что AWS Backup поддерживает как кросс-аккаунтные, так и кросс-региональные копии, оно не предусматривает их одновременного использования для определённых ресурсов, таких как RDS, Aurora, DocumentDB и Neptune. Именно об этом и поговорим в нашем подробном материале.
Начнём с того, что идея организации кросс-аккаунтного и кросс-регионального резервного копирования обусловлена желанием создать максимально надежный и отказоустойчивый план восстановления данных. Хранение резервных копий в одном аккаунте, пусть даже в разных регионах, не обеспечивает необходимого уровня защиты в случае компрометации аккаунта или прекращения его работы. Аналогично, хранение копий в одном регионе, но в нескольких аккаунтах, не гарантирует целостность данных при региональных сбоях или катастрофах. Поэтому для многих компаний идеальным решением становится хранение бэкапов в разных аккаунтах и регионах одновременно. К сожалению, стандартные возможности AWS Backup не позволяют настроить единый процесс, который бы одновременно создавал резервные копии с копированием в другой аккаунт и регион.
В официальной документации AWS приводится примечание, что для определённых сервисов (например, RDS и Aurora) нельзя выполнить прямое копирование данных по двум направлениям — одновременно в другой регион и другой аккаунт. Это ограничение создаёт сложности для архитекторов и администраторов, заставляя искать обходные пути для реализации необходимой защиты. Одним из наиболее эффективных решений данной задачи является поэтапный подход к созданию резервных копий. Сначала с помощью возможностей AWS Backup настраивается копирование бэкапов в другой аккаунт в том же регионе. Вторая копия создаётся с использованием дополнительной автоматизации, например, с помощью AWS Lambda и EventBridge.
Такой сценарий позволяет при завершении первого копирования в целевом аккаунте запускать функцию, которая инициирует копирование в другой регион. Важным аспектом при настройке кросс-аккаунтного шифрования является использование шифрования с помощью собственных ключей клиентской стороны (Customer Managed Keys, CMK) в AWS KMS. AWS Backup не поддерживает межаккаунтное копирование резервных копий, зашифрованных стандартными ключами AWS Managed Keys, поэтому обязательным требованием служит настройка ключей CMK и выдача прав доступа для их использования ролям AWS Backup в обоих аккаунтах. Особенно тщательно следует организовывать права на ключи для баз данных RDS, так как они шифруются отдельным ключом, отличным от ключа хранилища (vault key). Для достижения поставленных целей также важно правильно настроить политики доступа к Vault в AWS Backup.
В целевом аккаунте необходимо создать Vault с политиками, разрешающими копирование бэкапов из аккаунтов группы организации (Organization Units). Не менее значима установка Vault Lock, которая обеспечивает неизменяемость хранилища и защищает резервные копии от удаления или изменения без особых прав. В зависимости от требований безопасности можно выбрать доверительный режим Governance или более строгий Compliance. Организация маршрутизации событий копирования бэкапов представляет ещё один ключевой элемент архитектуры. AWS Backup генерирует события о состоянии копий только в исходном аккаунте, где запущено копирование, а не в аккаунте-получателе.
Для реализации автоматического кросс-регионального копирования необходимо направлять эти события через EventBridge из исходного аккаунта в целевой. При этом создаётся отдельная шина событий (EventBus) в целевом аккаунте с соответствующими политиками, разрешающими приём событий из исходного аккаунта. Вся связка дополнена правилами EventBridge, которые фильтруют наиболее важные события, и на основе которых вызываются необходимые функции AWS Lambda. AWS Lambda в представленном сценарии играет роль своеобразного мостика и триггера. Функция, написанная, например, на JavaScript с использованием AWS SDK, прослушивает специальные события об успешном завершении копирования резервных копий в целевой регион и инициирует последующий старт копирования во второй регион.
Этот подход компенсирует отсутствие нативной поддержки AWS Backup для одновременного кросс-аккаунтного и кросс-регионального копирования. При настройке Lambda важно удостовериться, что её роль обладает достаточными правами на выполнение команд копирования, включая возможность использования роли копирования (Copy Role), которая определена отдельно и также имеет необходимые IAM разрешения. Такая роль нужна для того, чтобы AWS Backup мог корректно запустить операции между Vault-ами и шифровать или расшифровывать данные на соответствующих этапах. Весь процесс накладывает серьёзные требования на качественную отработку сценариев тестирования. Начать стоит с ручного запуска копирования существующих recovery points, чтобы убедиться в правильной настройке KMS-политик, ролей и разрешений.
Отсутствие необходимых прав или несоответствие политик часто приводит к ошибкам, которые сложно сразу обнаружить без детального логирования. Рекомендуется настроить логи EventBridge и CloudWatch для контроля потоков событий и быстрого выявления неполадок. Ещё одна критическая деталь связана с дополнительными ролями сервисов, такими как AWS Backup Link Service Role и ролями сервисов для конкретных ресурсов, например, RDS. В отдельных случаях отсутствие этих ролей в целевом аккаунте вызывает сбои копирования. Активное использование документации AWS и своевременное добавление нужных ролевых зависимостей позволяют избежать подобных проблем.
Несмотря на техническую сложность и многоступенчатость настройки, итоговая архитектура даёт организациям ценное преимущество — гарантированное хранение резервных копий на удалённых площадках с различными зонами ответственности, что снижает риски утраты данных значительно выше, чем базовая модель с однократным резервным копированием. Это особенно важно для организаций с высокими требованиями к безопасности, соответствию нормативам и высоким уровням обслуживания. Помимо базовой реализации, специалисты также рекомендуют дополнять процесс мониторингом стоимости, так как мультирегиональное и мультиаккаунтное копирование приводит к удорожанию инфраструктуры. Автоматизация алертов на ошибки копирования и интеграция с системами управления инцидентами помогают оперативно реагировать на проблемы и минимизировать потенциальные риски. Также перспективным направлением является автоматизация тестирования восстановления данных (DR-упражнения) непосредственно из целевого аккаунта, что позволяет регулярно проверять целостность и доступность бэкапов без вмешательства в продакшен-среду.
