Кратко

  • AWS European Sovereign Cloud работает в отдельном разделе aws-eusc; учётные данные из другого раздела туда не переносятся.
  • По данным AWS, S3 Cross-Region Replication и межрегиональный пиринг Transit Gateway не работают между разделами. Значит, наличие копии требует отдельного объяснения происхождения и актуальности.
  • Даже корректная копия не является восстановленным сервисом без идентификации, сертификатов, сети, совместимых функций, ёмкости, законного разрешения и измеренного запуска.

Первая операция останавливается на границе

Оператор направляет на aws-eusc инструкцию, написанную для двух коммерческих регионов: принять роль в цели, проверить реплику S3 и присоединить сеть восстановления через Transit Gateway. До запуска приложения последовательность распадается. Учётные данные не переходят в другой раздел; S3 Cross-Region Replication и межрегиональный пиринг Transit Gateway также не пересекают эту границу, указывает AWS.

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

Фраза «данные находятся в суверенном облаке» звучит как ответ на вопрос о непрерывности. На деле она отвечает лишь на вопрос о местонахождении некоторого набора данных. Для восстановления нужно установить, является ли этот набор полным, согласованным, достаточно свежим и пригодным для запуска приложения.

AWS указывает, что aws-eusc — самостоятельный раздел, а eusc-de-east-1 — его первый регион в Бранденбурге. Учётные записи привязаны к разделу, поэтому в суверенной среде требуются новые учётные записи, идентификаторы и роли IAM.

Следовательно, копия могла появиться благодаря отдельному экспорту, внешнему инструменту, резервному архиву или пользовательскому каналу синхронизации. Каждый способ имеет собственные учётные данные, ключи, сеть, разрешение на передачу, задержку и модель согласованности. Без этих сведений нельзя оценить ни RPO, ни возможность повторить перенос во время кризиса.

Между хранилищем и сервисом семь разрывов

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

Третий разрыв — идентификация. Источниковые учётные данные не действуют в aws-eusc; целевой аккаунт, организация, роли и операторы должны существовать заранее. Четвёртый — доверие: сервисным идентификаторам нужны секреты и сертификаты, а органу сертификации — независимая возможность выпуска и отзыва.

Пятый разрыв — сеть. AWS рассматривает TLS через интернет, IPsec VPN и схемы, связанные с Direct Connect, но адресация, маршруты, фильтрация, DNS и ключи должны пережить именно тот сбой, ради которого выбран суверенный раздел. Обычная проверка связи не моделирует изоляцию.

Шестой разрыв — функции и ёмкость. AWS публикует широкий перечень сервисов и матрицу возможностей. Совпадение названия не гарантирует одинаковый API, функцию, тип ресурса, квоту или зависимость. Нахождение сервиса в области assurance также не резервирует мощность.

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

Почему устойчивость платформы не закрывает разрывы

AWS заявляет, что суверенный регион физически и логически отделён, находится в ЕС, использует отдельные компоненты идентификации, биллинга, доверия и DNS и рассчитан на работу при потере связи с остальным миром. Он включает несколько зон доступности и избыточные питание и сеть. Это значимые свойства инфраструктуры провайдера.

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

AWS различает доступность и disaster recovery. Она определяет RTO как максимально допустимое время от остановки до восстановления, а RPO — как максимально допустимый возраст последней восстанавливаемой точки. Эти значения задаёт организация. Резервная копия сама по себе показывает лишь потенциальную точку данных; она ничего не говорит о времени полного возврата сервиса.

Разные модели готовности меняют этот разрыв. Backup-and-restore оставляет большую часть работы после сбоя. Pilot light сохраняет минимум. Warm standby поддерживает уменьшенную работающую систему. Active-active оплачивает две активные стороны. Обещать короткий RTO при финансировании только холодной копии — значит перенести бюджетный разрыв в будущую аварию.

Соответствие требованиям не загружает приложение

AWS описывает в суверенной модели независимость управления, операционный контроль, резидентность данных и техническую изоляцию. Этот материал может доказать допустимость цели. Он не доказывает паритет функций, наличие квот, актуальность данных или успешное испытание.

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

В процитированных материалах нет инвентаря конкретного покупателя, объёма его данных, квот, RTO, RPO, времени упражнения, результата отката или стоимости. Нет и доказательства завершённого межраздельного переключения названной регулируемой системы. Поэтому нельзя превращать архитектурное руководство в сообщение о состоявшемся восстановлении.