AWSにおけるアクセス制御はIAM（API操作レベル）とSecurity Group（ネットワーク通信レベル）の2レイヤーで構成される。 アクセス先のサービスによってどちらが効くかが異なる。 それぞれの役割の違いと、Terraformで一括管理する際の共通設計パターンを解説する。
ページ構成
- AWSにおける2つのアクセス制御レイヤー
- IAMとSecurity Groupの違い
- 共通する設計パターン：箱の一括作成 ＋ リソース側での詳細追加
- 独立した2レイヤーであることの意味
- 実装パターンへの展開
- まとめ
1. AWSにおける2つのアクセス制御レイヤー
AWSでリソース間のアクセスを制御する仕組みは、大きく2つのレイヤーに分かれる。
- IAM（Identity and Access Management）: API操作レベルの認可。「誰が何をできるか」を制御する
- Security Group: ネットワーク通信レベルのフィルタリング。「誰がどこに接続できるか」を制御する
どちらのレイヤーが効くかは、アクセス先のAWSサービスによって異なる。 S3やDynamoDBのようなリージョナルサービスへのアクセスはIAMで制御される。 RDSやElastiCacheのようなVPC内に配置されるサービスへのアクセスはSecurity Groupで制御される。 一部のケース（RDS IAM認証など）では両方が関与するが、これは限定的である。
よくある混同
「IAMで許可すればアクセスできる」「Security Groupを開ければ通信できる」と単純に考えてしまうケースがある。 しかし実際には、この2つは制御する対象が異なる。
- Security Groupはネットワークパケットの到達を制御する。ポートが閉じていれば通信は届かない
- IAMはAWS APIリクエストの認可を制御する。権限がなければAPI呼び出しは拒否される
たとえばECSタスクがRDSに接続する場合、一般的なパスワード認証であればSecurity Groupの通信許可だけで接続できる。 一方、ECSタスクがS3にファイルをアップロードする場合は、IAMポリシーの許可だけで操作できる（Security Groupは関与しない）。
この2つを混同すると、「Security Groupを開けたのにS3にアクセスできない」「IAMポリシーを付けたのにRDSに接続できない」といった切り分けの混乱が生じる。
2. IAMとSecurity Groupの違い
制御レイヤーの比較
| 観点 | IAM | Security Group |
|---|---|---|
| 制御対象 | API操作（誰が何をできるか） | ネットワーク通信（誰がどこに接続できるか） |
| 評価タイミング | APIリクエスト時 | パケット到達時 |
| 適用対象 | IAMプリンシパル（ロール、ユーザー） | ENI（ネットワークインターフェース） |
| 許可の粒度 | Action + Resource（API操作 + 対象リソースARN） | Port + Protocol + Source（ポート + プロトコル + 接続元） |
| ステートフル性 | なし（リクエストごとに評価） | あり（戻りのトラフィックは自動許可） |
| デフォルト動作 | 暗黙的にDeny | インバウンド: 全Deny、アウトバウンド: 全Allow |
適用される場面の違い
| 場面 | IAMが関与 | Security Groupが関与 |
|---|---|---|
| ECSタスクがS3にファイルをアップロード | ✅ s3:PutObject 権限 | ❌ S3はVPCエンドポイント or インターネット経由 |
| ECSタスクがRDSに接続（パスワード認証） | ❌ パスワード認証ではIAM不要 | ✅ TCP 3306の通信許可 |
| LambdaがSecrets Managerから値を取得 | ✅ secretsmanager:GetSecretValue 権限 | ❌（VPC外Lambda）/ ✅（VPC内Lambda） |
| ALBがECSタスクにリクエストを転送 | ❌ ALBはIAM評価なし | ✅ ALB SGからECS SGへの通信許可 |
| CloudFrontがALBにリクエストを転送 | ❌ | ✅ CloudFront Managed Prefix ListからALB SGへの通信許可 |
| ECSタスクがRDSに接続（IAM認証） | ✅ rds-db:connect 権限 | ✅ TCP 3306の通信許可 |
多くの場面ではどちらか一方が主たる制御レイヤーとなる。 両方が同時に評価されるケース（RDS IAM認証等）は存在するが、限定的である。
3. 共通する設計パターン：箱の一括作成 ＋ リソース側での詳細追加
IAMとSecurity Groupは制御レイヤーが異なるが、Terraformで管理する際の設計パターンは共通化できる。
パターンの構造
IAMでの適用
| 段階 | 内容 | 例 |
|---|---|---|
| 一括管理 | ロール作成 ＋ AWSマネージドポリシーのアタッチ | AmazonECSTaskExecutionRolePolicy |
| 一括管理 | カスタムポリシー（resource = ["*"]）のアタッチ | logs:CreateLogGroup on * |
| リソース側で追加 | インラインポリシーで特定ARNへのアクセス許可 | s3:GetObject on arn:aws:s3:::my-bucket/* |
Security Groupでの適用
| 段階 | 内容 | 例 |
|---|---|---|
| 一括管理 | SG作成 ＋ 汎用ルール定義 | ALBの443受信、全Egress許可 |
| リソース側で追加 | Security Group Ruleで接続元SGを許可 | ECS SGからRDS SGへの3306許可 |
なぜこのパターンが有効か
- 一覧性: 一括管理モジュールを見れば、環境内の全ロール / 全SGが把握できる
- 可読性: リソースのTerraformを見れば、そのリソースに「誰がアクセスできるか」「どこから通信できるか」が完結する
- ライフサイクルの一致: リソース削除時に、そのリソース固有の権限 / ルールも自然に削除対象になる
- 上限の回避: IAMではマネージドポリシーの上限（デフォルト10）を超えてインラインポリシーで詳細設定が可能
4. 独立した2レイヤーであることの意味
多くの場面ではどちらか一方が効く
実際の構成では、IAMとSecurity Groupの両方が同時に評価される場面は限定的である。
| 場面 | 効くレイヤー |
|---|---|
| ECSタスクがS3にアクセス | IAMのみ |
| ECSタスクがRDSに接続（パスワード認証） | Security Groupのみ |
| ALBがECSタスクにリクエストを転送 | Security Groupのみ |
| LambdaがDynamoDBに書き込み | IAMのみ |
| ECSタスクがRDSに接続（IAM認証） | 両方 |
RDS IAM認証のように両方が同時に必要なケースは存在するが、一般的なパスワード認証のDB接続ではIAMは関与しない。 多くの場面では、IAMかSecurity Groupのどちらか一方が主たる制御レイヤーとなる。
それでも2つを区別して管理する理由
2つのレイヤーが独立していることは、トラブルシューティングと監査の観点で意味がある。
- 障害切り分け: 「ネットワーク的に到達できるか」と「API操作が許可されているか」を独立して検証できる。接続エラーの原因がSecurity Groupなのかポリシーなのかを切り分けやすい
- 監査対応: 「このリソースにネットワーク的に到達可能なリソースはどれか」と「このロールが操作可能なリソースはどれか」を別々に回答できる
- 設計の明確さ: 「通信経路の設計」と「権限の設計」を別の関心事として扱うことで、それぞれの変更が互いに影響しない
5. 実装パターンへの展開
本テーマの具体的な実装パターンは、以下の個別ページで詳述する。
- IAM一括管理 — ロール・ポリシーの集約管理、マネージドポリシーとインラインポリシーの使い分け、AWSクォータを踏まえた設計
- Security Group一括管理 — SGの集約管理、Security Group ID参照による通信許可、リソース別の通信許可パターン
6. まとめ
| 観点 | IAM | Security Group |
|---|---|---|
| 何を制御するか | API操作の認可 | ネットワーク通信の到達性 |
| 一括管理で作るもの | ロール ＋ 汎用ポリシー | SG ＋ 汎用ルール |
| リソース側で追加するもの | インラインポリシー（特定ARNへの許可） | Security Group Rule（特定SGからの許可） |
| 設計の共通思想 | 「箱の一括作成」＋「リソース側での詳細追加」 | 同左 |
AWSのアクセス制御は、IAMとSecurity Groupの2レイヤーで構成される。 アクセス先のサービスによってどちらが効くかが異なるため、この2つを混同せず、それぞれの役割を理解した上で、共通の設計パターンで管理することが、可読性と保守性の高いインフラ構成につながる。