猫でもわかるAWSのスイッチロール ~IAMも一緒にざっくり理解する~
はじめに
AI事業本部/生成AIインテグレーション部/ソリューションチームの竹口です。
みなさん、スイッチロール使ってますか?
使い始めた頃、あるいはこれから使おうとしている頃。はたまた今この瞬間、なんとなく使っているみなさん。「スイッチロールって結局なんなの?」「なんのためにやってるの?」「なにが嬉しいのこれ?」
そう感じたことはありませんか?
私自身よく分かっていなかったので、猫でもわかるようにIAMの基本的な仕組みから噛み砕いて説明していきます。
やっと本題
概要
スイッチロールとは、Userはそのままに、Roleを一時的に切り替える操作 です。
とは言っても、UserとかRoleとか用語だけ並べられてもよく分からないものです。それぞれ整理します。
そもそもIAMとは
IAMとは、AWS Identity and Access Managementの略です。頭文字をとって「IAM」ですね。
公式のドキュメントでは以下のように説明されています。
AWS Identity and Access Management (IAM) は、AWS リソースへのアクセスを安全に管理するためのウェブサービスです。IAM を使用すると、ユーザーがアクセスできる AWS のリソースを制御するアクセス許可を管理できます。IAM を使用して、誰を認証 (サインイン) し、誰にリソースの使用を認可する (アクセス許可を付与する) かを制御します。IAM は、AWS アカウントの認証と認可を制御するために必要なインフラストラクチャを提供します。
要するにAWSで 「誰がなにをできるのか」 を管理できるサービスです。
例として、
弊社のマスコットくらにゃんに「EC2を触れる」という権限だけを与えます。
そして弊社の二次元社員である二代目めそ子さんに「S3を触れる」という権限だけを与えます。
- このとき、くらにゃんはEC2 に、めそ子さんはS3 に 触る ことができます。
- しかし、くらにゃんはS3 に、めそ子さんはEC2 には 触ることができません。

これがIAMによるアクセス管理になります。
IAMのPolicy/User/Role
IAMは主に三つの要素で構成されます。
非常にわかりやすく解説してくださっている記事があるのでご紹介しておきます。
ざっくりまとめると、
- Policyは、なにを できる/できない のかを定義するもの
- Roleは、Policyを紐付けて、なにをできる/できないかをまとめた 「役割」 を定義するもの
- Userは、PolicyまたはRoleを紐付けて、できる/できない 「人」 を定義するもの
です。

「そもそもIAMとは」の項に記載した図で例えると、
- 「⚪︎⚪︎触っていいよ」と許可を出しているのが Policy または Role
- くらにゃんとめそ子さんが User
になります。
Roleの補足
Roleを紐付ける対象はUserだけではありません。
AWSサービスやウェブアイデンティティ(AWS以外のIDプロバイダー(Google・Facebook等)でログインしているユーザー)などにも紐付けが可能であり、Roleの作成時にその用途を設定します。

スイッチロール
改めて、スイッチロールとは、Userはそのままに、Roleを一時的に切り替える操作 です。
Userとしてログインしている状態はそのままに、Role(役割)だけが切り替わります。そしてRoleには「なにをできる/できない」がまとめられているため、Roleが切り替われば、そのAWS環境でできることが変わります。
例えば、くらにゃんに「EC2を触れる」というRole が与えられていたとします。
- このとき、くらにゃんは EC2 に 触る ことができます。
- しかし、くらにゃんは S3 には 触ることができません。

ここで スイッチロール を行い、くらにゃんのRoleが 「S3を触れる」というRole に切り替わりました。
- このとき、くらにゃんは S3 に 触る ことができます。
- しかし、くらにゃんは EC2 には 触ることができません。

スイッチロールを行うことで、くらにゃんがAWS環境で行える操作を役割別に切り替えることができました。
別のAWSアカウントへスイッチロール
そして、このスイッチロールは 別のAWSアカウントに対しても 行うことができます。
例えば、AWSアカウント1にくらにゃん という User がいたとします。
くらにゃんには AWSアカウント1 の 「EC2に触れる」というRole が与えられています。
- このとき、くらにゃんは AWSアカウント1のEC2 に 触る ことができます。
- しかし、くらにゃんは AWSアカウント2のEC2 に 触ることができません。

ここで スイッチロール を行い、くらにゃんのRoleが AWSアカウント2 の 「EC2に触れる」というRole に切り替わりました。
- このとき、くらにゃんは AWSアカウント2のEC2 に 触る ことができます。
- しかし、くらにゃんは AWSアカウント1のEC2 に 触ることができません。

スイッチロールを行うことで、AWSアカウント1のUserであるくらにゃんが、AWSアカウント2のRoleに切り替えることができました。
なにが嬉しいのか?
スイッチロールは 複数AWSアカウントの運用管理を楽にする機能 です。
こちらもわかりやすく解説してくださっている記事があるのでご紹介しておきます。
もしスイッチロールを使わずに複数AWSアカウントを運用しようとすれば、それぞれの環境でUserを用意して各アカウントIDとユーザー名とパスワードを管理する必要があります。
これはアカウントの数が少なければ大きな負担にはなりませんが、アカウントが増えればその分だけ管理する情報も膨れ上がり、運用が大変になってしまいます。

ですがスイッチロールを使うことで、管理が必要なのは1つのユーザー名とパスワードのみになります。
他のAWS環境では必要なRoleを用意するだけで、くらにゃんが各AWS環境で行える操作を管理できるのです。

さいごに
スイッチロールの具体的な実装手順については、こちらもわかりやすく解説してくださっている記事があるのでご紹介しておきます。
IAMについてはスイッチロールの理解に必要なPolicy/User/Roleに絞って記事にしましたが、本来はもっと奥深く、AWSにおけるセキュリティの中核をなすサービスです。深掘りすればするほど沼にハマりますが、いつかその沼も記事にまとめたいですね。
この記事がどなたかの参考になれば幸いです。
参考
私のようなジュニアレベルのエンジニアでも理解できる形でわかりやすくまとめてくださった、偉大なる先達様方へのリンクです。







