アカウントが増えてくると、Organizations と SCP は分かっても、そこに Control Tower という名前が出てきて混乱しがちです。上位版なのか、別の機能なのか。ランディングゾーン、コントロール、Account Factory という3つの語も、別々に説明されて1枚の絵になりません。この記事は、3つの語を1つの仕組みの役割として並べ直し、上司や顧客に説明できる形にします。
この記事の結論
- Control Tower は新しい権限の仕組みではなく、Organizations などを束ね、型に沿ってマルチアカウント環境を作り保つ調整役です。
- ランディングゾーンは OU・アカウント・ログ集約などを含む環境全体の土台で、作った後は型からのずれ（ドリフト）を検知して修復します。
- コントロールは OU 単位で効く統制ルールで、予防・発見・プロアクティブの3種があります。
- Account Factory は承認済みの設定でアカウントを払い出す雛形で、アカウントが増えるほど効きます。
- 管理アカウントの管理者とルートはコントロールの対象外なので、ワークロードは置きません。
- 選ぶ基準は「型に合わせて早く統制を敷く」か「自前で細かく設計する」かです。
AWS Control Tower とは何か
Control Tower は、AWS Control Tower という名前のとおり、複数のアカウントを持つ環境を管理するための調整役です。公式のドキュメントでは、AWS Organizations、AWS Service Catalog、IAM Identity Center などのサービスを束ねて、決まった型でマルチアカウント環境を用意し、運用できるものとして説明されています。
大事なのは、権限の枠そのものを新しく作るわけではない点です。アカウントの束ねと SCP のような上限は Organizations が担い、Control Tower はそれらを型に沿って敷く側にいます。「Organizations の上位版」と覚えるより、「Organizations を中心に、周辺サービスを含めて一式で用意する調整役」と覚えるほうが、説明がずれません。
ONE COORDINATOR束ねる調整役
Control Tower は新しい権限の仕組みではなく、既存の部品を型に沿って束ねる
土台を作る
- Organizations — アカウントと OU、SCP
- Service Catalog / IAM Identity Center — 払い出しとサインインの入口
- Control Tower — ランディングゾーン・コントロール・Account Factory
統制を敷く
- Organizations — アカウントと OU、SCP
- Service Catalog / IAM Identity Center — 払い出しとサインインの入口
- Control Tower — ランディングゾーン・コントロール・Account Factory
払い出す
- Organizations — アカウントと OU、SCP
- Service Catalog / IAM Identity Center — 払い出しとサインインの入口
- Control Tower — ランディングゾーン・コントロール・Account Factory
利用者が見て決める層裏で束ねられる層
Control Tower が提供するものは、大きく3つに分けて覚えると整理しやすくなります。
| 提供されるもの | 何をするか | 次の章 |
|---|---|---|
| ランディングゾーン | アカウントの土台となる環境全体 | 2 |
| コントロール | OU 単位で効く統制ルール | 3 |
| Account Factory | 承認済みの設定でアカウントを払い出す雛形 | 4 |
これらに加えて、公式にはダッシュボードがあり、環境の状態を一覧で見られます。アカウントの設計判断そのもの（どう分けるか、SCP をどう書くか）は、前提記事の 
READ ALSO — プロフェッショナル向け・段4 設計
マルチアカウント設計｜アカウントを「境界」として使い、Organizations と SCP で組織のガードレールを引く
で扱いました。この記事は「Control Tower が何を束ねるか」までに絞ります。
CHECK 1ここまでの確認
Control Tower と Organizations の関係として、正しいものはどれ?
答えと解説
答え: 2. Organizations などを束ねて、土台・統制・払い出しを型に沿って用意する調整役
権限の枠を担うのは Organizations の SCP などで、Control Tower はそれを型に沿って敷きます。「Control Tower とは何か」を読み直してください。
ランディングゾーンには何が入るのか
ランディングゾーンは、Control Tower が用意する環境全体の土台です。複数のアカウントを OU（組織単位）にまとめ、ログを集める専用のアカウントや、人がサインインする入口を、最初から決まった型で置きます。個々のアカウントのことではなく、アカウントを置く「場所の設計」と考えてください。
ここで「型」と呼んでいるのは、ログの集約、サインインの入口、OU の分け方といった、マルチアカウントで後から必ず必要になる土台を、先に決めた形で置くという意味です。自前で組むと、これらの配線を1つずつ設計することになります。Control Tower はその最初の組み上げを肩代わりします。
また、ランディングゾーンは作って終わりではありません。作った後も、型からずれていないかを見張り続けます。これは後述のドリフトの話につながります。
練習問題 sap-o-003 が問うのも、この組み合わせです。アカウントを頻繁に払い出す組織が、ログの集約・セキュリティの基準・禁止操作を新しいアカウントすべてに揃えたいとき、ランディングゾーンを構築し、Account Factory で払い出し、コントロールを OU に適用する、という流れが答えになります。
コントロールとは何か
コントロールは、環境全体に効く統制ルールです。公式のドキュメントでは、コントロールは OU 全体に効くと説明されています。以前はガードレール（guardrail）と呼ばれ、公式が用語を移行している途中で、両者は同義です。古い資料でガードレールと読んだら、コントロールと読み替えてかまいません。
コントロールには3つの種類があります。
WHEN IT WORKS予防と発見の違い
予防は操作を拒否し、発見は作った後に検出する
予防（preventive）
SCP などで実行そのものを止める
- 効くとき操作の実行時
- やること許可しない操作を拒否する
発見（detective）
作られたリソースを見つけて知らせる
- 効くときリソースが作られた後
- やること基準違反を検出して見せる
| 種類 | いつ効くか | 何をするか |
|---|---|---|
| 予防（preventive） | 操作の実行時 | 許可しない操作を拒否する |
| 発見（detective） | リソースが作られた後 | 基準違反を見つけて知らせる |
| プロアクティブ（proactive） | リソースが作られる前 | 作成前に、基準に合うかを確認する |
OU に付ける意味
コントロールは、アカウントごとではなく OU に付けます。OU の下に新しいアカウントが入れば、同じコントロールが自動で効きます。ここが、アカウントを払い出すたびに設定を揃える手間をなくす要点です。
実装としては、予防のコントロールは SCP などの仕組みで実行されます。練習問題 scs-o-087 のように、承認していないリージョンの操作を拒否したいときは、リージョン拒否のコントロールを有効化します。中身は組織全体に効く SCP の仕組みで動くので、「コントロールは SCP を型に沿って敷いたもの」と説明できます。ただし実装方式ごとの詳細は、公式のページで確認してください。
3種の使い分け
練習問題 scs-o-088 が問うのは、CloudFormation でリソースを作る場面です。基準に合わないリソースを、作られる前に確かめたいなら、プロアクティブが答えです。予防は「操作を拒否する」ものなので、作成前の確認とは役割が違います。発見は作られた後に見つけるものです。
CHECK 2ここまでの確認
リソースが作られる前の段階で、基準に合うかを確かめるコントロールはどれ?
答えと解説
答え: 3. プロアクティブ
予防は操作そのものを拒否し、発見は作られた後に見つけます。作成前に確かめるのがプロアクティブです。「コントロールとは何か」を読み直してください。
Account Factory とは何か（払い出しとドリフト）
Account Factory は、承認済みの設定でアカウントを払い出す雛形です。アカウントを作るたびに担当者が個別に設定すると、ログの配線やセキュリティの基準が人によってばらつきます。Account Factory を通せば、新しいアカウントは決まった設定で生まれ、所属する OU のコントロールを受けます。
数が少ないうちは、手作業でも回ります。アカウントを毎週のように増やす組織ほど、標準化の効果が大きくなります。「新アカウントを標準設定で払い出す」役割と覚えてください。具体的な手順や画面は改定されるので、公式のドキュメントを見てください。
ドリフトとは何か
ドリフトは、Control Tower が用意した型から、環境の実態がずれることを指します。たとえば、型として決めたものが、運用の途中で誰かの手で変えられた場合です。
ランディングゾーンを作った後で大事なのは、このずれを見つけ、戻せることです。型を作るだけで放置すると、時間とともに実態と設計が食い違います。Control Tower はドリフトを検知する役割を持ち、修復の手段もあります。検知や修復の細かい挙動は、公式のドリフトのページで確認してください。この記事では、そのページを開いて確認できていないため、詳細は書きません。
管理アカウントの例外とは何か
コントロールには、意図的な例外があります。公式のドキュメントでは、管理アカウントの管理者とルートユーザーはコントロールの対象外と説明されています。
管理アカウントでやってはいけないこと
- ワークロードを管理アカウントに置く（コントロールが効かず、統制の外になる）
- 管理アカウントの管理者・ルートを日常の作業に使う
管理アカウントは、組織の管理のために使うアカウントです。ワークロードを置くと、そこだけ統制が効かない場所ができます。「統制を敷いたのに、抜け道が残っている」状態を避けるために、ワークロードは別のアカウントに置いてください。責任共有モデルの考え方では、AWS が用意する基盤の上で、利用者側の責任（設定と運用）が残ります。コントロールを敷いても、この点は変わりません。
CHECK 3ここまでの確認
管理アカウントにワークロードを置かないほうがよい理由は?
答えと解説
答え: 1. 管理アカウントはコントロールの対象外で、統制が効かないから
管理アカウントの管理者とルートはコントロールの対象外で、これは意図的な例外です。「管理アカウントの例外」を読み直してください。
Control Tower を使うか、自前で組むか
判断の軸は、「型に合わせて早く統制を敷く」か「自前で細かく設計する」かです。
TEMPLATE OR CUSTOM型か、自前か
型に合わせて早く統制を敷くか、自前で細かく設計するか
Control Tower で型から始める
- 土台・統制・払い出しが一式で揃う
- ドリフトを見張れる
- アカウントが増えるほど効く
Organizations で自前設計
- 構成を細部まで自分で決められる
- 型への合わせ込みが要らない
- 配線と保守は自分で持つ
支点は「アカウントの数と、統制をどれだけ細かく決めたいか」
| 観点 | Control Tower で型から始める | Organizations で自前設計 |
|---|---|---|
| 立ち上げ | 土台・統制・払い出しが一式で揃う | 1つずつ設計して組む |
| 設計の自由度 | 型の範囲で決める | 細部まで自分で決められる |
| ずれの管理 | ドリフトを見張れる | 見張る仕組みを自分で用意する |
| 向く規模 | アカウントが増えるほど効く | アカウントが少なく、独自の統制が必要なとき |
向かない場面もあります。アカウントが少なく、統制を独自に細かく決めたいときは、型に合わせる作業が負担になることがあります。このときは、自前の Organizations 設計が合う場合があります。
反対に、これからアカウントを増やす組織は、型に沿って始めておくと、後から追加する手間が小さくなります。ただし、この記事は設計の考え方を公式のドキュメントから整理したもので、本番運用の経験を語るものではありません。料金や対応リージョンなど、判断に必要な数値は公式のページで確認してから決めてください。
CHECK 4ここまでの確認
アカウントが少なく、統制を独自に細かく決めたいとき、傾向として合いやすいのはどれ?
答えと解説
答え: 2. 自前で Organizations を設計する選択が合う場合がある
型への合わせ込みが負担になることがあります。「使うか、自前で組むか」を読み直してください。
まとめ
Control Tower は、Organizations などを束ねる調整役です。土台のランディングゾーン、統制のコントロール、払い出しの Account Factory の3つを型で用意し、ドリフトを見張ります。コントロールは OU に付けて予防・発見・プロアクティブを使い分け、管理アカウントはその対象外なのでワークロードを置きません。選ぶ軸は、型に合わせて早く敷くか、自前で細かく設計するかです。
Cloudory 執筆者（AWS 認定 全冠）
上司や顧客には、「新しい権限の仕組みではなく、Organizations を中心に、土台・統制・払い出しを一式で用意する調整役」と伝えてください。次は、マルチアカウントの権限設計とログの保存の設計に進むと、Control Tower が用意する土台の中身が見えてきます。
参照ソース
- What is AWS Control Tower?（AWS Control Tower ユーザーガイド） — Organizations・Service Catalog・IAM Identity Center を束ねる位置づけと、ランディングゾーン・コントロール・Account Factory・ダッシュボードの定義の根拠
- Controls（AWS Control Tower ユーザーガイド） — コントロールが OU 全体に効くこと、予防・発見・プロアクティブの3種、guardrail と control が同義であること、管理アカウントの管理者とルートが対象外であることの根拠
