要約
- AWS European Sovereign Cloud は
aws-euscという別パーティションであり、他パーティションの認証情報はそのまま通用しない。 - AWS によれば、S3 Cross-Region Replication と Transit Gateway のリージョン間ピアリングもパーティションを越えない。したがって通常のリージョン間 DR をそのまま転用できない。
- コンプライアンス対象、サービス提供、機能の同等性、確保済み容量、復旧実績はそれぞれ別に確認しなければならない。
最初の復旧操作が境界で止まる
商用パーティション内の二つのリージョン向けに書かれた手順を aws-eusc に向ける。最初にターゲットのロールを引き受け、S3 のレプリカを確認し、Transit Gateway で復旧ネットワークを接続するはずだった。しかし AWS の説明では、認証情報はパーティションを越えず、S3 Cross-Region Replication も Transit Gateway のリージョン間ピアリングもその境界を越えない。
従って、サービスを起動する前に、別アカウントと IAM、別のデータ同期、別の通信経路が必要になる。ソース側とターゲット側に同じサービス名称があればワークロードを再現できる、という判断もここから検証し直さなければならない。実際の依存関係は、API、特定機能、インスタンス種別、クォータ、証明書、名前解決、マネージドサービス同士の連携まで広がる。
AWS は European Sovereign Cloud の幅広いサービス群を示す一方、最新の能力マトリクスを参照するよう案内している。またコンプライアンスページでは保証対象のサービスを示している。保証対象であることは、そのサービスが一定の統制枠内で評価されていることを意味し得る。しかしソース環境と機能が同一、必要量を確保済み、あるいはワークロードが復旧済みという証明にはならない。
この区別は、aws-eusc が単なる新リージョンではないため重要だ。AWS はパーティションを強い境界と説明している。他のパーティションの認証情報は移らず、S3 のリージョン間レプリケーションも Transit Gateway のリージョン間ピアリングも境界を越えない。ターゲットのアカウント、IAM、組織、ポリシー、証明書、ネットワーク、データ転送は別系統として準備する必要がある。
独立性の価値と代償
AWS によれば、ドイツのブランデンブルクにある最初の主権リージョン eusc-de-east-1 は物理的・論理的に分離され、EU 内の専用 ID、請求、トラスト、DNS コンポーネントを用い、世界の他地域との接続が失われても運用継続できるよう設計されている。これはプロバイダー側の運用独立性に関する重要な主張だ。
ただし、その独立性は顧客のワークロード可用性とは同じではない。外部接続が失われても AWS の基盤が稼働することと、顧客のオペレーターがログインでき、証明書が有効で、必要データがあり、ネットワークが利用者に届き、十分なクォータでサービスが立ち上がることは別々の条件である。
独立境界を強くするほど、暗黙の共有部品は使えなくなる。これは矛盾ではなく、主権設計の取引条件だ。買い手は分離の便益を得る代わりに、ターゲット側の制御面と運用能力を平時から維持する。
能力マトリクスをワークロード表に変換する
審査では、一般的なサービス一覧ではなく、対象ワークロード固有の対照表が必要になる。各依存関係について、ターゲットに存在するか、同じ機能があるか、割り当て量が足りるか、代替設計が必要か、変更が RTO やデータ整合性に何をもたらすかを記録する。
データ経路は特に重要だ。パーティション間で S3 のネイティブなリージョン間レプリケーションを前提にできないため、内部または外部ツールによる同期、エクスポート、バックアップ復元などを明示する必要がある。どの方式も、認証、暗号鍵、回線、転送許可、整合点、転送時間を伴う。コピーが存在しても、起動可能なサービスが存在するとは限らない。
通信も独立した審査項目になる。AWS はインターネット上の TLS、IPsec VPN、Direct Connect に関連する構成を挙げている。日常時の疎通試験だけでなく、想定する自然災害、技術障害、人為障害、地政学的または規制上の事象の最中に、その経路と運用権限が残るかを検証しなければならない。
共有責任が DR の空白を示す
AWS の Well-Architected ガイダンスでは、クラウド基盤のレジリエンスは AWS、クラウド上のワークロードのレジリエンスは顧客が担う。マルチ AZ、自動修復、バックアップとレプリケーション、ネットワーク、クォータ、監視、手順書、継続的な試験は顧客側の作業として挙げられている。
従って、主権リージョンが複数 AZ と冗長な電源・ネットワークを備えるという説明は、基盤に関する証拠である。アプリケーションがその AZ を使うよう構成されていることや、別パーティションから復旧することの証拠ではない。
AWS は RTO を中断から復旧まで許容できる最大時間、RPO を最後に復旧可能なデータ点の許容最大経過時間と定義する。いずれも組織が決める目標であり、保証範囲から自動的に導けない。目標値は、実際の障害状態から開始した試験の結果と比較されて初めて統制として機能する。
引用した AWS 資料には、特定顧客の依存サービス、ターゲットクォータ、データ量、試験時間、ロールバック結果や費用はない。名指しされた規制対象ワークロードがパーティション間フェイルオーバーを完了した証拠もない。そのため、ここで示せるのは検証条件であって、実績の代替ではない。
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

