運用管理

AWS Control Tower でマルチアカウント環境を構築 - ランディングゾーンとガードレール

ベストプラクティスに基づくマルチアカウント環境を自動構築し、400 以上のガードレールでコンプライアンスを継続的に維持する。Account Factory と Customizations for Control Tower による拡張手法を解説します。

約 1 分で読めます

Control Tower の概要

Control Tower はマルチアカウント環境のセットアップとガバナンスを自動化するサービスです。Organizations でアカウントを管理し、ガードレールでセキュリティポリシーを強制し、Account Factory でアカウントのプロビジョニングを標準化します。ランディングゾーンの構築で、ログアーカイブアカウントと監査アカウントを含むベストプラクティスのマルチアカウント構成を自動的にセットアップします。

ガードレールと Account Factory

予防的ガードレールは SCP (Service Control Policy) で禁止アクションを強制します。例えば「CloudTrail の無効化を禁止」「S3 バケットのパブリックアクセスを禁止」などです。検出的ガードレールは Config ルールで非準拠リソースを検出し、ダッシュボードに表示します。Account Factory は Service Catalog ベースのアカウント作成ワークフローで、VPC 設定、IAM ロール、ガードレールが自動適用されたアカウントを数分でプロビジョニングします。カスタマイズ (CfCT) でアカウント作成時に追加の CloudFormation テンプレートを適用し、セキュリティツールのインストールやログ設定を自動化します。

カスタマイゼーションと AFT

Account Factory Customization (AFC) でアカウント作成時にカスタムテンプレート (CloudFormation 、 Terraform) を自動適用し、セキュリティベースライン、ネットワーク設定、 IAM ロールを標準化します。 Account Factory for Terraform (AFT) は Terraform ベースのアカウントプロビジョニングパイプラインで、 GitOps ワークフローでアカウント設定を管理します。 Control Tower のランディングゾーンは定期的にバージョンアップされ、新しいガードレールやリージョン対応が追加されます。カスタムガードレールは SCP または CloudFormation Guard ルールで定義し、組織固有のポリシーを強制します。 マルチアカウントの管理手法を網羅的に学ぶなら、技術書 (Amazon)を参照してください。

Control Tower の料金

Control Tower 自体に追加料金は発生しません。コストは基盤となるサービス (Organizations、CloudTrail、Config、S3) の利用料金に依存します。ガードレールの Config ルール評価は Config の料金として課金されます。マネージドアカウントごとに CloudTrail の証跡と Config の記録が有効化されるため、アカウント数が増えるとこれらのコストが積み上がります。不要なガードレールを無効化し、Config の記録対象リソースタイプを必要最小限に絞ることでコストを管理します。

まとめ

Control Tower はランディングゾーンとガードレールでマルチアカウント環境のガバナンスを自動化するサービスです。Account Factory でアカウントのプロビジョニングを標準化し、AFT で Terraform ベースの GitOps ワークフローを実現します。予防的ガードレール (SCP) と検出的ガードレール (Config ルール) で組織全体のセキュリティポリシーを強制します。

関連するサービス

AWS Control Towerマルチアカウント環境のセットアップとガバナンスを自動化するサービスAWS Organizations複数の AWS アカウントを一元管理するサービスAWS IAM Identity Center複数の AWS アカウントと SaaS アプリケーションへのシングルサインオンを提供するサービス

関連する記事

AWS Organizations で実現するマルチアカウント管理 - OU 設計と SCP によるガバナンスOU 階層の設計と SCP によるアクセス制御でマルチアカウント環境のガバナンスを確立する。一括請求によるコスト管理も紹介します。AWS Security Hub で一元管理するセキュリティ態勢 - 検出結果の集約と自動対応GuardDuty・Inspector・Macie の検出結果を ASFF で集約し、セキュリティ標準の自動評価でスコアを定量化する。EventBridge 連携の自動修復も紹介します。AWS Control Tower で構築するマルチアカウント環境 - ランディングゾーンとガードレールランディングゾーンの自動構築とガードレールによるポリシー適用で、マルチアカウント環境のガバナンスを確立する。Account Factory によるアカウント自動作成も紹介します。

同じテーマの記事

AWS の内部時刻同期の仕組み - Amazon Time Sync Service とうるう秒スミアリングの設計AWS が独自に運用する Amazon Time Sync Service の仕組み、GPS と原子時計による高精度時刻源、うるう秒をスミアリングで吸収する設計判断、分散システムにおける時刻同期の重要性を解説します。AWS AppFabric で SaaS 監査ログを集約 - OCSF 標準化と Security Lake 統合AppFabric による SaaS アプリケーションの監査ログ収集、OCSF 形式への標準化、分析パイプラインの構築を解説します。AWS AppConfig で実装するフィーチャーフラグ - 安全な設定デプロイとロールバックコードデプロイとは独立した設定変更を、Linear・Exponential 戦略で段階的にロールアウトする。CloudWatch アラーム連動の自動ロールバックで安全性を確保します。アーキテクチャレビュー - AWS Well-Architected Tool でワークロードを体系的に評価するAWS Well-Architected Tool を使ったワークロードのアーキテクチャレビューを解説。6 つの柱に基づく評価、改善計画の策定、カスタムレンズの活用を紹介します。監査ログの設計と運用 - CloudTrail による API アクティビティの完全記録AWS CloudTrail を活用した監査ログの設計手法を解説し、API アクティビティの記録、S3 への長期保存、Config との連携によるコンプライアンス対応を紹介します。AWS の障害報告書 (COE) から学ぶ分散システムの教訓 - 過去の大規模障害が変えた設計原則AWS が公開した Correction of Errors (COE) と障害報告書から、S3 障害、us-east-1 の DNS 障害、Kinesis 障害など過去の大規模インシデントの根本原因と、それが AWS の設計原則をどう変えたかを解説します。タグの設計が運用を決める - AWS リソースタグ戦略の雑学と実践的な命名規則AWS リソースタグが単なるラベルではなくコスト配分、アクセス制御、自動化の基盤である理由、タグキーの命名規則、タグの上限 50 個の使い方、タグポリシーによるガバナンスを解説します。AWS のサービスクォータはなぜ存在するのか - 共有インフラを守るマルチテナント設計AWS のサービスクォータ (旧サービス制限) が単なる制約ではなく、マルチテナント環境で他の顧客を守るための設計であることを、ノイジーネイバー問題、ソフトリミットとハードリミットの違い、引き上げ申請の裏側から解説します。

内容が近い記事・サービス

AWS Control Tower で構築するマルチアカウント環境 - ランディングゾーンとガードレールランディングゾーンの自動構築とガードレールによるポリシー適用で、マルチアカウント環境のガバナンスを確立する。Account Factory によるアカウント自動作成も紹介します。AWS Control Towerマルチアカウント AWS 環境のセットアップとガバナンスを自動化し、セキュリティとコンプライアンスのベースラインを一元管理するサービスAWS マルチアカウント統制の設計力 - Organizations・Control Tower・SCP による組織ガバナンスAWS Organizations、Control Tower、SCP (Service Control Policies) を中心とするマルチアカウント統制の仕組みを、Azure Management Groups と比較し、エンタープライズガバナンスの設計力の差を解説します。マルチアカウント管理 - AWS Organizations と RAM で実現する組織全体のガバナンスOrganizations の委任管理者モデルで CloudTrail・Config・GuardDuty・Security Hub を全アカウントに一括展開し、セキュリティとコンプライアンスの統合管理を実現する方法を解説します。