aws-vault で role_arn を変えてもアカウントが切り替わらない原因はセッションキャッシュだった！
はじめに
こんにちは！コンサルティング部のヒスです。
検証（開発）アカウントで作業していて、新しい本番環境アカウントへ切り替えようと AWS config を修正したのに、
本番アカウントに変更したはずなのに依然として検証アカウントで認証されてしまう、という現象に遭遇したことはないでしょうか？
私は最初、これまで使っていたプロファイルの role_arn だけを本番アカウントに書き換えました。
一見問題なさそうですが、実際には意図したアカウントに切り替わっていませんでした。
結論から言うと、原因は aws-vault のセッションキャッシュで、解決策は aws-vault clear の一行でした。
本記事では、この落とし穴がなぜ起きるのか、そしてどう回避できるのかを整理します。
前提：私の AWS config 構成
私は踏み台（ジャンプ）アカウントの IAM ユーザーで MFA 認証し、そのセッションで各環境のアカウントへ assume role する構成を使っています。ベースの認証情報は 1Password（op-desktop バックエンド）から取得し、MFA のワンタイムパスワードも 1Password から取り出しています。
# ベースの認証情報を 1Password から取得するプロファイル
[profile source]
credential_process = aws-vault --op-vault-id <vault-id> --op-desktop-account-id <account-id> --backend op-desktop --prompt terminal export source-vault --duration 1h --format=json
# source をベースに MFA 認証 + assume role するプロファイル
[profile source-vault]
region = ap-northeast-1
source_profile = source
mfa_serial = arn:aws:iam::<踏み台アカウント>:mfa/<user>
mfa_process = op item get "Amazon" --otp
role_arn = arn:aws:iam::<検証環境アカウント>:role/<role>
sourceがベース認証情報の取得元、source-vaultが実際に role を assume するプロファイルです。
Terraform 実行時はAWS_PROFILE=sourceを指定し、sourceのcredential_process経由でsource-vaultのセッションが使われます。
aws-vault と 1Password の連携セットアップ（Mac）については、上記のブログもあわせてご参照ください。
発生した現象
検証環境に入っていた source-vault の role_arn だけを、本番アカウントへ書き換えました。プロファイル名はそのままです。
[profile source-vault]
region = ap-northeast-1
source_profile = source
mfa_serial = arn:aws:iam::<踏み台アカウント>:mfa/<user>
mfa_process = op item get "Amazon" --otp
# role_arn = arn:aws:iam::<検証環境アカウント(3xxxxxx)>:role/<role> ← 既存(検証)
role_arn = arn:aws:iam::<本番環境アカウント(0xxxxxx)>:role/<role> ← 変更(本番)
この状態で Terraform を実行し、どのアカウントに認証されているか確認してみます。
→ 依然として <検証環境アカウント(3xxxxxx)> のまま
config ファイル上は明らかに本番の ARN なのに、実際にはまだ検証アカウントのセッションで接続されていました。
原因：aws-vault は「プロファイル名」単位でセッションをキャッシュする
aws-vault は STS で取得した一時認証情報（セッション）を OS の keychain などにキャッシュします。
このときのキャッシュキーが プロファイル名 基準になっています。
つまり role_arn を変更しても、プロファイル名が source-vault のままであれば、aws-vault は以前の ARN（検証環境アカウント）で取得した一時セッションが有効な間はそのセッションを再利用してしまいます。
そのため、config は本番を指しているのに、実際の認証は検証アカウントのまま、という不一致が発生します。
解決：aws-vault clear
キャッシュされたセッションをクリアすれば、新しい ARN で再認証されます。
aws-vault clear # すべてのキャッシュセッションを削除
aws-vault clear <プロファイル名> # または該当プロファイルだけ
では、既存のプロファイルをそのまま修正するのは一般的か？
ここで一点、触れておきたいことがあります。
「既存プロファイルの ARN だけを変更して使う」やり方は、実務ではよく見かけますが、推奨される方法ではありません。
よく見かける理由は次のようなものです。
- 一人で使うローカル環境なので、手早く ARN だけ変えて少しだけ本番作業をして戻りたい場合
- プロファイルが増えるのが嫌で、「使っているもの一つ」だけを維持したい場合
- SSO よりも IAM role +
source_profile方式を長く使ってきた場合
しかし、同じプロファイルを in-place で修正する方法には落とし穴があります。
| 問題 | 説明 |
|---|---|
| セッションキャッシュの衝突 | 本記事で扱ったその問題。ARN を変えても aws-vault が古いセッションを再利用 → clear が必須 |
| ヒューマンエラーのリスク | 本番の ARN を有効にしたまま、検証だと思い込んでコマンドを実行 → 事故。どのアカウントか名前で区別できない |
| 元に戻すのが手間 | 作業後に再び ARN を元に戻す必要がある。忘れると次の作業が本番で実行されてしまう |
推奨：アカウントごとにプロファイルを分ける
そもそもアカウントごとにプロファイルを分けておけば、上記の問題のほとんどを回避できます。
# 検証環境（source をベースに assume role）
[profile dev]
source_profile = source
mfa_serial = arn:aws:iam::<踏み台アカウント>:mfa/<user>
mfa_process = op item get "Amazon" --otp
role_arn = arn:aws:iam::<検証環境アカウント>:role/<role>
region = ap-northeast-1
# 本番環境（source をベースに assume role）
[profile prod]
source_profile = source
mfa_serial = arn:aws:iam::<踏み台アカウント>:mfa/<user>
mfa_process = op item get "Amazon" --otp
role_arn = arn:aws:iam::<本番環境アカウント>:role/<role>
region = ap-northeast-1
aws sts get-caller-identity --profile dev # 検証
aws sts get-caller-identity --profile prod # 本番
こうすることで：
- キャッシュキーがプロファイル名ごとに分かれるため、
clearしなくてもセッションが混ざりません。 - コマンドに
dev/prodがそのまま表示されるので、今どのアカウントで作業しているか目で確認できます。 - 作業後に ARN を元に戻す必要がありません。
補足：Terraform コードは毎回書き換えない
アカウントを切り替えるたびに .tf 内の provider / backend を直接修正するのも、同じ理由で推奨されません。
人がミスをすると本番に検証用の設定が出てしまったり、その逆が起きたりするからです。
provider の profile や region はコードにハードコーディングせず、変数 / tfvars / backend-config に分離するほうが安全です。
provider "aws" {
profile = var.aws_profile # dev / prod
region = var.region
}
aws-vault exec prod -- terraform plan -var-file=prod.tfvars
まとめ
aws-vault のセッションキャッシュは、知らないとハマりやすいポイントです。
プロファイルを環境ごとに分けておくだけで、今回のような問題はほぼ防げます。
Terraform も同じ考え方で整理しておくと、うっかりミスが減って作業が少し楽になります。
