AWSの複数アカウントに同時ログインする｜5つまで並べる手順

AWSの複数アカウントにログインしようとして、片方に入った瞬間にもう片方から追い出される経験をした人は多い。開発用と本番用、自社と受託先、請求を見るための親アカウント。必要なのは同時に見ることなのに、ブラウザは1つのセッションしか持ってくれなかった。この前提は変わっており、いまは1つのブラウザで複数のアカウントを並べて開けるようになっている。有効にする手順と、有効にしたことで変わる点を順に整理する。

複数のアカウントを持つ理由は、たいてい後から増える。最初は1つで始めても、本番と開発を分ける方針が決まり、請求をまとめる親アカウントが立ち、監査用の読み取り専用のアカウントが足される。受託の仕事をしていれば、取引先から発行されたアカウントも並ぶ。数が増えるほど、切り替えの手数そのものより、いまどのアカウントの画面を見ているのか分からなくなる時間が問題になる。

1つのブラウザで5つまで入れる

AWSマネジメントコンソールには、複数の認証情報で同時にサインインする仕組みが用意されている。公式のドキュメントには上限が明記されている。

You can sign in to up to five different identities simultaneously in a single web browser in the AWS Management Console. These can be any combination of root, IAM, or federated roles in different accounts or in the same account. 出典: docs.aws.amazon.com

上限は5で、組み合わせは自由になる。ルートユーザー、IAMユーザー、フェデレーションしたロールのどれでもよく、別のアカウントでも同じアカウントの中の別のロールでも並べられる。サインインした認証情報それぞれが、新しいタブでコンソールを開く形になる。

この機能が案内されたのは現地時間の2025年1月で、それまでは1つのブラウザに1つのセッションという前提だった。

ブログエントリのタイトル通りですが、現地時間 2025年1月16日の発表で、AWS マネジメントコンソールで同時に複数の AWS アカウントへログインできるようになったとのアナウンスがありました。 出典: blog.serverworks.co.jp

注意したいのは、既定で有効になっているわけではないという点になる。使う側が明示的に切り替える必要があり、しかもその設定はブラウザごとに持たれる。職場のChromeで有効にしても、自宅のFirefoxやSafariでは改めて有効にすることになる。

上限の数え方も押さえておくとよい。5という数はブラウザ単位で、タブの数ではない。同じアカウントのコンソールをタブ2つで開いても、消費するのは1つ分になる。逆に、同じアカウントの中で違うロールに入っていれば、それは別の認証情報として数えられる。ロールの切り替えを多用している環境では、思っていたより早く上限に届くことがある。

マルチセッションを有効にする手順

操作の場所は2つある。1つはコンソールの右上、アカウント名のメニューの中にある切り替えで、もう1つはサインインの入口のページになる。どちらから入っても結果は同じになる。

有効にしたあとに、2つ目以降のアカウントを足す流れはこうなる。

• まずいつも通りにコンソールへサインインする
• 画面上部のナビゲーションバーで、自分のアカウント名を選ぶ
• セッションを追加する項目を選び、サインインへ進む
• 新しいタブが開くので、そこで2つ目の認証情報を入れる
• タブごとに別のアカウントのコンソールが読み込まれる

シングルサインオンを使っている環境では、入口が1つ増える。IAM Identity Centerのアクセスポータル、あるいは社内のシングルサインオンのポータルで追加のロールにサインインしておくと、コンソール側のアカウント名のメニューに、選べるセッションとして並ぶ。ロールを行き来する運用をしている場合は、こちらのほうが手数が少ない。

やめたいときも同じ場所から戻せる。サインインのページで無効にする操作を選ぶか、ブラウザのCookieを消せば元の状態に戻る。試してから決められるので、まず開発用のアカウントだけで動きを見るという進め方が取りやすい。

手順を踏むときに迷いやすいのは、2つ目の認証情報をどこに入れるかという点になる。新しく開いたタブの中でサインインするので、既に開いている1つ目のタブは触らない。1つ目のタブで一度ログアウトしてから入り直すと、せっかく足したセッションが消えてしまう。足す操作と入れ替える操作は別物だと考えておくと間違えにくい。

ルートユーザーを並べる場合は、別の注意が要る。ルートユーザーは操作できる範囲が広いため、日常の作業用のタブと同じ並びに置いておくと事故の確率が上がる。必要なときだけサインインし、用が済んだらそのタブを閉じる運用のほうが安全になる。

URLが変わることで起きること

有効にすると、コンソールのURLの形が変わる。アカウントIDとランダムな文字列を含むサブドメインが付く形になり、どのタブがどのアカウントのものかがアドレスから判別できるようになる。

これは便利な変更だが、副作用が1つある。以前のURLで保存していたブックマークと、社内の手順書やチケットに貼られているコンソールへのリンクが、そのままでは意図した場所を開かなくなる。公式のドキュメントでも、ブックマークとコンソールのリンクを更新するよう案内されている。

実務では次の順番で当たると手戻りが少ない。自分のブラウザのブックマークを直す。次に、チームで共有している手順書のリンクを直す。最後に、監視やアラートの通知文に埋め込まれているコンソールへのリンクを確認する。3つ目は忘れやすく、障害の最中に押したリンクが違うアカウントを開くという形で表に出る。

Cookieの持ち方も変わる。アカウントIDを含む名前のCookieがアカウントごとに増える構造になっていて、これが同時サインインを支えている。裏を返せば、Cookieを消せばすべてのセッションが一度に消えることになる。ブラウザの掃除を習慣にしている人は、その直後に全アカウントから落ちることを覚えておくとよい。

どのタブがどのアカウントかを見分ける手も併せて用意しておくとよい。コンソールの右上にはアカウント名とIDが出ているが、タブを何枚も並べているとタブの見出しだけでは判別できない。リージョンや表示名をアカウントごとに変えておく、タブの並び順を固定する、といった工夫で確認の手数が減る。

チームで使う場合は、有効にするかどうかを個人の判断に任せないほうがよい。有効にした人と有効にしていない人でURLの形が違うため、貼り合ったリンクが相手の環境では開かないという食い違いが起きる。開発の窓口になっているチャンネルで先に方針を決めて、手順書のリンクも同じ形にそろえておくと、後からの直しが1回で済む。

有効にできない場面での分け方

会社の方針でブラウザの設定が管理されていて、この機能を使えない場合がある。ロールの切り替えだけで足りていて、わざわざ有効にしたくない場合もある。そのときに使われてきたやり方は3つある。

1つ目は、ブラウザのプロファイルを分けるやり方になる。Chromeはこれを標準で持っている。

プロファイルを使用すると、Chrome 上の情報全体（ブックマーク、履歴、パスワードなど）を、プロファイルごとに分離できます。 出典: support.google.com

アカウントごとにプロファイルを作り、色を変えておけば、どの窓が本番のものかが目で分かる。事故を防ぐ効果はここが一番大きい。

2つ目は、ブラウザ自体を分けるやり方になる。開発用はChrome、本番用はFirefoxという形だ。確実に分かれるが、拡張機能やブックマークを二重に管理することになる。

3つ目は、シークレットウィンドウを使うやり方になる。一時的に別のアカウントを見るだけなら手早いが、窓を閉じれば消えるので、日常の作業には向かない。

どれを選んでも、分かれる単位はブラウザのプロファイルであってタブではない。ここが理解できると、タブをいくら整えても解決しない理由が分かる。

AWSだけの問題ではない

同じ構造は他のサービスでも起きている。仕事用と個人用のGmail、2社分のSlack、取引先ごとのNotion、複数のテナントを持つ管理画面。どれもログイン状態がCookieに入り、Cookieがブラウザのプロファイルに属しているという同じ仕組みの上にある。AWSは上限5の同時サインインを用意したが、こうした仕組みを自前で持っているサービスは多くない。

そこで必要になるのは、サービスごとに置き場所を決めてしまう考え方になる。アプリを一覧に並べ、それぞれが自分のセッションを持ち、クリックすれば必ずそのアカウントが開く形だ。窓を増やすのではなく、窓の中を区切る発想で、名前を付けた集まりとして束ねる方法はワークスペースに整理してある。どのWebサービスがこの形で扱えるかは使えるアプリで確認できる。

AWS以外の管理画面を同じ日に行き来している人は、その数を一度書き出してみるとよい。クラウドの管理画面が2つ、決済の管理画面が1つ、解析の管理画面が2つ、社内のチャットが2つ。1つのブラウザに全部を押し込んでいると、タブは30個を超えていることが多く、探す時間のほうが操作の時間より長くなる。ここまで来ると、個々のサービスが同時サインインに対応しているかどうかとは別の問題になっている。

事故を防ぐ配置を先に決める

複数アカウントを扱うときに怖いのは、切り替えの手数ではなく、本番のアカウントで開発用のつもりの操作をしてしまうことになる。ここを減らす手は決まっている。

• アカウントごとに窓か色を固定し、位置も変えない
• 本番のアカウントは同じ場所からしか開かない
• 請求のように見るだけのアカウントは、操作するアカウントと離して置く
• 作業が終わったら、本番のタブは閉じる

アプリごとに独立したワークスペースを持たせる道具を使うと、この配置がそのまま道具側の設定になる。左の一覧に並ぶ位置が変わらないため、手が場所を覚える。似た分類の製品には考え方の違いがあり、代表的なものとの比較はRamboxとの比較やWaveboxとの比較に書いてある。何ができるようになるかはできることに、費用の目安は料金にまとめてある。

まず今日できることは2つある。コンソールでマルチセッションを有効にして、手元のアカウントを並べてみること。そして、ブックマークと手順書のリンクを新しいURLに直しておくことだ。この2つを先に済ませておくと、どの道具を足すかという判断は落ち着いて決められる。