AWS CLI のアクセスキー設定はプロジェクトごとに共有される？影響範囲と安全な分け方

背景

普段自分のノートパソコンでチーム開発を行っており、その際にAWSを用いた開発も行っている。今回はそれとは別で新しく登場したChatGPTのcodexの性能や使い心地を確かめるためにポートフォリオページを作成。性能比較などに関してはまた別の記事に書く予定。その際に、複数のプロジェクトで AWS SAM を使い始めたときに、
「aws configure で設定したアクセスキーって他のプロジェクトにも影響してしまうのでは？」
と結構初歩的なことで躓いてしまい、不安になったので調べた結果を備忘録としてここに残します。

プロジェクトA：Windows (C:\workspace\...)
プロジェクトB：Linux（WSL 上）

それぞれで SAM を利用しています。

結論

アクセスキーは IAM ユーザー単位で発行される
→ 「プロジェクト単位」ではなく「IAMユーザー単位」で同じキーを使うことになる。

⬆ここは理解してた

影響範囲を決めるのは AWS CLI のプロファイル設定
→ aws configure の default プロファイルを上書きすると、全プロジェクトでその設定が有効になる。

⬆ ここ注意

Windows と Linux (WSL) の .aws/credentials は別管理
→ 通常は相互に影響しない。
→ ただし明示的にシンボリックリンクで共有している場合は例外。

▶samconfig.tomlにプロファイル欄を追加して、別のプロジェクトのLambdaにデプロイしないように注意！！

安全な運用方法

1. プロファイルを分けて設定する

# プロジェクトA (Windows 側)
aws configure --profile projA

# プロジェクトB (Linux 側)
aws configure --profile projB

~/.aws/credentials に [projA] と [projB] が保存される。

2. コマンドで明示的に指定

aws s3 ls --profile projA
sam deploy --profile projA

3. 環境変数で固定

# bash/zsh (Linux)
export AWS_PROFILE=projB

# PowerShell (Windows)
$env:AWS_PROFILE = "projA"

4. samconfig.toml に書く

samconfigに記述することでsam build && sam deploy時にミスってしまうのを防止する

[default.deploy.parameters]
stack_name = "my-stack"
region     = "ap-northeast-1"
profile    = "projA"   # ← ここで固定
capabilities = "CAPABILITY_IAM"

確認コマンド

aws sts get-caller-identity --profile projA
aws configure list

まとめ

・aws configure の default を上書きすると全プロジェクトに影響する。

・プロジェクトごとにプロファイルを分ける運用がおすすめ。

・Windows と Linux の .aws は別なので基本的に干渉しない。

これで安心して SAM を複数プロジェクトで使えます。ここに書いてあること当たり前なんですけどね、自分の経験が足りず、まだまだ未熟なことがわかりました
(´；ω；｀)