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