AWS Organizations の SCP と RCP はどっちを使う？ - 2 つのガードレールを図で整理する

Posted at 2026-10-15

はじめに

AWS Organizations には、組織全体に「ここまでしかできない」という上限（ガードレール）をかけるポリシーが 2 種類あります。

昔からある SCP（サービスコントロールポリシー） と、
2024 年 11 月に追加された RCP（リソースコントロールポリシー） です。

名前も書き方も似ているので、「どっちを使えばいいの？」「両方いるの？」 と迷いやすいかと思います。
この記事では、違い・使い分け・導入のベストプラクティス を図で整理します。

たとえるなら、
SCP は社員証に書かれた「入ってよい場所」のリスト、
RCP は会社の金庫に貼られた「開けてよい人」のリスト です。

SCP と RCP のページから、違いを表にまとめると次のとおりです。

項目	SCP	RCP
上限をかける対象	組織内の IAM ユーザー・ロール（ルートユーザー含む）	組織内のリソース
対応サービス	ほぼすべて	S3・KMS・SQS・Secrets Manager・STS など 60 以上の一部サービス
書ける `Effect`	`Allow` と `Deny`	`Deny` だけ
`Principal`	書かない	`"*"` 固定（相手は `Condition` で絞る）
既定で付くポリシー	`FullAWSAccess`（外せる）	`RCPFullAWSAccess`（外せない）

ドキュメントの「General use cases for SCPs and RCPs」の表を、アクセスする人とされるリソースの組み合わせで並べ直すと次のようになります。

ドキュメントでは 「SCP と RCP は独立したコントロールで、両方使うことで人とリソースの両側にデータ境界を作れる」 とされています。
どちらか一方を選ぶのではなく、止めたいアクセスの主語で使い分けて組み合わせます。

「どちらでも書ける」例として、暗号化なしの S3 アップロードの禁止 です。
取引先など組織外の人もアップロードするなら、RCP にすれば相手が誰でも暗号化を強制できます。

用途別には次のとおりです。

やりたいこと	使うポリシー
使ってよいリージョン・サービスを絞る、ルートユーザーの操作を禁止する	SCP
組織からの離脱、CloudTrail の停止などを禁止する	SCP
自分のリソースへのアクセスに条件（TLS バージョン・暗号化など）を必ず付ける	RCP

IAM ユーザーガイドの Establish permissions guardrails using data perimeters では、データ境界 の 6 つの目標と、使うポリシーを整理しています。

囲いたいもの	目標	使うもの	主な条件キー
人	自分のリソースには信頼できる人だけがアクセスできる	RCP	`aws:PrincipalOrgID`
人	自分のネットワークからは信頼できる人だけ	VPC エンドポイントポリシー	`aws:PrincipalOrgID`
リソース	自分の人は信頼できるリソースだけにアクセスできる	SCP	`aws:ResourceOrgID`
リソース	自分のネットワークからは信頼できるリソースだけ	VPC エンドポイントポリシー	`aws:ResourceOrgID`
ネットワーク	自分の人は想定したネットワークからだけアクセスできる	SCP	`aws:SourceIp`、`aws:SourceVpc`
ネットワーク	自分のリソースは想定したネットワークからだけアクセスされる	RCP	`aws:SourceIp`、`aws:SourceVpc`

Deny を間違えると組織中のアカウントで一斉に仕事が止まる ので、ドキュメントはどちらも段階的に広げることを強く勧めています。

段階	SCP	RCP
影響を調べる	IAM のサービス最終アクセス時間で、実際に使っているサービスを確認	IAM Access Analyzer の外部アクセスの検出結果で、組織外に共有中のリソースを確認
書き方	既定の `FullAWSAccess` は残し、Deny を足していく（外すと全操作が止まる）	`RCPFullAWSAccess` の上に Deny を足していく（これしかできない）