運用管理

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

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

約 1 分で読めます

Control Tower の役割

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

ガードレールの設計

ガードレールは必須、強く推奨、選択的の 3 段階で 400 以上が提供されます。予防的ガードレールは SCP で実装され、禁止されたアクションを事前にブロックします。例えば「ログアーカイブアカウントの CloudTrail 設定の変更を禁止」「リージョン制限 (許可されたリージョン以外での操作を禁止)」などです。検出的ガードレールは Config ルールで実装され、非準拠の設定を検出して通知します。例えば「EBS ボリュームが暗号化されていない」「S3 バケットがパブリックアクセス可能」などです。プロアクティブガードレールは CloudFormation フックで実装され、非準拠のリソースの作成を事前にブロックします。

Account Factory とカスタマイズ

Account Factory は Service Catalog と統合されたアカウント作成機能です。開発者がセルフサービスでアカウントを申請すると、標準化された設定 (VPC 、サブネット、セキュリティグループ、 IAM ロール) が自動適用されたアカウントが数分で作成されます。 Customizations for Control Tower (CfCT) を使用すると、アカウント作成時にカスタムの CloudFormation テンプレートを自動適用できます。セキュリティツールのインストール、監視エージェントの設定、標準的な IAM ロールの作成などを自動化し、全アカウントで一貫した構成を保証します。 Control Tower の運用ノウハウを深めるには、専門書籍 (Amazon)が役立ちます。

Control Tower の料金

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

まとめ

Control Tower はマルチアカウント環境のセットアップとガバナンスを自動化するサービスです。ランディングゾーンでベストプラクティス構成を自動構築し、ガードレールでセキュリティポリシーを強制し、Account Factory でアカウント作成を標準化します。組織の 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 でマルチアカウント環境を構築 - ランディングゾーンとガードレールベストプラクティスに基づくマルチアカウント環境を自動構築し、400 以上のガードレールでコンプライアンスを継続的に維持する。Account Factory と Customizations for Control Tower による拡張手法を解説します。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 を全アカウントに一括展開し、セキュリティとコンプライアンスの統合管理を実現する方法を解説します。