欧州向けのシステムを設計するとき、データの置き場所だけでなく、誰がログインし、どこへ監査ログを集め、どの経路でアプリを配布するかまで決める必要があります。既存のAWS基盤を、そのまま欧州向けに広げられるのでしょうか。

2026年9月16日に公開されたAWSのランディングゾーン設計記事は、AWS European Sovereign Cloud（以降、EUSC）を独立したパーティションとして捉えています。ここを押さえると、既存環境との接続方法が見えてきます。

ランディングゾーンとは、複数アカウントの管理、認証、監査などをそろえた共通の基盤です。EUSCへ持ち込める設計と、EUSC内に作り直す管理機能を、ログインからデプロイまで順に考えてみましょう。

IAMの境界が、既存ランディングゾーンの拡張を制限する

通常の商用AWSは aws、EUSCは aws-eusc という別のパーティションに属します。EUSCの最初のリージョンは、ドイツのブランデンブルクにある eusc-de-east-1 です。

パーティションごとにIAMは独立しており、一方のIAM認証情報をもう一方のリソース操作には使えません。S3のリージョン間レプリケーションなども、同じパーティションの中で使う機能です。この仕組みはAWSのパーティション解説で確認できます。

そのため、商用AWSの管理用ロールからEUSCのロールへ AssumeRole する設計は成立しません。既存の管理アカウントから操作する前提があるなら、EUSC側の認証経路を別に用意するところから設計が始まります。

一方、EUSC内のアカウント間ロールは利用できます。集約管理を諦める必要はなく、集約する範囲をパーティションの内側にそろえるわけですね。

アカウントの役割を再現し、SSOの権限割り当てを分ける

EUSC側には独立したAWS Organizationsの組織を用意します。管理アカウントへすべての仕事を集めるより、AWS Security Reference Architectureのアカウント構成を使い、役割を分けると設計を整理できます。

この役割分担は既存環境とそろえられます。ただし、組織や所属アカウントを共有するわけではありません。

利用者のログインも同様です。同じ企業IdPを、商用AWSとEUSCそれぞれのIAM Identity Centerへ接続する構成は可能ですが、アクセス許可セットやアカウントへの割り当ては個別に管理します。EUSCのインスタンスARNやアクセスポータルも専用の形式を持ちます。EUSC向けIdentity Centerガイドには、ポータル利用時に許可するドメインも掲載されています。

同じ従業員が同じIdPで認証されても、両環境で同じ操作権限を持つとは限りません。異動や退職に伴う権限の変更を試す際には、両方の割り当てが意図どおりになっているかを検証したいところです。

IaCはARNを可変にし、サービスの提供差分は別に扱う

アカウント構成をコードで再現するには、まずARNに埋め込まれた arn:aws: を見直します。CloudFormationなら、疑似パラメータ AWS::Partitionでデプロイ先のパーティションを参照できます。

例えば、S3バケットARNを組み立てる式は次のように書けます。これは式の例であり、バケットや権限を作成する完全なテンプレートではありません。

# AuditBucketNameには対象バケット名を渡します。
!Sub "arn:$AWS::Partition:s3:::${AuditBucketName}"

aws-eusc で展開すれば、先頭は arn:aws-eusc:s3::: になります。ただし、ARNを正しく生成できても、利用するサービスや自動化機能まで同じとは限りません。EUSCのIAMにはSTSのグローバルエンドポイントがなく、リージョン別エンドポイントを使う仕様です。認証処理が参照する接続先も併せて見直します。

Control Towerについても、提供開始と機能の一致は分けて考えます。リリースノートには2026年1月13日のEUSC対応が記載されていますが、2026年9月17日に確認したEUSC専用ガイドは、Account Factory for Terraform（AFT）とランディングゾーンのIdentity Center統合を未提供としています。

ここは、AFTの利用を勧める2026年9月16日のブログ記事と記述が一致しません。どちらが実環境の最新状態を反映するかは確認できていないため、AFTを利用可能な前提で構築手順に組み込むのは避け、対象環境で提供状況を確かめる必要があります。Identity Center自体の提供と、Control Towerからの統合も別の話です。

監査ログはEUSC内へ集約し、検索経路まで設計する

認証と管理の境界をそろえたら、操作の記録も同じ範囲で追えるようにします。AWSの設計記事は、EUSC内のLog Archiveアカウントへログを集め、Security Toolingアカウントで検知を管理する構成を勧めています。EU内で処理を完結させる要件なら、SIEMによる取り込みと分析もその境界内に収めます。

監査では、ログを保存できることに加え、必要な操作を後から探せることが必要です。CloudTrailはAPI呼び出しの履歴を記録できますが、2026年9月17日時点のEUSC向けCloudTrailガイドではCloudTrail Lakeは未提供です。既存の調査手順がLakeに依存するなら、保管先の移設と一緒に検索・分析の経路も設計し直します。

例えば検証環境で権限変更を行い、対象の記録をLog Archive側で見つけ、分析担当者が参照できるところまで試すと、収集・保管・閲覧権限を一続きで評価できます。これは導入時の検証案であり、実施済みの結果ではありません。

CI/CDはEUSCへの搬入と、内部への配布を分ける

同じ境界は、アプリケーションの配布にも現れます。商用AWSからEUSCへコンテナイメージを届ける際は、パーティションをまたぐECRレプリケーションに頼らず、EUSCの認証情報でEUSC側のレジストリへ明示的にプッシュする構成になります。

これを「EUSCへ成果物を搬入する処理」と「EUSC内の各アカウントへ配布する処理」に分けると、必要な権限を整理しやすくなります。搬入後のデプロイは、EUSC内のShared ServicesからWorkloadへロールを引き受ける設計にできます。外側から接続する処理では、ネットワークの到達性とEUSC側の認証を別々に検証します。

検査工程にも提供差分があります。EUSC向けECRガイドでは、2026年9月17日時点で拡張スキャンは未提供です。既存パイプラインがその結果を配布条件にしているなら、同じ検査がEUSCでも動く前提にせず、搬入・配布のどの段階で検査するかを決めます。

既存のAWS基盤から引き継げるのは、アカウントの責務、権限設計、コード化したルールです。その設計をEUSC内へ展開し、ログイン、監査、デプロイが一巡する小さな経路を先に検証すると、再利用できる部分と追加実装が必要な部分を具体的に判断できます。

欧州向けの基盤を広げる際の出発点は、この運用経路をEUSC側で成立させることです。共通の設計を保ちながら、管理と認証の実体を独立させる。それがパーティション境界に沿ったランディングゾーンの作り方です。

出典

• Title: Architecting a secure landing zone in the AWS European Sovereign Cloud
• URL: https://aws.amazon.com/blogs/security/architecting-a-secure-landing-zone-in-the-aws-european-sovereign-cloud/