いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！
少し遅くなりましたが、2025.01.16（木）にAWSからアップデートされました複数の AWS アカウントへの同時サインインに関して気になったため、技術検証もかねて記事を執筆したいと思います。
初学者でもサクッと読めるように平易な表現で執筆しておりますので、お気軽に読んでいただければ幸いです。
目次
- アップデート内容
-
技術検証
- その1：IAMユーザで5ユーザマルチセッション
- その2：IAMユーザで6ユーザマルチセッション
- その3：IAM Identity Centerユーザで5ユーザマルチセッション
- オペミスしない運用（案）について
アップデート内容
アップデート情報に関して公式ブログを見てみると以下の通り説明がなされていました。
本日、AWS はマルチセッションのサポートを発表しました。これにより、AWS のお客様は AWS コンソールで複数の AWS アカウントに同時にアクセスできるようになります。AWS のお客様は、1 つのブラウザで最大 5 つのセッションにサインインできます。これは、異なるアカウントまたは同じアカウントのルート、IAM、またはフェデレーションロールの任意の組み合わせにすることができます。
公式ブログ
ざっくり言えば、同じ端末で最大5ユーザまで同じAWSアカウントへログインできるといったニュアンスです。
設定方法として、AWSコンソール>ユーザアカウント>マルチセッションサポートをオンにするを押下するだけで設定可能です。
押下後、ポップアップが表示されるため、マルチセッションサポートをオンにするボタンを押下すれば設定完了です。
公式ドキュメントでも記載されていますが、マルチセッションサポートをオンにするとエイリアスURLが変更されるため、AWSエイリアスURLを別システムで利用している場合はそちらも設定変更が発生します。
https://docs.aws.amazon.com/ja_jp/signin/latest/userguide/how-to-sign-in.html
エイリアスURLの変更の影響か、マルチセッションサポートをオン⇒オフした場合、ログインしているユーザはログアウトしてしまうので、他ユーザが利用していないことを後設定を行ってください。
マルチセッションユーザでログイン時、シドニーリージョン*で選択された状態になっているため、シドニーリージョン以外で作業を行う場合は正しいリージョンへ切り替える必要があります。
技術検証
技術検証用に以下IAMユーザとIAM Identity Centerユーザをあらかじめ作成しました。
なお、全ユーザ同じIAMロールを設定しています。
- IAMユーザ
- testuser0001
- testuser0002
- testuser0003
- testuser0004
- testuser0005
- testuser000A
- IAM Identity Centerユーザ
- testuser0006
- testuser0007
- testuser0008
- testuser0009
- testuser0010
- testuser000B
その1：IAMユーザで5ユーザマルチセッション
ログイン結果は以下の通りでした。
testuser0001から～testuser0005までマルチセッションできていることが確認できました。
アカウントをクリックすると、現在セッションを利用しているユーザへ切り替えることもできます。
その2：IAMユーザで6ユーザマルチセッション
それでは、testuser000Aも追加でログインしてみたいと思います。
セッションを追加をクリックし追加しようとしたところ、セッションの制限に達しましたの画面が表示されたため接続できないことが分かりました。
その3：IAM Identity Centerユーザで5ユーザマルチセッション
IAM Identity Centerでマルチセッションを試みようと試しましたが、違うロールにスイッチしてマルチセッションすることは可能ですが、同じロールを利用してマルチセッションを行うことはサポートしていないようでした。（別の許可セット or AWSアカウントであれば実行可能なようですが)
オペミスしない運用（案）について
マルチセッションについて一通り機能検証を行ってみましたが、個人的な感想として利用前に運用設計をかなり考えないとオペミスを行う可能性があると考えました。
オペミス対策に関しては、先行ブログでも言及しておりました。
そのうえで、私なりにオペミスしない運用（案）に考えてみました。
- その1：ユーザ名にdev or stg or proといった識別子を入れておく
- testuser0001を開発用とする場合、testuser0001-devといった命名規則で設定する
- メリット：ユーザ名だけで用途を識別できる
- デメリット：既存運用している場合、大規模な修正作業が発生する
- その2：Display AWS Account Nameなどの拡張機能を利用する
- 既存アカウント設定を修正せずにユーザの違いをUIで判別可能
- メリット：既存運用の変更が小規模ですむ
- デメリット：
- セキュリティ要件が厳しいユーザの場合、利用できない場合がある
- 公式から提供されているアプリではないためサポート・セキュリティ面の懸念
- その3：利用環境を開発環境に留めておく
- ステージング用、本番用AWSアカウントではマルチセッションを有効化させない
- メリット：マルチセッションサポートの利用を最低限で留められる
- デメリット：開発環境でのオペミスを防ぐことはできない
運用（案）についていろいろ考えてみましたが、ベストプラクティスが出ているわけではないため、実運用で利用するのは待った方が妥当だと個人的に思いました。個人の検証環境で利用するのがベターだと思います。（他クラウドサービスでの利用可否、ベストプラクティスに関しては今後調査していきたいと思います）
参考ブログ
ざっくりですが、マルチセッション機能をいい感じで運用する方法を考えてみました。
最後まで、記事を読んでいただきありがとうございました。