🏢 オフィスビルの入館システムで例えると超わかりやすい!
AWS CLI = オフィスビルに入るためのシステム
毎日オフィスに入るために、身分証明書や入館カードが必要ですよね。
AWS CLIも同じで、AWSにアクセスするために
認証情報
が必要です。
でも、その認証情報を「どうやって提示するか」には3つの方法があります。
いつ・なぜ・どの方法を使うか
を完璧にマスターしましょう✨
🎯 結論：優先順位を理解しよう!
AWS CLIは以下の順番で認証情報を探します：
1位（最優先）： コマンドラインオプション（--profile, --region など）
2位： 環境変数（AWS_ACCESS_KEY_ID など）
3位： 設定ファイル（~/.aws/credentials, ~/.aws/config）
💡 つまり：
コマンドラインオプションで指定すれば、他の設定は全て無視されます！
これが「一時的な実行」や「他の設定に依存しない実行」に最適な理由です。
1位（最優先）： コマンドラインオプション（--profile, --region など）
2位： 環境変数（AWS_ACCESS_KEY_ID など）
3位： 設定ファイル（~/.aws/credentials, ~/.aws/config）
💡 つまり：
コマンドラインオプションで指定すれば、他の設定は全て無視されます！
これが「一時的な実行」や「他の設定に依存しない実行」に最適な理由です。
環境変数
Environment Variables
🎯 仕組み：
シェル全体に影響する「グローバル設定」。
一度設定すると、そのシェルセッション中は全てのコマンドに適用される。
📝 主な変数：
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN
• AWS_DEFAULT_REGION
優先度: 2位（中間）
シェル全体に影響する「グローバル設定」。
一度設定すると、そのシェルセッション中は全てのコマンドに適用される。
📝 主な変数：
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN
• AWS_DEFAULT_REGION
設定ファイル
Configuration Files
🎯 仕組み：
永続的に保存される「プロファイル」システム。
複数のアカウント/環境を切り替えて使える。
📝 ファイル：
• ~/.aws/credentials（認証情報）
• ~/.aws/config（設定）
• 複数プロファイルの管理が可能
優先度: 3位（最低）
永続的に保存される「プロファイル」システム。
複数のアカウント/環境を切り替えて使える。
📝 ファイル：
• ~/.aws/credentials（認証情報）
• ~/.aws/config（設定）
• 複数プロファイルの管理が可能
コマンドラインオプション
Command Line Options
🎯 仕組み：
実行時に直接指定する「その場限り」の設定。
他の全ての設定をオーバーライドする。
📝 主なオプション：
• --profile
• --region
• --output
• その他のパラメータ
優先度: 1位（最優先）✨
実行時に直接指定する「その場限り」の設定。
他の全ての設定をオーバーライドする。
📝 主なオプション：
• --profile
• --region
• --output
• その他のパラメータ
🏢 オフィスビル入館システムで理解する
環境変数
「全館共通カード」
🏢 シチュエーション：
あなたはオフィスビルで働いています。朝、首から社員証をかけると、その日一日中ずっと身につけています。
💳 どんな感じ？：
• ビル全体で使える共通カード
• 一度かけたら、全てのドアで自動認識
• でも、退社するまで外せない
• 他のカードに切り替えるのが面倒
⚠️ 問題点：
違う部署（プロジェクト）に行くときも同じカードのまま。切り替えが難しい！
あなたはオフィスビルで働いています。朝、首から社員証をかけると、その日一日中ずっと身につけています。
💳 どんな感じ？：
• ビル全体で使える共通カード
• 一度かけたら、全てのドアで自動認識
• でも、退社するまで外せない
• 他のカードに切り替えるのが面倒
⚠️ 問題点：
違う部署（プロジェクト）に行くときも同じカードのまま。切り替えが難しい！
設定ファイル
「カードケース」
🏢 シチュエーション：
あなたの財布には複数の入館カードが入っています。開発部門用、本番環境用、テスト環境用...など。
💳 どんな感じ？：
• 財布に複数のカードを保管
• 「今日は開発用カード」と選べる
• 永続的に保存されている
• でも、複数持っていると混乱することも
⚠️ 問題点：
どのカードが今日使われているか忘れがち。競合の原因に！
あなたの財布には複数の入館カードが入っています。開発部門用、本番環境用、テスト環境用...など。
💳 どんな感じ？：
• 財布に複数のカードを保管
• 「今日は開発用カード」と選べる
• 永続的に保存されている
• でも、複数持っていると混乱することも
⚠️ 問題点：
どのカードが今日使われているか忘れがち。競合の原因に！
コマンドラインオプション
「ゲストパス」
🏢 シチュエーション：
今日だけ特別な会議室に入る必要があります。受付でその都度「ゲストパス」を発行してもらいます。
💳 どんな感じ？：
• その場で手渡される一時パス
• 明確に「今回だけこれ」と指定
• 他のカードは一切関係なし
• 終わったら返却（一時的）
✨ メリット：
他のカードを気にせず、今この瞬間だけの認証！完全に独立！
今日だけ特別な会議室に入る必要があります。受付でその都度「ゲストパス」を発行してもらいます。
💳 どんな感じ？：
• その場で手渡される一時パス
• 明確に「今回だけこれ」と指定
• 他のカードは一切関係なし
• 終わったら返却（一時的）
✨ メリット：
他のカードを気にせず、今この瞬間だけの認証！完全に独立！
🔄 それぞれの動作の流れ
環境変数の流れ
1
シェル起動時に設定
export AWS_ACCESS_KEY_ID=xxx
⬇️
2
シェル全体に影響
全てのコマンドがこの認証情報を使用
全てのコマンドがこの認証情報を使用
⬇️
3
切り替えが面倒
別の認証情報を使うには再設定が必要
別の認証情報を使うには再設定が必要
⬇️
4
シェル終了で消滅
次回起動時は再設定
次回起動時は再設定
設定ファイルの流れ
1
ファイルに永続保存
~/.aws/credentials に複数プロファイル
~/.aws/credentials に複数プロファイル
⬇️
2
デフォルトプロファイル使用
または --profile で明示的に選択
または --profile で明示的に選択
⬇️
3
複数プロファイル混在
競合の可能性あり
競合の可能性あり
⬇️
4
永続的に保存
次回も同じ設定を使用
次回も同じ設定を使用
コマンドラインオプションの流れ
1
実行時に直接指定
aws s3 ls --profile dev
⬇️
2
他の設定を全て無視
環境変数も設定ファイルも関係なし
環境変数も設定ファイルも関係なし
⬇️
3
そのコマンドだけ有効
完全に独立した実行
完全に独立した実行
⬇️
4
実行完了で終了
次のコマンドには影響なし
次のコマンドには影響なし
🏆 AWS CLIが認証情報を探す順番（優先順位）
1
コマンドラインオプション
最優先！
--profile, --region など
他の全てをオーバーライド
--profile, --region など
他の全てをオーバーライド
→
2
環境変数
2番目
AWS_ACCESS_KEY_ID など
コマンドラインがない場合のみ
AWS_ACCESS_KEY_ID など
コマンドラインがない場合のみ
→
3
設定ファイル
最後
~/.aws/credentials
他が何もない場合のみ
~/.aws/credentials
他が何もない場合のみ
💡 重要ポイント：
コマンドラインオプションを使えば、環境変数や設定ファイルの内容を気にせず実行できます！
これが「他の設定に依存しない」理由です。
コマンドラインオプションを使えば、環境変数や設定ファイルの内容を気にせず実行できます！
これが「他の設定に依存しない」理由です。
💻 実際のコード例
1. 環境変数での指定
# シェル全体に影響（Linux/macOS） export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE" export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" export AWS_DEFAULT_REGION="ap-northeast-1" # この後の全てのコマンドがこの認証情報を使う aws s3 ls aws ec2 describe-instances aws dynamodb list-tables # 問題：別のアカウントに切り替えるのが面倒
2. 設定ファイルでの指定
# ~/.aws/credentials ファイル [default] aws_access_key_id = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY [dev] aws_access_key_id = AKIAI44QH8DHBEXAMPLE aws_secret_access_key = je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY [prod] aws_access_key_id = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY # ~/.aws/config ファイル [default] region = ap-northeast-1 output = json [profile dev] region = us-west-2 output = json # 使用例 aws s3 ls # defaultプロファイル使用 aws s3 ls --profile dev # devプロファイル使用
3. コマンドラインオプションでの指定（推奨！）
# プロファイルを明示的に指定（最も安全） aws s3 ls --profile dev --region us-west-2 # リージョンだけ指定 aws ec2 describe-instances --region ap-northeast-1 # 出力形式も指定 aws dynamodb list-tables --profile prod --region us-east-1 --output table # 複数のオプションを組み合わせ aws s3 cp myfile.txt s3://my-bucket/ \ --profile dev \ --region us-west-2 \ --no-verify-ssl # メリット： # - 環境変数の影響を受けない # - 設定ファイルの競合を気にしない # - そのコマンドだけ独立して実行 # - スクリプトに書いても明確で安全
4. 優先順位のデモンストレーション
# 設定状況： # - 環境変数: AWS_DEFAULT_REGION=us-east-1 # - 設定ファイル: region=ap-northeast-1 # ケース1: コマンドラインオプションなし aws ec2 describe-instances # → 環境変数が優先: us-east-1 を使用 # ケース2: コマンドラインオプションあり aws ec2 describe-instances --region eu-west-1 # → コマンドラインが最優先: eu-west-1 を使用 # → 環境変数も設定ファイルも完全に無視される！ # ケース3: プロファイル指定 aws ec2 describe-instances --profile dev # → devプロファイルの設定を使用 # → 環境変数は無視される
📊 詳細比較表
| 項目 | 環境変数 | 設定ファイル | コマンドラインオプション |
|---|---|---|---|
| 優先順位 | 2位（中間） | 3位（最低） | ✅ 1位（最優先） |
| 影響範囲 | ❌ シェル全体 | ⚠️ 永続的 | ✅ そのコマンドのみ |
| 切り替え | ❌ 難しい（再設定必要） | ⚠️ プロファイル指定で可能 | ✅ 簡単（毎回指定） |
| 永続性 | ❌ セッション終了で消滅 | ✅ ファイルに永続保存 | ❌ その実行のみ |
| 複数環境管理 | ❌ 困難 | ✅ プロファイルで簡単 | ✅ 毎回明示的に指定 |
| セキュリティ | ⚠️ プロセスから見える | ✅ ファイルパーミッション管理 | ⚠️ コマンド履歴に残る |
| 一時的な実行 | ❌ 不向き | ❌ 不向き | ✅ 最適！ |
| スクリプト化 | ⚠️ 可能だが非推奨 | ✅ 推奨 | ✅ 最も明確 |
| CI/CD環境 | ✅ よく使われる | ⚠️ 可能だが管理が複雑 | ✅ 明示的で安全 |
| 初心者向け | ❌ 理解が必要 | ✅ おすすめ | ✅ 最も明確 |
💼 どの方法をいつ使う？シナリオ別ガイド
環境変数を使うべきケース
✅ こんな状況なら環境変数：
• CI/CDパイプライン（GitHub Actions, GitLab CI）
• Dockerコンテナ内の実行
• 一時的な開発環境
• スクリプト全体で同じ認証情報
💡 具体例：
「GitHub Actionsでデプロイスクリプトを動かす。全てのコマンドで同じAWSアカウントを使う」
⚠️ 注意：
切り替えが面倒なので、複数環境を扱う場合は不向き
• CI/CDパイプライン（GitHub Actions, GitLab CI）
• Dockerコンテナ内の実行
• 一時的な開発環境
• スクリプト全体で同じ認証情報
💡 具体例：
「GitHub Actionsでデプロイスクリプトを動かす。全てのコマンドで同じAWSアカウントを使う」
⚠️ 注意：
切り替えが面倒なので、複数環境を扱う場合は不向き
設定ファイルを使うべきケース
✅ こんな状況なら設定ファイル：
• 日常的な開発作業
• 複数のAWSアカウント/環境を管理
• チーム全体で統一した設定
• 永続的な設定が必要
💡 具体例：
「開発用、ステージング用、本番用の3つのAWSアカウントを使い分けている」
✨ メリット：
aws configure でGUI的に設定でき、プロファイルで簡単切り替え
• 日常的な開発作業
• 複数のAWSアカウント/環境を管理
• チーム全体で統一した設定
• 永続的な設定が必要
💡 具体例：
「開発用、ステージング用、本番用の3つのAWSアカウントを使い分けている」
✨ メリット：
aws configure でGUI的に設定でき、プロファイルで簡単切り替え
コマンドラインオプションを使うべきケース
✅ こんな状況ならコマンドラインオプション：
• 一時的なテスト実行
• 他の設定に依存したくない
• スクリプト内で明示的に指定
• デバッグ時の確実な実行
💡 具体例：
「普段はdev環境だけど、今回だけprod環境でS3の状態を確認したい」
🎯 最適！：
他の設定を完全に無視できるので、最も確実で安全な方法
• 一時的なテスト実行
• 他の設定に依存したくない
• スクリプト内で明示的に指定
• デバッグ時の確実な実行
💡 具体例：
「普段はdev環境だけど、今回だけprod環境でS3の状態を確認したい」
🎯 最適！：
他の設定を完全に無視できるので、最も確実で安全な方法
🏆
ベストプラクティス：どう組み合わせる？
1. 基本は「設定ファイル」+ 必要に応じて「コマンドラインオプション」：
日常作業は ~/.aws/credentials にプロファイルを設定。
一時的な操作や確実に実行したい時は --profile で明示的に指定。
2. 環境変数は限定的に使う：
• CI/CDパイプライン
• Dockerコンテナ
• 一時的な開発環境
これら以外では基本的に使わない方が安全。
3. スクリプトでは必ず明示的に：
スクリプト内では --profile や --region を必ず指定。
「暗黙の設定」に依存しないことで、予期しないエラーを防ぐ。
4. 本番環境では特に慎重に：
本番環境での操作は、必ず --profile prod のように明示的に指定。
「間違ったアカウントで実行してしまった」を防ぐ。
5. デバッグには AWS_PROFILE も便利：
export AWS_PROFILE=dev とすると、--profile dev と同じ効果。
でも、コマンドラインオプションの方が優先されるので安心。
6. セキュリティのために：
• ~/.aws/credentials のパーミッションは 600 に設定
• 環境変数で認証情報を渡す場合は、ログに残らないよう注意
• 一時的な認証情報（STS）を積極的に活用
7. チーム開発では：
• プロファイル名を統一（dev, staging, prod など）
• README に設定方法を明記
• スクリプトには必ず --profile を記述
日常作業は ~/.aws/credentials にプロファイルを設定。
一時的な操作や確実に実行したい時は --profile で明示的に指定。
2. 環境変数は限定的に使う：
• CI/CDパイプライン
• Dockerコンテナ
• 一時的な開発環境
これら以外では基本的に使わない方が安全。
3. スクリプトでは必ず明示的に：
スクリプト内では --profile や --region を必ず指定。
「暗黙の設定」に依存しないことで、予期しないエラーを防ぐ。
4. 本番環境では特に慎重に：
本番環境での操作は、必ず --profile prod のように明示的に指定。
「間違ったアカウントで実行してしまった」を防ぐ。
5. デバッグには AWS_PROFILE も便利：
export AWS_PROFILE=dev とすると、--profile dev と同じ効果。
でも、コマンドラインオプションの方が優先されるので安心。
6. セキュリティのために：
• ~/.aws/credentials のパーミッションは 600 に設定
• 環境変数で認証情報を渡す場合は、ログに残らないよう注意
• 一時的な認証情報（STS）を積極的に活用
7. チーム開発では：
• プロファイル名を統一（dev, staging, prod など）
• README に設定方法を明記
• スクリプトには必ず --profile を記述
🎓 まとめ
🏢 オフィス入館 = AWS CLI認証
3つの認証方法は、オフィスビルに入る3つの方法と同じ。
どれを使うか
は状況次第ですが、
優先順位
を理解すれば迷わない！
🌍
環境変数
全館共通カード
シェル全体に影響
優先度：2位
📁
設定ファイル
カードケース
複数プロファイル管理
優先度：3位
⚡
コマンドラインオプション
ゲストパス
その場限りで明確
優先度：1位✨
🎯 ゴールデンルール：
日常作業：
設定ファイル（プロファイル管理）
一時的な実行：
コマンドラインオプション（--profile）
CI/CD：
環境変数
迷ったら：
コマンドラインオプションが最も安全！
他の設定を完全に無視できるので、予期しない動作を防げます。
💡 最重要ポイント：
AWS CLIは
1. コマンドラインオプション → 2. 環境変数 → 3. 設定ファイル
の順で認証情報を探します。
コマンドラインオプションを使えば、他の設定に依存せず、
確実に意図した認証情報で実行できます！🎉