組織単位 (OU)

組織単位 (OU) は、組織内の AWSアカウントのグループです。OU には、階層を作成できる他の OU を含めることもできます。例えば、同じ部門に属するすべてのアカウントを部門 OU にグループ化できます。同様に、セキュリティサービスを実行しているすべてのアカウントをセキュリティ OU にグループ化できます。

サービスコントロースポリシー（SCP）

サービスコントロールポリシー (SCP) は、組織のアクセス許可の管理に使用できる組織ポリシーの一種です。SCP では、組織の IAM ユーザーと IAM ロールで使用可能な最大アクセス許可を一元的に制御できます。
AWS公式でも、SCPは「IAMユーザーやIAMロールに対して利用可能な最大権限を中央で制御するもの」と説明されています。

SCPは、たとえば次のようなときに使います。

• 組織全体で ec2:TerminateInstances を禁止したい
• 特定のAWSリージョン以外の利用を禁止したい
• メンバーアカウントで特定サービスの利用を禁止したい
• 管理者権限を持つIAMロールがいても、組織ルールとして越えられない制限をかけたい

つまり、各アカウントのIAM設定より上位で効く、ガードレールのようなものです。

SCPとIAMポリシーとの違い

混同しやすいですが、役割が違います。

IAMポリシー

• ユーザーやロールに対して
  「何を許可するか」を定義する

SCP

• 組織配下アカウントに対して
  「何を最大限として許すか」を定義する
• 許可はしない
• IAMで許可されていても、SCPで禁止されていれば実行不可

たとえば、IAMポリシーで AdministratorAccess を付けていても、SCPで s3:DeleteBucket を拒否していれば、その削除はできません。AWS公式も、明示的Denyは他のAllowに優先すると案内しています。（参照：AWSドキュメント）

前提条件

SCPを使うには、AWS Organizations で**すべての機能（all features）**を有効化している必要があります。
請求統合だけの簡易モードではSCPは使えません。

書き方

SCPはIAMポリシーにかなり近いJSON構文です。

例として、S3のバケット削除を禁止するイメージです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDeleteBucket",
      "Effect": "Deny",
      "Action": "s3:DeleteBucket",
      "Resource": "*"
    }
  ]
}

このようなSCPをOUやアカウントに付けると、IAMで削除権限を持っていても削除できなくなります。

よくある使い方

1. 利用リージョンの制限

例:

• 東京リージョンのみ許可
• それ以外のリージョンを禁止

2. 危険操作の禁止

例:

• CloudTrail停止禁止
• GuardDuty無効化禁止
• IAMユーザー作成禁止
• KMSキー削除禁止

3. 特定サービスの利用禁止

例:

• 開発OUでは一部高額サービスを禁止
• 本番OUでは実験系サービスを禁止

4. セキュリティ統制

例:

• 組織共通でログ削除や監査停止を禁止

AWS公式もSCPのサンプルを多数公開していて、適用前の十分な検証を強く勧めています。

注意点

1. SCPはAllowを与えるものではない

ここが最重要です。
SCPで許していても、IAM側で許可がなければ操作できません。

2. 広くかけすぎると事故になりやすい

ルートや広いOUにいきなり厳しいDenyを入れると、運用に必要な作業まで止まることがあります。AWS公式も、まず狭い範囲でテストしてから段階的に広げるよう案内しています。

3. Organizations配下全体の継承を意識する必要がある

上位OUのSCPと下位OUのSCPが組み合わさって効くため、
「どこで拒否されているか分かりにくい」ことがあります。評価ロジックの理解が大事です。

4. ルートユーザーでも逃げられない場面がある

メンバーアカウントのルートユーザーにもSCPは影響するため、
「ルートなら何でもできる」はOrganizations配下では通用しない場合があります。

どういうときに導入するとよいか

SCPは特に、

• AWSアカウントを複数持っている
• 開発・検証・本番で統制を分けたい
• セキュリティ事故を組織的に防ぎたい
• 各PJ担当者にアカウント管理を任せつつ、最低限の統制は維持したい

という場合に向いています。

逆に、単一アカウントで小規模に使っている段階では、まずIAM設計を整理したほうが先なことも多いです。