はじめに
どーも!shihopowerです!
今日はIAMサービスロールについてお話します。
AWS SAP(Solutions Architect Professional)対策をしていると、IAMサービスロールに関する模擬問題にはじめて出くわしました。
ここで「IAMサービスロールって、要するにIAMロールと同じようなものでしょ?」とスルーしてしまうのは簡単です。でも、SAPの問題がわざわざ「サービスロール」という言葉を使い分けている以上、そこには理解しておくべき差分があるはず。
IAMロールをはじめとする他の概念との違いを明確にして、なぜ「サービスロール」という概念がわざわざ存在するのかを腹落ちさせることは、設計力を底上げするうえで大事だと思ったので、記事に書き起こします。
同じくSAP対策中の方や、IAM周りの用語がふんわりしている方の参考になれば嬉しいです。
目次
- 問題の要件をざっくり把握する
- ありがちな"惜しい"アプローチではなぜ不十分なのか理解する
- IAMサービスロールとは何か理解する
- IAMサービスロールとIAMロールの差分を理解する
- IAMサービスロールの必要性を理解する
1. 問題の要件をざっくり把握する
まずは出会った問題のシチュエーションをざっくり整理します。シナリオはこんな感じです。
- ある会社が、単一のAWSアカウントで複数のワークロードを運用している
- 新しいセキュリティポリシーにより、エンジニアのリソース作成には次の制約が課せられた
- 承認されたリソース種別しか作成できないこと
- リソース作成は AWS CloudFormation経由でしか行えないこと
- ソリューションアーキテクトは、エンジニアが使うIAMロールに対してこの制約を強制する仕組みを設計する必要がある
要件は2つあるのがポイントです。
- ① 作れるリソースの種類を絞る
- ② 作り方(CloudFormation経由)を絞る
この「AND条件」をどう成立させるか、が問題の本質になります。
2. ありがちな"惜しい"アプローチではなぜ不十分なのか理解する
この手の問題には、いかにも正解っぽく見える"惜しい"選択肢が混ざっています。今回もそうでした。
具体的には、次のようなアプローチです。
エンジニアのIAMロールに対して、「承認されたリソースを作る権限」と「CloudFormationを使う権限」の両方を付与するIAMポリシーを設定する。あわせて、承認されたリソースだけを含むCloudFormationテンプレートを用意する。
承認されたリソースに絞っているし、CloudFormationも使えるようにしている。一見、要件を満たしているように見えます。
でも、これだと「迂回路」が残ります
このアプローチでは、エンジニアのIAMロール自体に承認されたリソースを直接プロビジョニングする権限が残ったままになっています。
つまりエンジニアは、次の2通りの方法でリソースを作れてしまいます。
- ✅ CloudFormation経由でリソースを作る(要件OK)
- ❌ AWS CLI / SDK / マネジメントコンソールから
ec2:RunInstancesやs3:CreateBucketを直接叩く(要件NG)
要件②の「CloudFormation経由で行わなければならない」は、CloudFormationを"使える"ようにするだけでは満たせないんですね。CloudFormation以外の経路を権限レベルで塞ぐ必要があります。
これがこのアプローチの落とし穴です。
「CloudFormationを使えるようにすること」と「CloudFormationを使うことを強制すること」は別物。
そして、この強制を実現するための鍵が、次に説明するIAMサービスロールです。
3. IAMサービスロールとは何か理解する
ここでAWS公式ドキュメント(IAMロール - AWS Identity and Access Management ユーザーガイド)の定義を引用します。
サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受けるIAMロールです。
ざっくり言うと、**「AWSサービス自身が引き受けるためのIAMロール」**です。
たとえばCloudFormationの場合、スタック作成時に「実際にEC2インスタンスを起動する」「S3バケットを作る」というAPIコールを行うのは、エンジニア本人ではありません。CloudFormationサービス自身がサービスロールを引き受けて、そのロールの権限でリソースを作成します。
イメージとしてはこんな感じです。
エンジニア
│ ① 「このテンプレートでスタック作って」
▼
CloudFormation
│ ② サービスロールをAssumeRole
▼
サービスロール(EC2やS3の作成権限を持つ)
│ ③ 実際にリソースを作成
▼
EC2 / S3 / etc.
エンジニアは直接EC2を作っているのではなく、CloudFormationに作業を依頼しているだけ。実際の手は動かしていません。
4. IAMサービスロールとIAMロールの差分を理解する
「サービスロールもIAMロールの一種でしょ?」というのは正しいです。AWS公式でも、サービスロールは"IAMロールの一種"と定義されています。
ただし、誰が引き受けるかで性質がはっきり分かれます。
| 観点 | 一般的なIAMロール | サービスロール |
|---|---|---|
| 引き受ける主体 | IAMユーザー、フェデレーティッドユーザー、他アカウントのプリンシパルなど | AWSサービス自身(ec2.amazonaws.com、cloudformation.amazonaws.comなど) |
| 信頼ポリシーのPrincipal |
AWS(アカウントID、ユーザー、ロール) |
Service(サービスプリンシパル) |
| 典型的なユースケース | クロスアカウントアクセス、人間のスイッチロール、フェデレーション | サービスがユーザーに代わってリソースを操作する |
| 管理者による編集 | 可能 | 可能(※サービスにリンクされたロールは編集不可) |
さらにややこしいのが「サービスにリンクされたロール(Service-Linked Role)」ですが、これはサービスロールの特殊な一種で、サービス自身が所有・管理し、管理者は権限を編集できないものです。今回の話の主役ではないので、ここでは「サービスロールの厳格版がある」くらいの理解でOKです。
5. IAMサービスロールの必要性を理解する 〜冒頭の問題に戻る〜
ここまでくると、章2のアプローチがなぜダメで、正解はどうあるべきかが見えてきます。
要件②「CloudFormation経由を強制する」を実現するには、権限を2つの主体に分離するのが正解です。
| 主体 | 与える権限 |
|---|---|
| エンジニアのIAMロール |
cloudformation:*(スタック操作)と iam:PassRole(CloudFormationにサービスロールを渡す権限)のみ。リソースを直接作る権限(ec2:*、s3:* など)は与えない
|
| CloudFormationサービスロール | 承認されたリソースをプロビジョニングするための実権限(ec2:RunInstances など) |
この設計のキモは、エンジニア自身はリソースを直接作る権限を持っていないということです。
- エンジニアがCLIで
aws ec2 run-instancesを叩いても → ❌ 権限がなくて失敗 - エンジニアがCloudFormationにテンプレートを渡してスタックを作る → ✅ CloudFormationがサービスロールを引き受けて成功
これでようやく要件②「CloudFormation経由でしかリソースを作れない」が、仕組み(権限)として強制されます。
つまりIAMサービスロールは、
- 「人が直接操作する権限」と「サービスが代理で操作する権限」を分離する
ための仕組みであり、今回のようなガードレール設計には欠かせない概念なんです。
おわりに
最初は「IAMロールと何が違うの?」と思っていたIAMサービスロールですが、
- 誰が引き受けるか(人 vs サービス)が違う
- それを使うことで**「サービス経由でしか操作できない」というガードレールを設計できる**
という2点を押さえると、SAPの問題文の意図がぐっと読み取りやすくなりました。
似たような"用語の混同"はSAPの他の領域でもありがちなので、引っかかったらスルーせずに一度立ち止まって整理するのが、結局は近道だなと改めて感じています。
ここまで読んでくださってありがとうございました!