AWS / SAP-C02

セクション 04 · タスク 1.4 · SAP-C02-033

AWS Control TowerとLanding Zone

AWS Control Tower / ランディングゾーン / コントロール / アカウントファクトリー / ガバナンス / 標準化されたアカウントプロビジョニング / AWS Service Catalog

このページのゴール

複数のAWSアカウントを個別に管理するだけでなく、ランディングゾーン・コントロール・アカウントプロビジョニングをまとめて標準化し、継続的にガバナンスするアーキテクチャを選択できることをゴールにします。

マルチアカウント要件
↓
ランディングゾーンが必要?
↓
AWS Control Tower
↓
OU / コントロール / ベースライン
↓
アカウントファクトリー
↓
標準化されたアカウントプロビジョニング
↓
継続ガバナンス

単一の権限ガードレールだけが要件ならAWS Organizationsのポリシーで成立する場合があります。AWS Control Towerは、マルチアカウント基盤全体を標準化したい要件で選びます。

1. AWS Control Towerはマルチアカウントガバナンスを標準化する

AWS Control Towerは、AWS Organizationsを基盤として複数AWSサービスを組み合わせ、マルチアカウント環境のセットアップと継続ガバナンスを標準化するマネージドサービスです。

AWS Control Tower
├─ AWS Organizations
├─ コントロールカタログ
├─ AWS Service Catalog / アカウントファクトリー
├─ AWS Config(有効化する場合)
├─ AWS CloudFormation
└─ その他の統合

AWS Organizationsを置き換えるのではありません。アカウント / OUの階層はOrganizationsを利用し、その上にAWS Control Towerがランディングゾーン、コントロール、アカウントプロビジョニングなどのガバナンスレイヤーを提供します。

2. ランディングゾーンはマルチアカウント基盤

ランディングゾーンは、アカウントを継続的に追加・管理していくためのマルチアカウント基盤です。

AWS Organizations
+
ランディングゾーン設定
+
コントロール / ベースライン
+
アカウントプロビジョニング
↓
ガバナンスされたマルチアカウント環境

単なるVPCテンプレートではなく、組織全体のAWSアカウントを配置・ガバナンスする基盤として考えます。

3. 既存AWS Organizationsにも導入できる

AWS Control Towerは新しい組織専用ではありません。既存のAWS Organizations組織へランディングゾーンを追加し、既存のOUやアカウントへガバナンスを拡張できます。

既存のAWS Organizations
↓
AWS Control Towerランディングゾーンを追加
↓
既存OU / アカウントへガバナンスを拡張

1つのAWS Organizations組織につきランディングゾーンは1つです。既存組織にAWS Control Towerを導入するときも、別のアカウント階層を作るのではなく既存Organizationsを基盤として利用します。

4. ランディングゾーン v4.0は組織構造を固定しない

現在のランディングゾーン v4.0では、従来のように特定名称・固定構造のセキュリティOUを必須とはしません。組織構造は要件に合わせて設計できます。

ルート
├─ プラットフォームOU
├─ 本番OU
├─ 非本番OU
└─ ガバナンスOU

※ 固定名称のセキュリティOUが必須ではない

ただしサービス統合を有効にする場合、各統合用に構成する中央アカウントはルート直下の同一OUにまとめる必要があります。そのOUがAWS Control Tower上の指定されたセキュリティOUとして扱われます。

5. サービス統合は選択可能だが依存関係がある

ランディングゾーン v4.0では、AWS Config、AWS CloudTrail、セキュリティロール、AWS Backupなどのサービス統合を要件に応じて選択できます。

ただし完全に独立した切り替えではなく、統合間には依存関係があります。そのため、アーキテクチャでは「すべて有効が必須」とも「好きな順序で自由に無効化できる」とも考えません。

要件
↓
必要なサービス統合を選択
↓
依存関係を確認
↓
ランディングゾーン設定

6. コントロールのみのランディングゾーンも選択できる

ランディングゾーン v4.0ではマニフェストが任意となり、AWS Organizations統合とコントロール有効化を中心にしたコントロールのみの環境を構築できます。

既存Organizations
+
AWS Control Tower コントロールカタログ
↓
コントロール中心のガバナンス

完全なサービス統合は必須ではない

既にマルチアカウント環境を持ち、まずAWS Control Towerのマネージドコントロールだけを採用したい要件では重要な選択肢です。

7. コントロールは継続ガバナンスのルール

AWS Control Towerのコントロールは、マルチアカウント環境で継続的に守らせたい高レベルなガバナンスルールです。コントロールには動作として次の3種類があります。

動作判断代表的な実装
予防的違反アクションや設定を発生させないSCP / RCP / 宣言型ポリシー
検出的既存リソースの非準拠を検出するAWS Configルール
プロアクティブCloudFormationプロビジョニング前に違反リソースを拒否するAWS CloudFormation Hook

8. 動作は「いつ止めたいか」で選ぶ

違反アクションそのものを実行させない
→ 予防的

既存リソースの違反状態を継続検出
→ 検出的

CloudFormationで作る前に違反を拒否
→ プロアクティブ

予防的コントロールの中でも実装方式は1種類ではありません。SCPだけでなくRCPや宣言型ポリシーを使うコントロールもあるため、予防的 = SCP固定とは覚えません。

9. 検出的コントロールにはAWS Configが必要

検出的コントロールはAWS Configルールで実装されます。ランディングゾーン v4.0ではAWS Config統合を無効にした構成も可能ですが、その場合検出的コントロールは利用できません。

コントロールAWS Config統合なし
予防的利用可能
プロアクティブ利用可能
検出的利用不可

「コントロールのみ = すべての動作を統合なしで使える」ではありません。

10. ガイダンスは動作とは別軸

コントロールには動作とは別に、適用推奨度を表すガイダンスがあります。

動作
予防的 / 検出的 / プロアクティブ

ガイダンス
必須 / 強く推奨 / 選択

強く推奨と選択は要件に応じて有効化する任意コントロールです。必須コントロールはAWS Control Towerがデプロイしたリソースを保護するためのコントロールで、環境で有効にしたサービス統合や管理対象リソースに応じて適用されます。ランディングゾーン v4.0以降は必須コントロールが全OUへデフォルト適用されるとは限りません。したがって「必須だから全環境・全OUで常に同じコントロール集合になる」と一般化しません。

11. v4.0ではコントロールを直接OUへ有効化できる

ランディングゾーン v4.0では、既存OUへコントロールを直接有効化できます。コントロールを1つ利用するためだけに、必ず包括的なAWSControlTowerBaselineをOUへ適用する必要はありません。

既存OU
↓
適用可能コントロールを直接有効化
↓
ガバナンス範囲へ組み込む

現在 v4.0では、OUやアカウントにコントロール / ベースラインなどのAWS Control Towerリソースが有効になっていれば、そのリソースはガバナンス対象として扱われます。従来のように「AWSControlTowerBaselineがある= ガバナンス対象」の1条件だけでは判断しません。

12. ベースラインは目的別に使い分ける

ベースラインは、OUへ特定のガバナンス基盤を展開する仕組みです。ランディングゾーン v4.0では、必要な機能に応じてベースラインを選びます。

コントロールだけ必要
→ コントロールを直接有効化できる場合がある

検出的コントロールが必要
→ AWS Config統合 + ConfigBaseline

アカウントファクトリーで単一アカウントをプロビジョニング / 更新 / カスタマイズ
→ 対象OUにAWSControlTowerBaselineが必要

AWSControlTowerBaselineをすべてのコントロール利用の必須条件にしないことが現在設計の重要なポイントです。

13. アカウントファクトリーは標準化されたアカウントプロビジョニング

アカウントファクトリーは、AWSアカウントを同じプロセスとガバナンス条件で繰り返し払い出すための機能です。

アカウントリクエスト
↓
アカウントファクトリー
↓
アカウント作成
↓
対象OUへ配置
↓
標準化されたガバナンスで利用開始

目的は単にアカウントを作ることではなく、アカウントプロビジョニングプロセスを標準化し、作成者ごとの設定差・OU配置ミス・ガバナンス漏れを減らすことです。

14. アカウントファクトリーとAWS Service Catalog

AWS Control Tower アカウントファクトリーはAWS Service Catalogと連携し、アカウントファクトリー製品やAPIを通じて標準化されたアカウントをプロビジョニングできます。

承認済みアカウント設定
↓
AWS Service Catalog / アカウントファクトリー
↓
標準化されたAWSアカウント

現在のランディングゾーン v4.0でアカウントファクトリー / AWS Service Catalog 統合を使用する場合はAWS Config統合が必要です。また、単一アカウントのプロビジョニング / 更新 / カスタマイズの対象OUではAWSControlTowerBaselineが有効である必要があります。

15. 既存アカウントは作り直さず登録できる

AWS Control Towerは新規アカウントだけを対象にするサービスではありません。既存アカウントをサポート対象登録ワークフローでガバナンス範囲へ取り込めます。

既存のAWSアカウント
↓
必要な登録前提を満たす
↓
管理対象OUへ登録
↓
AWS Control Towerガバナンス

要件が「既存アカウントを残したままAWS Control Towerへ移行」であれば、アカウントファクトリーで同じアカウントを作り直すのではなく登録を検討します。

16. ドリフトは期待設定との差

AWS Control Towerが管理するリソースや設定を外部から変更し、期待状態と実際の状態がずれた場合はドリフトとして扱います。

期待される設定
        ≠
実際の設定
        ↓
       ドリフト

ドリフト検知と修復は別です。ドリフトを検出したからといって、すべてが自動的に元へ戻るわけではありません。ドリフトの種類に応じてサポート対象修復を選択します。

17. AWS Control TowerとOrganizationsポリシーを使い分ける

AWS Control Towerは基盤となる サービスを置き換えるものではありません。要件の範囲で選びます。

要件アーキテクチャ候補
組織全体で特定APIを禁止したいAWS Organizations + SCP等
OU / アカウント階層を作りたいAWS Organizations
ランディングゾーン、コントロール、アカウントプロビジョニング、継続ガバナンスを標準化したいAWS Control Tower

単一のガードレール要件しかないのに、必ずAWS Control Towerを追加する必要はありません。

18. 障害モード

AWS Control TowerがOrganizationsを置き換えると思う

AWS Control TowerはOrganizationsを基盤としてガバナンスレイヤーを提供します。

現在AWS Control Towerでも固定セキュリティOUが必須だと思う

ランディングゾーン v4.0では固定組織構造は不要です。ただし有効化したサービス統合用アカウントの親OU条件は残ります。

コントロールは全部SCPだと思う

予防的にはSCP / RCP / 宣言型ポリシー、検出的にはAWS Configルール、プロアクティブにはCloudFormation Hookがあります。

コントロールのみなら検出的もConfigなしで使えると思う

検出的コントロールにはAWS Config統合が必要です。

コントロール利用には必ずAWSControlTowerBaselineが必要だと思う

v4.0ではOUへコントロールを直接有効化できます。包括ベースラインはコントロール利用そのものの必須条件ではありません。

アカウントファクトリーの対象OUにもベースラインは不要だと思う

単一アカウントのプロビジョニング / 更新 / カスタマイズでは対象OUにAWSControlTowerBaselineが必要です。

ドリフトはすべて自動修復されると思う

検知と修復は別であり、ドリフトの種類に応じて対応します。

19. SAP-C02判断フロー

マルチアカウント要件
        │
        ▼
アカウント / OU階層だけ?
        │
      はい → AWS Organizations
        │ いいえ
        ▼
特定権限ガードレールだけ?
        │
      はい → Organizationsポリシー / SCP等
        │ いいえ
        ▼
ランディングゾーン + コントロール +
アカウントプロビジョニング + ガバナンス?
        │
      はい → AWS Control Tower
        │
        ▼
コントロール要件は?
防止 / 検知 / CFN プロビジョニング前
        │
        ▼
予防的 / 検出的 / プロアクティブ
        │
        ▼
新規アカウントを標準化して払い出す?
        │
      はい → アカウントファクトリー
        │
        ▼
既存アカウント?
      はい → 登録

20. まとめ

AWS Control Towerは、AWS Organizationsを基盤にランディングゾーン・コントロール・アカウントプロビジョニングを一貫して標準化するガバナンスレイヤーです。

Organizations
+
AWS Control Towerランディングゾーン
+
コントロール / ベースライン
+
アカウントファクトリー
↓
標準化されたマルチアカウントガバナンス

現在のランディングゾーン v4.0では固定セキュリティOUやすべてのサービス統合を必須とせず、コントロールのみ構成も可能です。コントロールは予防的 / 検出的 / プロアクティブから要件に合わせて選び、アカウントファクトリーではAWS Service Catalogと連携して標準化されたアカウントプロビジョニングを実現します。

コントロールだけを使う条件と、アカウントファクトリーを使うためのAWSControlTowerBaseline条件を混同しないことが重要です。

21. 主要AWS公式資料

  • AWS Control Tower — 概要
  • AWS Control Tower — ランディングゾーン v4.0 移行ガイド / 主な変更点
  • AWS Control Tower — コントロールの動作とガイダンス
  • AWS Control Tower — アカウントファクトリー
  • AWS Control Tower — AWS Service Catalogとの統合
  • AWS Control Tower — ドリフトとガバナンス

理解確認

このページの内容を14問で確認します。

理解確認14問へ →