AWS ランディングゾーン図：Organizations と Control Tower によるマルチアカウント構成

すべてを 1 つの AWS アカウントで賄うやり方は、うまくいかなくなるまではうまくいきます。テストスクリプトが本番のバケットを削除する。経理が請求をチームごとに分けられない。監査人が監査ログを変更できるのは誰かと尋ね、正直な答えは「管理者権限を持つ全員」になる。ランディングゾーンとは、ワークロードが入ってくる前に用意しておくマルチアカウントの土台です。新しいアカウントがすべて引き継ぐ、アカウント構成、ID、ガードレール、ログ、ネットワークのことです。

この記事では、図を使ってランディングゾーンの設計を順に説明します。なぜ複数のアカウントにするのか、推奨される組織単位、コアアカウント、サービスコントロールポリシー（SCP）、リソースコントロールポリシー（RCP）、宣言型ポリシーによるガードレール、ID、ログの集約とセキュリティツール、ネットワーク、そして Control Tower（ランディングゾーン 4.0 の変更点を含む）や Terraform で構築する方法です。

なぜ複数のアカウントにするのか

AWS アカウントは、AWS が提供する最も強力な分離境界です。IAM の権限、サービスクォータ、コスト、そしてほとんどの障害は、アカウントの境界で止まります。アカウントを分けると、次のものが得られます。

• 影響範囲の限定。 サンドボックスでのミスや漏えいした認証情報が本番に触れることはありません。
• 明確な責任範囲と請求を、チーム、アプリケーション、環境ごとに持てます。
• よりシンプルな権限。 タグ条件だらけの 1 つのアカウントではなく、各アカウントにそのチームが必要とするアクセスだけを与えます。
• 独立したクォータ。あるチームの負荷テストが別のチームの上限を使い切ることはありません。

代償は調整です。ID、ログ、ガードレール、ネットワークが数十のアカウントをまたいで機能しなければなりません。その調整を提供するのがランディングゾーンです。

構成：組織単位

AWS Organizations はアカウントを組織単位（OU）にまとめ、OU にアタッチしたポリシーはその配下のすべてのアカウントに適用されます。AWS のホワイトペーパー「AWS 環境の整理」は、出発点として次の OU を推奨しています。

Workloads は早い段階で Prod と Non-prod のサブ OU に分けてください。両者ではガードレールが異なり、あとからアカウントを移すのは大変です。閉鎖待ちのアカウントのために、すべてを拒否するポリシーを付けた Suspended OU も追加しましょう。

管理アカウント

管理アカウントは、組織、一括請求、Control Tower を所有します。ここにワークロードを置かないでください。決定的な理由があります。Organizations のドキュメントにあるとおり、SCP は管理アカウントのユーザーやロールには影響しません。そこにデプロイしたものは何ひとつガードレールで制限されないので、ユーザーもリソースもできるだけ少なくします。

コアアカウント

• Log Archive。 組織の CloudTrail 証跡と AWS Config の履歴を S3 で受け取ります。書き込みや削除の権限を持つ人はほぼいません。管理者でさえログを改ざんできないよう、S3 Object Lock の利用を検討してください。
• Security Tooling（Audit とも呼ばれます）。GuardDuty、Security Hub、IAM Access Analyzer、AWS Config アグリゲーターの委任管理者です。これにより、セキュリティチームは管理アカウントにアクセスせずに、すべてのアカウントを 1 か所から見られます。
• Network。 Transit Gateway、データセンターへのプライベート接続、DNS リゾルバー、IP アドレス管理を所有し、AWS Resource Access Manager でワークロードアカウントと共有します。
• Shared Services。 CI/CD、アーティファクトリポジトリ、多くのチームが使うその他のツールです。

ガードレール：SCP、RCP、宣言型ポリシー

Organizations には複数のポリシータイプがあり、それぞれ答える問いが異なります。

ポリシーは制限するだけで、権限を付与することはありません。まずは効果の高い短いガードレールのリストから始めます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "cloudtrail:UpdateTrail"],
      "Resource": "*"
    }
  ]
}

リージョン制限は人気がありますが、間違えやすいものです。IAM のようなグローバルサービスは許可したままにする必要があるからです。新しいポリシーは、Workloads にアタッチする前に、代表的なアカウントを 1 つ入れたステージング OU で必ずテストしてください。

Control Tower はガードレールを 3 種類のコントロールとして提供します。SCP と RCP で実装される予防コントロール、AWS Config ルールで実装される検出コントロール、そして CloudFormation がリソースを作成する前にチェックするプロアクティブコントロールです。

ID

ワークロードアカウントに、長期間有効なキーを持つ IAM ユーザーを人のために作ってはいけません。IAM Identity Center を企業の ID プロバイダーに接続し、SCIM でユーザーとグループをプロビジョニングし、アカウントごとにグループへ割り当てたアクセス許可セットでアクセスを付与します。たとえば、開発者には Non-prod でパワーユーザー、Prod で読み取り専用のアクセスを与えます。

ハードウェア MFA 付きの緊急用（break-glass）ID を 2 つ用意し、オフラインで保管して監視します。ルートユーザーについては、2024 年 11 月に導入された機能により、IAM でメンバーアカウントのルートアクセスを一元管理できるようになりました。メンバーアカウントからルートの認証情報を完全に削除し、ルートにしかできない数少ない作業を一か所から実行できます。

ログと検出

1. CloudTrail の組織の証跡が、すべてのアカウントとリージョンの API アクティビティを Log Archive アカウントに記録します。
2. AWS Config がすべての場所でリソース構成を記録し、アグリゲーターは Security Tooling に置きます。
3. GuardDuty と Security Hub を組織全体で有効にし、Security Tooling を委任管理者にします。新しいアカウントも自動的に対象になります。
4. 検出結果は SIEM やオンコールのツールに送られます。

ネットワーク

ワークロードアカウントは自分の VPC を所有しますが、接続は所有しません。Network アカウントが、Resource Access Manager で共有する Transit Gateway、集約された送信トラフィックと検査、クラウドとデータセンター間の DNS 解決、そして IP アドレス計画を提供します。IP アドレス計画は、VPC 同士が重複しないよう Amazon VPC IP Address Manager で管理するのが理想です。各ワークロード VPC の中身は AWS VPC 図で、複数リージョンへの拡張は AWS マルチリージョンアーキテクチャ図で扱っています。

構築：Control Tower か Terraform か

AWS Control Tower は、組織、コアアカウント、組織の証跡、Config、コントロールのカタログをセットアップし、新しいアカウントを作成する Account Factory を提供します。Control Tower のリリースノートによると、2025 年 11 月 17 日にリリースされたランディングゾーン 4.0 で、柔軟性が大きく高まりました。

• AWS Config、CloudTrail、セキュリティロール、AWS Backup との統合が任意になりました。
• Security OU は必須ではなくなり、独自の OU 構成を定義できます。
• 最小構成では、Organizations との統合とコントロールだけを使うこともできます。
• Config と CloudTrail に専用のリソースが用意され、サービスにリンクされた Config アグリゲーターが従来の集約方式に代わります。

Terraform を使うチームは、Control Tower と Account Factory for Terraform（AFT）を組み合わせることがよくあります。AFT は Git リポジトリからアカウントをプロビジョニングし、カスタマイズします。2026 年 9 月からは、AFT のカスタマイズを plan のみのモードで実行し、適用前に変更をプレビューできるようになりました。ほかに、Organizations をすべて Terraform で管理するチームや、Landing Zone Accelerator on AWS ソリューションを使うチームもあります。どれも機能します。大事なのは、アカウントの作成が自動化され、再現可能であることです。

アカウントの払い出し

新しいアカウントは、すぐ使える状態で届くべきです。リクエスト（多くの場合はプルリクエスト）によって、適切な OU にアカウントが作られ、ベースライン（Identity Center の割り当て、予算とアラート、Transit Gateway に接続された VPC、既定のセキュリティサービス）が適用され、チームに引き渡されます。Organizations では、1 つの組織のアカウント数は既定で 10 に制限されています。Service Quotas で引き上げられるので、必要になる前に申請しておきましょう。

よくある誤り

• SCP がまったく適用されない管理アカウントにワークロードを置く。
• フラットな Workloads OU が 1 つだけで、本番と開発が同じガードレールを共有している。
• チームがすでに前提を置いて構築したあとで、その前提を壊すガードレールを書く。
• 管理者が変更できる Log Archive アカウント。
• 手作業で作られ、それぞれ少しずつ違うアカウント。

ランディングゾーンの図

図の読み方は次のとおりです。

• 上部の管理アカウントが組織とポリシーを持ちます。各 OU へのエッジはガードレールのアタッチを表します。
• Security OU には、すべてのアカウントからログを受け取る Log Archive と、GuardDuty と Security Hub を管理する Security Tooling があります。
• Infrastructure OU には、Transit Gateway でワークロード VPC をつなぐ Network アカウントと、CI/CD 用の Shared Services があります。
• Workloads OU は Prod と Non-prod のアカウントを分け、Sandbox OU は隔離されたままです。
• 右側の IAM Identity Center が、アクセス許可セットを通じて人にアクセスを付与します。
• Markdown ブロックは最初に入れるガードレールの一覧です。

アカウント構成をわかりやすく描くには

• OU はコンテナとして描き、アカウントをその中に置きます。階層そのものがポリシーモデルです。
• 管理アカウントは離して描きます。 ガードレールの外にあることを、図でも示すべきです。
• アカウントをまたぐフローだけを描きます。 アーカイブへのログ、ネットワーク接続、委任管理、ID です。
• アカウントはアカウント番号ではなく、役割で名付けます。

背後にあるセキュリティモデルについては、ゼロトラストアーキテクチャ図を参照してください。インフラをコードで管理しているなら、Terraform アーキテクチャ図で Terraform 管理の環境の描き方を紹介しています。

Archboard で作る

1. Google または GitHub でサインインし、図を作成します。
2. 管理アカウント用にセキュリティパックの ポリシー ノードを、IAM Identity Center 用に IDプロバイダー を追加します。
3. OU 用に基本パックの フレーム ノードを 4 つ追加します。Security、Infrastructure、Workloads、Sandbox です。
4. Security の中に、Log Archive 用としてクラウドパックの オブジェクトストレージ ノードを、Security Tooling 用として DevOps パックの アラート ノードを追加します。Infrastructure の中には、Network アカウント用としてネットワークパックの ルーター を、Shared Services 用として DevOps パックの パイプライン を追加します。
5. Prod、Non-prod、Sandbox の各アカウント用に、クラウドパックの コンピューティング ノードを追加します。
6. 管理アカウントを各 OU に、各アカウントを Log Archive に、Network アカウントをワークロードにつなぎ、ガードレールを書いた基本パックの Markdown ブロックを追加します。

この例で使うダイアグラムノードは 14 個で、Free プランの範囲に収まります。

よくある質問

AWS ランディングゾーンとは何ですか？ ワークロードを移す前に、自社のセキュリティと運用の基準に沿って構築したマルチアカウントの AWS 環境です。組織単位、コアアカウント、ID、ガードレール、ログ、ネットワークを含みます。

ランディングゾーンには AWS Control Tower が必要ですか？ いいえ。Control Tower はマネージドな構築手段であり、バージョン 4.0 でより柔軟になりました。Organizations を Terraform、Account Factory for Terraform、Landing Zone Accelerator で管理することもできます。

SCP と RCP の違いは何ですか？ SCP は、メンバーアカウントのプリンシパルが何をできるかを制限します。RCP は、メンバーアカウントのリソースに対して何ができるかを制限します。たとえば、バケットが組織外と共有されるのを防ぎます。どちらも権限は付与しません。

なぜ管理アカウントは空にしておくべきなのですか？ SCP は管理アカウントのユーザーとロールには適用されないため、そこにあるものはすべてガードレールの外になります。さらに、請求と組織そのものを管理するため、最も機密性の高いアカウントでもあります。

1 つの組織にはいくつのアカウントを作れますか？ 既定では 10 個です。クォータは Service Quotas で引き上げられ、引き上げを申請できるのは管理アカウントだけです。

無料で始める — 1 シート、クレジットカード不要。