AWS にログインした後に Switch Role を使う
本記事では、AWS Console の Switch Role（クロスアカウントでのロール切替）を解説し、Trust Relationship と Policy の設定方法を紹介します。
AWS Cloud Console へのログイン方法はいくつかあります。
root アカウントでログインする方法（非推奨）、
IAM User の認証情報でログインする方法、
SAML（例: Azure AD）連携でログインする方法、
AWS SSO でログインする方法です。
その中でも特に実務でよく使われる方法が 1 つあります。
まず 1 つの AWS アカウントにログインし、
その後 Switch Role を使って
別の AWS アカウントに切り替える方法です。
この記事では、この方式の考え方と
設定手順を紹介します。
図で見るログイン方式の違い
代表的な流れを簡略化すると、次のようになります。
1
2
3
4
5
6
7
8
9
10
11
12
[Root / IAM User / SSO でログイン]
|
v
[ソースアカウントの Console に入る]
|
(Switch Role)
|
v
[ターゲットアカウントの Role に切替]
|
v
[ターゲット資源を操作]
結果だけを見ると、どの方式も「Console に入る」点は同じです。
ただし、権限設計の観点では意味が大きく異なります。
| 方式 | 利用する主体 | 長期利用の推奨 | 典型的な利用シーン |
|---|---|---|---|
| Root アカウント | Account Root User | いいえ | 初期設定、まれな緊急対応 |
| IAM User | 固定のユーザー資格情報 | 組織方針による | 小規模チーム、SSO 未導入 |
| SAML/SSO | 企業アイデンティティ基盤 | はい | 中〜大規模組織、集中管理 |
| Switch Role | ソースにログイン後ロール切替 | はい | クロスアカウント運用、本番分離 |
なぜ必要なのか
多くのチームでは、本番環境を専用アカウントとして分離します。
普段は一般作業用アカウントで業務を行い、
本番対応が必要なときだけ Switch Role で入ります。
考え方としては、本番前の踏み台に近いです。
この構成には少なくとも 3 つの利点があります。
- 高権限が長期間露出するリスクを下げられる
- 日常利用の主体と本番責務を明確に分離できる
- CloudTrail 監査で「誰がいつどのロールに切替えたか」を追いやすい
実務では、Switch 可能な Role を明確な境界として扱えます。 先に本人確認、次にロール許可、その後に機密資源へアクセス、という流れです。
設定手順
ここでは最も一般的なクロスアカウント構成を例にします。
- ユーザーがソースアカウント（A）にログイン
- ターゲットアカウント（B）で、A から Assume 可能な Role を作成
- Console で Switch Role を使って B に切替
手順 1: ターゲット側で IAM Role を作成
ターゲットアカウント（B）で Role を作る際、
先に Permission Policy を定義します。
例として、CloudWatch Logs の参照と EC2 の参照のみ許可する Policy:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:GetLogEvents",
"ec2:DescribeInstances"
],
"Resource": "*"
}
]
}
手順 2: Trust Relationship を設定
次に、ターゲット側 Role の信頼ポリシーで、
ソースアカウント（A）の特定 IAM User/Role を許可します。
よくある例（ソース側 ops-admin Role を許可）:
1
2
3
4
5
6
7
8
9
10
11
12
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<source_account_id>:role/ops-admin"
},
"Action": "sts:AssumeRole"
}
]
}
より厳格にする場合は、MFA などの条件を追加できます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<source_account_id>:role/ops-admin"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
手順 3: ソース側にも AssumeRole 権限を付与
ソースアカウント（A）のユーザー/ロールには、
ターゲット Role に対する sts:AssumeRole 権限が必要です。
これがないと切替できません。
1
2
3
4
5
6
7
8
9
10
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::<target_account_id>:role/<target_role_name>"
}
]
}
手順 4: Console で Switch Role を実行
右上のアカウントメニューから Switch role を選び、
次を入力します。
- Account ID（ターゲットアカウント）
- Role name（ターゲットロール名）
- Display name（識別しやすい表示名）
成功すると Console 右上の主体表示が切り替わり、
同じブラウザセッション内で別ロール権限を使っている状態になります。
よくあるエラーと確認ポイント
1) AccessDenied: not authorized to perform sts:AssumeRole
多くは、ソース側に sts:AssumeRole 権限がない、
またはターゲット側 Trust Relationship の Principal が誤っているケースです。
2) Role は見えるのに切替できない
Account ID と Role name を再確認してください。
また、ターゲット側の Role なのか（ソース側同名 Role ではないか）も確認します。
3) 切替成功後に資源が見えない
ターゲット Role の Permission Policy が不足している、
あるいは参照 Region が違うことが多いです。
ログイン方式の使い分け
簡易的な判断基準は次の通りです。
- 学習用途や一時操作: IAM User（短期なら可）
- チームの本番運用: SSO + Switch Role
- 高機密アカウント（本番など）: 常時権限なし、必要時のみ Switch Role
実務で安定しやすい構成は、
SSO で本人認証を行い、
その後 Switch Role でアカウントと責務ごとに切替える形です。
まとめ
Switch Role の価値は、単なるクロスアカウントの利便性だけではありません。
本質は、主体と権限を分離できる点にあります。
これにより、高リスク環境へのアクセスをより制御しやすくなります。
一言でまとめると:
普段は低権限で作業し、必要な時だけ対象ロールへ短時間切替える。
これが AWS マルチアカウント運用で非常に重要な実践です。
参考資料
- AWS IAM User Guide - Switching to a role (console): https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html
- AWS IAM User Guide - Tutorial: Delegate access across AWS accounts using IAM roles: https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
- AWS IAM JSON policy elements reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html