運用管理

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

ランディングゾーンの自動構築とガードレールによるポリシー適用で、マルチアカウント環境のガバナンスを確立する。Account Factory によるアカウント自動作成も紹介します。

約 4 分で読めます

Control Tower の役割

Control Tower は AWS のマルチアカウント環境を自動構築・管理するサービスです。Organizations でアカウントを作成し、SCP でポリシーを適用し、Config でコンプライアンスを監視し、CloudTrail でログを集約する一連の設定を、ランディングゾーンとして自動的にセットアップします。手動で構築すると数日かかるマルチアカウントのベストプラクティス構成が、Control Tower では数時間で完了します。ランディングゾーンは管理アカウント、ログアーカイブアカウント、監査アカウントの 3 アカウント構成を基本とし、Security OU と Sandbox OU を自動作成します。ログアーカイブアカウントには全アカウントの CloudTrail ログと Config ログが S3 バケットに集約され、監査アカウントには Config Aggregator と SNS 通知が構成されます。

ガードレールの設計

ガードレールは必須、強く推奨、選択的の 3 段階で 400 以上が提供されます。予防的ガードレールは SCP で実装され、禁止されたアクションを事前にブロックします。例えば「ログアーカイブアカウントの CloudTrail 設定の変更を禁止」「リージョン制限 (許可されたリージョン以外での操作を禁止)」などです。検出的ガードレールは Config ルールで実装され、非準拠の設定を検出して通知します。例えば「EBS ボリュームが暗号化されていない」「S3 バケットがパブリックアクセス可能」などです。プロアクティブガードレールは CloudFormation フックで実装され、非準拠のリソースの作成を事前にブロックします。組織固有のポリシーが必要な場合は、カスタムガードレールを SCP または CloudFormation Guard ルールで定義し、マネージドガードレールと同様に OU 単位で適用できます。ガードレールの適用は OU 単位で行い、本番 OU には厳格な予防的ガードレールを、開発 OU には検出的ガードレールのみを適用するなど、環境に応じた段階的な制御が推奨されます。

Account Factory とカスタマイズ

Account Factory は Service Catalog と統合されたアカウント作成機能です。開発者がセルフサービスでアカウントを申請すると、標準化された設定 (VPC、サブネット、セキュリティグループ、IAM ロール) が自動適用されたアカウントが数分で作成されます。Customizations for Control Tower (CfCT) を使用すると、アカウント作成時にカスタムの CloudFormation テンプレートを自動適用できます。セキュリティツールのインストール、監視エージェントの設定、標準的な IAM ロールの作成などを自動化し、全アカウントで一貫した構成を保証します。Account Factory Customization (AFC) では CloudFormation と Terraform の両方のカスタムテンプレートに対応しており、セキュリティベースラインやネットワーク設定を標準化できます。Account Factory for Terraform (AFT) を利用すると、Terraform のワークフローでアカウント作成からカスタマイズまでを IaC で管理でき、GitOps パターンによるアカウントプロビジョニングが実現します。 Control Tower の運用ノウハウを深めるには、専門書籍 (Amazon)が役立ちます。

設計のベストプラクティスと落とし穴

Control Tower の OU 設計では、ワークロードの種類 (本番、ステージング、開発) とセキュリティ境界 (ネットワーク、共有サービス、セキュリティ) を軸にした階層化が推奨されます。典型的な構成は Security OU (ログアーカイブ・監査)、Infrastructure OU (ネットワーク・共有サービス)、Workloads OU (本番・非本番) の 3 層です。よくある落とし穴として、ランディングゾーンのホームリージョン変更が不可能な点があります。初期セットアップ時のリージョン選択は慎重に行う必要があります。また、ガードレールのドリフト検出で「非準拠」になった場合、Control Tower ダッシュボードからの修復操作が必要になり、手動で SCP を直接編集すると状態の不整合が発生します。Control Tower が管理する OU 配下のアカウントで Organizations の SCP を直接変更することは避け、必ず Control Tower コンソールまたは API 経由で管理してください。

Control Tower の料金

Control Tower 自体に追加料金は発生しません。コストは Control Tower が内部で使用する AWS サービス (Organizations、Config、CloudTrail、S3、SNS) の利用料金です。検出的ガードレールは Config ルールとして実装されるため、Config の評価料金 (1 評価あたり約 0.003 ドル) が発生します。ガードレールの数とアカウント数に応じて Config のコストが増加するため、必要なガードレールを選択的に有効化し、全ガードレールを一律に有効化しないことでコストを管理します。Account Factory で作成されるアカウントの VPC やサブネットの構成もコストに影響するため、不要なリソースの自動作成を最小限に抑える設定が推奨されます。特に大規模組織 (100 アカウント以上) では、Config の評価コストが月数百ドルに達する場合があるため、OU ごとにガードレールの適用範囲を最適化することが重要です。

Organizations 単体構築との比較

Organizations と SCP を直接使ってマルチアカウント環境を構築することも可能ですが、Control Tower はそのプロセスを大幅に簡素化します。Organizations 単体では、CloudTrail のマルチアカウント集約設定、Config の Aggregator 構成、ログバケットのアクセスポリシー設定、アカウント作成時のベースライン適用をすべて手動で構築する必要があります。Control Tower はこれらを自動化し、ドリフト検出でガバナンスの一貫性を継続的に監視します。一方、Control Tower には制約もあります。サポートされるリージョンの組み合わせに制限があること、ネストされた OU の階層に制限があること、ランディングゾーンの更新時にダウンタイムが生じる可能性があることです。組織が独自のガバナンスフレームワークを既に持ち、SCP と Config ルールを Terraform や CDK で完全に管理している場合は、Control Tower を使わず Organizations 直接管理の方が柔軟性を確保できます。

まとめ

Control Tower はマルチアカウント環境のセットアップとガバナンスを自動化するサービスです。ランディングゾーンでベストプラクティス構成を自動構築し、ガードレールでセキュリティポリシーを強制し、Account Factory でアカウント作成を標準化します。OU 設計の階層化とガードレールの段階的適用を組み合わせることで、セキュリティと開発者の俊敏性を両立できます。組織の AWS 利用が拡大する際の基盤として不可欠です。

関連するサービス

AWS Control Towerマルチアカウント環境のセットアップとガバナンスを自動化するサービスAWS Organizations複数の AWS アカウントを一元管理するサービスAWS ConfigAWS リソースの構成変更を記録・評価し、コンプライアンスを継続的に監視するサービス

関連する記事

AWS Service Catalog で実現する IT ガバナンス - 承認済み製品の標準化とセルフサービスIT 部門が承認した CloudFormation テンプレートをカタログ化し、起動制約とテンプレート制約でエンドユーザーのセルフサービスを安全に提供する手法を紹介します。AWS Config で実現する継続的コンプライアンス監視 - ルール評価と自動修復AWS Config によるリソース構成の記録、Config ルールによるコンプライアンス評価、自動修復アクションの設定を解説します。AWS Organizations で実現するマルチアカウント管理 - OU 設計と SCP によるガバナンスOU 階層の設計と SCP によるアクセス制御でマルチアカウント環境のガバナンスを確立する。一括請求によるコスト管理も紹介します。

同じテーマの記事

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マルチアカウント AWS 環境のセットアップとガバナンスを自動化し、セキュリティとコンプライアンスのベースラインを一元管理するサービスAWS マルチアカウント統制の設計力 - Organizations・Control Tower・SCP による組織ガバナンスAWS Organizations、Control Tower、SCP (Service Control Policies) を中心とするマルチアカウント統制の仕組みを、Azure Management Groups と比較し、エンタープライズガバナンスの設計力の差を解説します。AWS Organizations で実現するマルチアカウント管理 - OU 設計と SCP によるガバナンスOU 階層の設計と SCP によるアクセス制御でマルチアカウント環境のガバナンスを確立する。一括請求によるコスト管理も紹介します。