はじめに
本ドキュメントは「AWS ロール」についての調査結果を分かりやすくまとめたものです。AWS上での権限管理に悩む人向けに、基本概念から実務でよく使う操作方法までを丁寧に解説します。
目的
読み終えると、IAMロールの役割や種類、作成手順、他アカウントやユーザーへの切り替え（スイッチロール）、サービスリンクロールの見分け方が理解できます。具体例を交え、設定時に迷わない実践的な知識を提供します。
想定読者
クラウド初心者、システム管理者、開発者、権限設計を学びたい方が対象です。基本的なAWS用語に不安がある方でも読み進められるよう配慮しました。
本稿の構成
全7章で段階的に解説します。第2章は「IAMロールとは」、第3章は「ロールの種類と使い分け」、第4章は「ロール作成の流れ」、第5章は「スイッチロール」、第6章は「スイッチロールのメリット」、第7章は「サービスリンクロールの見分け方」です。
読み方のポイント
まずは全体をざっと読み、必要な章を詳しく確認してください。操作手順は実際のコンソールやCLIで試すと理解が深まります。
AWS IAMロールとは
概要
AWS IAMロールは、ユーザーやサービスに一時的なアクセス権限を与える仕組みです。固定のログイン資格情報を使わずに、必要な権限だけを一時的に委譲できます。複数のポリシーを結び付けて、細かく権限を制御します。
特徴
- 一時的な認証情報を発行し、長期間の資格情報を持たせません。
- ユーザー、EC2インスタンス、Lambdaなどのサービスに割り当てられます。
- 別アカウントや外部IDに権限を委譲できます。
使い方の例
- EC2インスタンスがS3にファイルを置くとき、インスタンスにロールを付与します。鍵をコードに書かずに済み安全です。
- 別アカウントの運用チームが本番アカウントにアクセスする場合、ロールを使って最小権限で作業できます。
注意点
- ロール自体は権限の定義であり、使う主体に割り当てる必要があります。誤ったポリシーを付けると過剰な権限になります。
- 監査とローテーション（ポリシーの見直し）を定期的に行ってください。
ロールの種類と使い分け
種類の概要
IAMのロールは用途ごとに大きく3種類に分かれます。
- クロスアカウント（汎用）ロール：他アカウントや外部ユーザーが一時的に権限を借りるためのロールです。トラストポリシーでどのプリンシパルが引き受けられるかを指定します。
- サービスロール：LambdaやEC2などAWSのサービスがユーザーに代わって操作するときに使います。サービスを信頼するトラスト設定と、必要な権限を付与するポリシーで構成します。
- サービスリンクロール：あるサービス専用に作られ、そのサービスが管理・使用する特別なロールです。名前は「AWSServiceRoleFor…」の形が多く、ユーザー側での編集をできない場合があります。
使い分けの指針
- 他アカウントへアクセスを許可したいときはクロスアカウントロールを作ります。たとえば運用チームが別アカウントのS3を操作する場合です。
- Lambda関数やGlueジョブがS3やDynamoDBへアクセスするならサービスロールを割り当てます。サービス実行のために必要最低限の権限だけを与えてください。
- サービスが自動で作成するロールや、サービス固有の統合が必要な場合はサービスリンクロールを使います。サービス側の動作に密接に結び付くため、基本的に変更は避けます。
具体例と実務上の注意点
- EC2：インスタンスプロファイル（サービスロールの一種）を使い、SSMやS3へアクセスさせます。
- Lambda：関数ごとにロールを作り、最小権限でAPIやS3を呼べるよう設定します。
- Glue：データカタログやS3へアクセスするためにサービスロールを指定します。Glueはしばしばサービスリンクロールを作成します。
実務上は「最小権限」と「明確なトラスト設定」を優先してください。ロールの目的が変わったら新しいロールを作り、既存ロールの乱用を避けると運用が安定します。
ロール作成の流れ
手順（概要）
- IAMダッシュボードで「Roles」→「Create role」を選択します。
- 信頼されたエンティティのタイプを選びます（例：AWSサービス、別アカウント、Web ID、SAML）。この設定で誰がそのロールを引き受けられるかを決めます。
- ポリシーを選択します。AWS管理ポリシーやカスタムポリシーを付与できます。
- ロール名や説明、タグを入力します。
- 内容を確認して「Create role」で作成します。
具体例：EC2からS3に読み取りアクセスを与える場合
- 信頼されたエンティティ：AWSサービス → EC2を選択
- ポリシー：AmazonS3ReadOnlyAccess（AWS管理ポリシー）をアタッチ
- ロール名：ec2-s3-readonly（わかりやすい名前を付ける）
- 作成後はEC2インスタンスにロールを割り当てると、そのインスタンス上のアプリがS3を読み取れます。
注意点と推奨
- 最小権限の原則を守り、必要以上の権限は与えないでください。
- 信頼ポリシー（誰がassumeできるか）を確認してください。誤設定すると意図しないアクセスを許してしまいます。
- 管理ポリシーは手軽ですが、用途に応じてカスタムポリシーで細かく制御すると安全です。
- タグや説明を付けて後から管理しやすくしてください。
- 作成後は必ず動作確認（ロールを使った操作で期待どおりアクセスできるか）を行ってください。
スイッチロール（Switch Role）
概要
スイッチロールは、別のAWSアカウントや別の役割（ロール）に一時的に切り替えて操作する機能です。普段のログインを変えずに、必要な権限だけ借りて作業できます。例：自分のアカウントから別アカウントの管理作業をする場面です。
切り替えの仕組み
切り替え先のロールは「信頼ポリシー」であなたのアカウントを許可します。実際には、現在の認証情報で一時的な認証情報を取得し、その権限で操作します。
ロール作成時の設定（ポイント）
- ソースアカウントIDの入力：どのアカウントから切り替えを許可するか指定します。
- ポリシー選択：切り替え後の権限を決めます（例：読み取り専用や管理者）。
- ロール名設定：分かりやすい名前を付けます。例：「CrossAccount-Admin」
コンソールでの切り替え手順（簡易）
- AWSコンソール右上のアカウントメニューから「Switch Role」を選びます。
- アカウントIDとロール名を入力し保存します。
- 登録したロールを選ぶと画面が切り替わり、指定の権限で操作できます。
使いどころ（具体例）
- 複数アカウント運用で中央管理者が設定変更する。
- 開発者が本番環境を読み取り専用で確認する。
注意点
長時間の放置や不要な権限付与は避けてください。名前や説明を丁寧に付け、誰がどの権限を持つか分かるように管理します。
スイッチロールのメリット
1. セキュリティが向上します
長期的なアクセスキーを共有する必要がなくなります。代わりに一時的な認証情報でアクセスするため、漏洩リスクが低くなります。例えば開発者が別アカウントに入る際、キーを渡さずブラウザ上で切り替えるだけで済みます。
2. 権限管理が簡単になります
必要最小限の権限をロールに割り当てて切り替える方式は、ユーザーごとに細かくキーを管理するよりも分かりやすいです。業務ごとにロールを作れば、誰が何をできるかを整理しやすくなります。
3. 監査がしやすくなります
ロールでのアクセスはログに残りやすく、誰がどのロールでいつ操作したかを追跡できます。監査やトラブル対応で原因を突き止めやすくなります。
4. 運用面の利便性
ブラウザでの切替や短時間の権限付与により、一時的な作業や外部メンバー対応が楽になります。結果として運用負荷を減らせます。
サービスリンクロールの見分け方
基本ポイント
サービスリンクロールは、ARN（Amazon Resource Name）のパス部分に「/aws-service-role/」が含まれていることで判別できます。名前からAWSサービスが管理しているロールだとわかります。例えば、ロードバランサー用のロールは次のようになります。
arn:aws:iam::123456789012:role/aws-service-role/elasticloadbalancing.amazonaws.com/AWSServiceRoleForElasticLoadBalancing
マネジメントコンソールでの確認
- IAMコンソールにアクセスし、左メニューで「ロール」を選びます。
- ロール一覧で検索ボックスに「aws-service-role」と入力すると絞り込めます。
- ロールの詳細画面では「信頼関係（Assume role policy）」にサービス名（例: elasticloadbalancing.amazonaws.com）が表示され、管理元がAWSである旨がわかります。編集ボタンが無効になっている項目があります。
CLIでの確認例
簡単な方法は一覧を取得して文字列検索することです。
aws iam list-roles --output text | grep "/aws-service-role/"
より正確にはjqで絞り込めます。
aws iam list-roles | jq -r '.Roles[] | select(.Path|contains("/aws-service-role/")) | .RoleName + " " + .Arn'
信頼ポリシーの特徴
信頼ポリシーにはServiceプリンシパルがあり、サービス名が明記されます。例: “Service”: “elasticloadbalancing.amazonaws.com”。この設定によりAWSサービスがそのロールを引き受けます。
編集制限と注意点
コンソールではサービスリンクロールの多くの部分が編集できません。名前やパスも変更しないでください。ロールを削除するとサービスの機能に影響が出る場合がありますので注意が必要です。
