AWS Control Towerは、同じ対象を別の言葉で呼ぶ場面が公式ドキュメントの中にも残っているサービスです。「ガードレール」と「コントロール」、「作成」と「登録」、そして共有アカウントが3つなのか2つなのか。さらにLanding Zone 4.0では、registeredやenrolledといった語の定義そのものが変わりました。用語を曖昧にしたまま設計を始めると、有効にしたつもりのコントロールが効いていない、ドリフトの警告が消えないといった食い違いが後から出てきます。この記事では、公式ドキュメントの定義と版による意味の変化を突き合わせて基本用語を整理します。サービス全体の定義や料金、導入判断はAWS Control Towerとは？マルチアカウント統制の仕組みと導入判断で扱っています。
まとめ：用語の取り違えで起きる食い違い
実務で問題になりやすいのは、次の点です。ガードレールとコントロールは新旧の呼び名であって別機能ではありません。「必須コントロール」はLanding Zone 4.0以降、既定では適用されなくなりました。OU間のアカウント移動がドリフトになるかどうかは、自動登録の設定で変わります。
| 用語 | 公式の定義 | 取り違えの型 |
|---|---|---|
| コントロール | OU単位で効く統制ルール | 旧称ガードレールと別機能だと誤解 |
| ランディングゾーン | 推奨構成のクラウド環境 | 構築する側のサービスと混同 |
| 共有アカウント | 管理・ログアーカイブ・監査 | 2つと数える記述も公式に残る |
| ドリフト | 構成済みリソースへの変更 | 検知的コントロールの違反と混同 |
| 登録（Enroll） | 既存アカウントの統制下への編入 | Account Factoryでの作成と混同 |
以降で、それぞれの語が公式ドキュメントでどう定義され、どこに版による差と例外があるのかを見ていきます。
コントロール（旧ガードレール）の定義と用語移行の現状
コントロールは、AWS環境全体に継続的なガバナンスを提供する高レベルのルールです。適用単位はOU（組織単位）であり、そのOUに属するアカウントはすべて対象になります。アカウントを名指しして有効化する仕組みではない点が、IAMポリシーとの一番大きな違いです。
ガードレールはコントロールの旧称です。AWS公式ドキュメントには、業界での用法や他のAWSサービスに合わせて用語を移行中であり、ドキュメント・コンソール・ブログで旧称と新称が混在する可能性があること、両者は同義であることが注記されています。旧称は表記だけの問題ではなく実体にも残っており、Control Towerが管理するSCPの識別子は現在もaws-guardrailsで始まります。組織のポリシー一覧を棚卸しするとき、この接頭辞がControl Tower管理下の目印になります。なお、利用できるコントロールの一覧を指すControl Catalogは、2025年6月にControls Libraryから改称された名称です。
予防的・検知的・プロアクティブの3挙動と状態表示の読み分け
コントロールは挙動によって3種類に分かれ、それぞれ別のAWSサービスで実装されています。挙動ごとの使い分けの方針はAWS Control Towerとは？マルチアカウント統制の仕組みと導入判断で扱っているため、ここでは用語として押さえるべき実装と状態表示の対応に絞ります。
| 挙動 | 実装 | 状態表示 | 有効な範囲 |
|---|---|---|---|
| 予防的 | SCP・RCP・宣言型ポリシー | enforced / not enabled | 全リージョン |
| 検知的 | AWS Configルール | clear / in violation / not enabled | 対応リージョンのみ |
| プロアクティブ | CloudFormation hooks | PASS / FAIL / SKIP | 対応リージョンのみ |
状態表示が挙動ごとに違うのは、評価するタイミングが違うためです。予防的コントロールは操作そのものを拒否するので、状態は「効いている（enforced）」か「有効化していない」かの二択にしかなりません。検知的コントロールは作成済みリソースを評価するため、違反あり（in violation）という第三の状態を持ちます。ここで注意したいのが、not enabledとclearの違いです。cleanな状態を表すのはclearだけで、not enabledは「そもそも評価していない」を意味します。ダッシュボード上で違反が出ていないことを、統制が効いている証拠として読んではいけません。
プロアクティブコントロールはCloudFormationでプロビジョニングされる前にスキャンし、非準拠のリソースは作成されません。裏を返すと、コンソールから手作業で作ったリソースは検査対象外です。また検知的コントロールの実体はAWS Configとは？設定変更の記録・ルール評価・料金の考え方と導入判断を実装者目線で解説【2026年時点】で解説しているConfigルールですが、2025年6月以降はサービスリンクConfigルールとして展開され、Control Tower経由でのみ変更できます。ARNがarn:aws:config:*:*:config-rule/aws-service-rule/controltower.*/*の形式であればこの方式です。Config側で個別に修復設定を足すことはできません。
必須・強く推奨・選択的のガイダンス区分とLanding Zone 4.0での既定変更
ガイダンスは、そのコントロールをどう適用すべきかの推奨度を示す区分で、必須・強く推奨・選択的の3つがあります。挙動の分類とは独立した軸なので、「必須の検知的コントロール」のような組み合わせが成立します。必須はControl Towerが展開したリソースを保護するもの、強く推奨はマルチアカウント環境の一般的なベストプラクティス、選択的は企業環境で制限されがちな操作を追跡・封鎖するものと位置づけられています。
注意が必要なのは、2025年11月17日にリリースされたLanding Zone 4.0以降、必須コントロールが既定では適用されなくなった点です。「必須と書かれているから有効になっているはず」という読み方は、4.0の環境では通用しません。実際の有効状態は、コンソールのEnabled controlsページかListEnabledControls APIで確認します。バージョンによる差分の全体像はAWS Control Tower Landing Zoneとは？構成要素とv4.0の変更点を解説にまとめています。
管理アカウントがコントロールの適用外になる理由
予防的コントロールは管理アカウントには適用されません。管理アカウントのrootユーザーと管理者は、コントロールが本来拒否する操作を実行できます。これは仕様上意図された例外で、管理アカウントが自らのポリシーによって操作不能な状態に陥ることを防ぐためのものです。ただし免責ではなく、管理アカウント内の操作はログアーカイブアカウントに集約されるログに記録され続けます。「コントロールが適用されない」と「記録されない」は別の話です。
ランディングゾーン・OU・共有アカウントの呼び分け
ランディングゾーンは、既定のアカウント・アカウント構造・ネットワークとセキュリティのレイアウトなどを含む、推奨される出発点としてのクラウド環境を指します。それを構築・管理する側のサービスがControl Towerです。「ランディングゾーンを導入する」という言い方が指す実体は、この環境の生成にあたります。構成要素の内訳はAWS Control Tower Landing Zoneとは？構成要素とv4.0の変更点を解説で扱っているため、ここでは呼称の区別に絞ります。
共有アカウントが3つと2つで揺れている理由
公式の用語ページでは、共有アカウントは「ランディングゾーンのセットアップ時にAWS Control Towerが自動的に作成する3つのアカウントのうちの1つ。すなわち管理アカウント、ログアーカイブアカウント、監査アカウント」と定義されています。一方、Control Towerの動作を解説するページでは、Security OUに入るログアーカイブと監査の2アカウントを指して「しばしば共有アカウントと呼ばれる」と書かれています。つまり公式ドキュメント内で3つと2つの用法が併存しています。
読み替えの基準は文脈です。課金や組織の親という話題であれば管理アカウントを含む3つ、Security OU配下の話題であればログアーカイブと監査の2つを指します。設計書やレビューでこの語を使うときは、数ではなくアカウント名を書くのが安全です。なお、ログアーカイブと監査の名前はランディングゾーンの起動時にのみカスタマイズでき、後から改名できません。
ネストOU・トップレベルOU・Rootの関係
OUの用語はAWS Organizationsと共通ですが、Control Tower側で制約が加わります。ネストOUの階層は最大5階層までで、階層の最上位がLevel 1です。トップレベルOUはRootの直下にあるOUを指し、Root自体はOUに含めません。各アカウントが所属できるOUは1つだけで、ポリシーは階層を下って配下のOUとアカウントに影響します。SCPやRCPの継承そのものはOrganizationsの仕組みなので、ポリシー設計はAWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説と併せて検討してください。
Security OUの位置づけがLanding Zone 4.0で変わった点
Landing Zone 3.3以前では、セットアップ時にSecurity OUが自動作成され、その配下にログアーカイブと監査が固定配置されていました。Security OUを消すとランディングゾーンの即時リセットが必要になります。
4.0ではこの前提が変わりました。Control TowerはSecurity OUを作成せず、組織構造を利用者側で定義できます。要件として残るのは、各サービス統合用のアカウントが同一の親OU配下にあることだけで、サービス統合アカウントが置かれたOUがdesignated Security OUとして扱われます。すでにSecurity OUを持つ環境への影響はありません。「Security OUは必ず存在する」という前提で書かれた社内手順は、4.0へ上げる前に見直しが必要です。
ドリフトが指す状態と、逸脱として扱われる操作の範囲
ドリフトは、AWS Control Towerがインストールし構成したリソースへの変更を指します。エラーや障害ではなく状態名である点が、検知的コントロールの「違反（in violation）」との違いです。違反はリソースの設定がConfigルールに合っていないこと、ドリフトはControl Tower自身が敷いた統制の枠組みが崩れていることを指します。
ポリシーに関するドリフトの例は、管理対象SCPの更新と、OUからのデタッチです。Control TowerはSCP・RCP・宣言型ポリシーを日次でスキャンし、登録済みOUごとに、有効化された予防的コントロールのポリシー文が管理対象SCPに含まれているかを検証します。反対に、2025年8月20日の更新で「SCPが管理対象OUにアタッチされた」「SCPがメンバーアカウントにアタッチされた」の2種類はドリフト扱いから外れました。古い運用手順書にこの2つが残っていれば削除して構いません。
自動登録の有無でOU移動の扱いが変わる点
「OU間でアカウントを移動するとドリフトになる」は、条件付きでのみ正しい説明です。2025年10月15日に追加された自動登録を有効にしている場合（Landing Zone 3.1以上が対象）、アカウントを新しいOUへ移すとそのOUの有効なベースラインとコントロールが適用され、移動元のコントロールとベースラインは削除されます。この操作では多くの場合ドリフトは発生しません。有効化はSettingsページ、またはAPIでRemediationTypeにInheritance Driftを指定します。
自動登録を使っていない場合は従来どおりで、移動元のコントロールは自動では外れません。移動先で新しいhookベースのコントロールを有効にすると古いhookベースのコントロールは置き換わりますが、SCPとConfigルールで実装されたコントロールは手動で削除する必要があります。「移したのに前のOUのルールが残っている」という状況は仕様どおりの挙動です。例外として、サービス統合アカウントが在籍するOUへメンバーアカウントを移動した場合は、自動登録の有無にかかわらずそのOUの有効コントロールがドリフトします。
共有アカウントをSecurity OUの外へ移動した場合もドリフトになり、こちらの解決にはランディングゾーンの更新が必要です。また、ドリフト状態が残っているとコンソールのアカウント登録機能が動作せず、AWS Service Catalogとは？仕組み・ポートフォリオ設計と組織展開の判断を実装者目線で解説で説明しているService Catalog経由でアカウントをプロビジョニングすることになります。
ドリフト通知の宛先がバージョンで変わる点
Landing Zone 3.3以前では、メンバーアカウントのドリフトは監査アカウントに集約されるAmazon SNSの通知として届きます。同じリソースに同種のドリフトが繰り返し起きても通知は初回のみで、解消後に再発した場合に改めて通知されます。
4.0では宛先が変わります。AWSControlTowerBaselineを有効にしていない環境では、SNSトピックへのドリフト通知が停止し、管理アカウントのEventBridgeへ送られるようになりました。またアカウントの自動登録を有効にしている場合、従来のSNS通知は利用できません。通知が届かなくなったときは、まずこの2つの条件に当たっていないかを確認してください。プログラムから状態を取りたい場合は、ListEnabledBaselines APIにincludeChildrenを指定すると、アカウント単位のドリフト状況と登録状況を取得できます。
ホームリージョン・ガバナンス対象・拒否の3状態
ホームリージョンは、ランディングゾーンをデプロイしたリージョンです。選択後は変更できません。東京リージョンを主に使う予定であれば、最初のセットアップをどのリージョンのコンソールから始めるかが、そのまま後戻りできない決定になります。
リージョンの状態は3つに区別されます。governedはControl Towerが管理・監視し、コントロールで保護されるリージョンです。not governedは監視も制御もされず、リソースを作れますがコントロールでは保護されません。deniedはControl Towerが明示的に遮断し、そもそもリソースをプロビジョニングできないリージョンです。「使っていないリージョンを統制対象から外す」ことは、そのリージョンでの野良リソースを防ぐ手段にはなりません。利用そのものを封じたい場合はnot governedではなくリージョン拒否コントロールを使います。
挙動による差もあります。予防的コントロールはすべてのリージョンで機能しますが、検知的とプロアクティブはControl Towerがサポートするリージョンでのみ機能します。対応リージョンの数を調べるときは注意が必要で、ユーザーガイドのリージョン一覧には東京・大阪を含む33リージョンが列挙されている一方、2025年10月28日に追加されたアジアパシフィック（ニュージーランド）が反映されていません。正確な対応状況はAWS Region Tableで確認してください。なお、リージョンを追加してもOU内の既存アカウントは自動更新されないため、OUの再登録が必要です。
Account Factoryによる「作成」とEnrollによる「登録」の使い分け
Account Factoryは、承認済みの構成で新規アカウントの払い出しを標準化する、設定可能なアカウントテンプレートです。内部ではService Catalogを使ってプロビジョニングし、既定ではIAM Identity CenterのAWSAccountFactoryグループまたは管理グループに属するユーザーが払い出せます。認証基盤側の設計はAWS IAM Identity Centerとは？権限セット設計とCLI認証・IAMとの使い分けを実装者目線で解説を参照してください。
「作成」と「登録」は別の操作です。作成はAccount Factoryによる新規払い出し、登録（Enroll）は既に存在するアカウントを統制下に取り込む操作を指します。既存アカウントを登録するには、そのアカウントでAWSControlTowerExecutionロールが有効になっている必要があります。AWSはこれを登録の前提条件として明記しており、ロールを用意しないまま登録しようとすると失敗します。
さらにLanding Zone 4.0では、registeredとenrolledという語の定義自体が変わりました。従来はAWSControlTowerBaselineが適用されているかどうかが基準でしたが、4.0ではコントロールやベースラインなど何らかのControl Towerリソースが有効になっていれば統制下のリソースとみなされます。バージョンをまたいで書かれた資料を読むときは、この語が何を指しているかを版とセットで確認してください。
enrolledとunenrolledが混在するOUでのコントロール適用差
登録済みOUの中に、登録済みアカウントと未登録アカウントが混在することがあります。このとき、コントロールの効き方は挙動によって割れます。予防的コントロールはSCP・RCP・宣言型ポリシーによってOUレベルで適用されるため、未登録アカウントにも効きます。一方、検知的コントロールとプロアクティブコントロールは未登録アカウントには適用されません。
この非対称は、移行期の環境で監査時に問題になります。未登録アカウントは、禁止操作は止まるものの、非準拠リソースの検出対象からは外れているためです。「OUに入れたから統制下にある」ではなく、アカウント単位の登録状態まで確認してください。
用語を取り違えたまま設計した場合の実害
最も重いのは、必須コントロールの既定適用を前提に統制設計を書いてしまうケースです。Landing Zone 4.0以降は既定適用がないため、設計書上は保護されているはずの範囲が実際には無防備という状態が生まれます。しかもこの抜けは、検知的コントロールの違反としては上がってきません。有効化されていないコントロールは何も報告しないため、ダッシュボードは静かなままです。
次に見落とされやすいのが、ドリフトの前提を版と設定で確認しないまま運用手順を固定してしまうケースです。OU移動がドリフトになるかは自動登録の設定次第、通知がSNSで届くかはバージョンとベースラインの適用状況次第で変わります。手順書には必ず前提バージョンを書き添えてください。
逆に、用語の暗記そのものに時間をかける価値は高くありません。押さえるべきは、どの語がOU単位で効くのか、どの設定が後から変えられないのか、どの語がバージョンで意味を変えたのか、そして公式内で表記が揺れているのはどこか、という4点だけです。
よくある質問
ガードレールとコントロールは別の機能ですか？
同じものです。AWS公式ドキュメントには、用語を移行中でドキュメントやコンソールに旧称のガードレールと新称のコントロールが混在すること、両者は同義であることが明記されています。Control Towerが管理するSCPの識別子は現在もaws-guardrailsで始まるため、実体側にも旧称が残っています。
「必須コントロール」は常に有効になっていますか？
Landing Zone 4.0以降、必須コントロールは既定では適用されません。必須という名称は推奨度の区分であって、自動適用の保証ではありません。現在の有効状態は、コンソールのEnabled controlsページかListEnabledControls APIで確認してください。
OU間でアカウントを移動するとドリフトになりますか？
自動登録を有効にしていれば、移動先OUのベースラインとコントロールが適用され、移動元のものは削除されるため、多くの場合ドリフトにはなりません。自動登録を使っていない場合はドリフトとして扱われ、SCPとConfigルールで実装されたコントロールは手動で削除する必要があります。ただしサービス統合アカウントが在籍するOUへの移動は、自動登録の有無にかかわらずドリフトになります。
ホームリージョンは後から変更できますか？
変更できません。ランディングゾーンをデプロイしたリージョンがホームリージョンとして固定されます。ガバナンス対象のリージョンは後から追加・削除できますが、その場合は既存アカウントを更新するためにOUの再登録が必要です。
共有アカウントは3つですか、2つですか？
公式の用語ページでは、管理アカウント・ログアーカイブアカウント・監査アカウントの3つと定義されています。一方、動作解説のページではログアーカイブと監査の2つを共有アカウントと呼んでおり、公式内で用法が分かれています。文脈で読み替えるか、設計書ではアカウント名を明記してください。
