【AWS CLI】認証情報の優先順位

はじめに

AWS CLIを利用する際、「設定したはずの認証情報が使われない」「意図しないIAMロールで実行されてしまった」という経験はありませんか？

AWS CLIは、複数の場所から認証情報を読み込むことができ、それらには明確な優先順位が存在します。この優先順位を理解していないと、思わぬ設定の落とし穴にはまってしまうことがあります。

この記事では、AWS CLIがどの認証情報をどの順番で探しに行くのかを、具体例を交えながら徹底的に解説します。

対象読者

• AWS CLIを使い始めた方
• 複数のAWSアカウントやIAMロールを切り替えて作業する方
• CI/CDパイプラインなどでAWS CLIの認証を設定する方

結論：認証情報の優先順位

AWS CLIは以下の順序で認証情報を探し、最初に見つかったものを使用します。

1. コマンドラインオプション (--profile, --region など)
2. 環境変数 (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY など)
3. （Web Identity連携）OIDCの環境変数 (AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE)
4. 共有認証情報ファイル (~/.aws/credentials)
5. CLI設定ファイル (~/.aws/config) ※IAMロールの指定など
6. コンテナ認証情報 (ECSタスクロールなど)
7. インスタンスプロファイル (EC2インスタンスプロファイルなど)

この順番が非常に重要です。例えば、環境変数を設定していると、~/.aws/credentialsに記述した内容は無視されます。

それでは、各項目を詳しく見ていきましょう。

1. コマンドラインオプション

最も優先度が高いのが、コマンド実行時に直接指定するオプションです。

--profileオプションを使えば、~/.aws/credentialsや~/.aws/configで設定した特定のプロファイルを明示的に使用できます。

# my-profileという名前のプロファイルを利用する
aws s3 ls --profile my-profile

この方法は、一時的に別のプロファイルを使いたい場合に非常に便利です。

2. 環境変数

次に優先されるのが環境変数です。以下の環境変数が設定されている場合、CLIはこれらを利用します。

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN (一時的な認証情報の場合)

設定例:

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# この状態で実行すると、上記で設定したキーが使われる
aws s3 ls

# 使い終わったら必ずunsetすること！
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY

注意点: 環境変数は非常に強力ですが、ターミナルのセッションが続く限り有効です。使い終わったらunsetコマンドで必ず解除する癖をつけましょう。CI/CD環境など、一時的な認証情報を扱うのに適しています。

4. 共有認証情報ファイル (~/.aws/credentials)

aws configureコマンドで設定される、おなじみのファイルです。複数のプロファイルを定義することができます。

ファイル例: ~/.aws/credentials

[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[user1]
aws_access_key_id = AKIAI44QH8DHBEXAMPLE
aws_secret_access_key = je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

コマンドラインオプションや環境変数の指定がなければ、このファイルの[default]プロファイルが使われます。

5. CLI設定ファイル (~/.aws/config)

このファイルは、リージョンや出力形式のデフォルト設定、そして**IAMロールの引き受け（AssumeRole）**設定などを記述します。

ファイル例: ~/.aws/config

[default]
region = ap-northeast-1
output = json

[profile developer]
role_arn = arn:aws:iam::123456789012:role/developer-role
source_profile = default
region = ap-northeast-1

上記の例では、aws s3 ls --profile developerと実行すると、defaultプロファイルの認証情報を使ってdeveloper-roleというIAMロールを引き受けます。

6. コンテナ認証情報

Amazon ECSのタスクやEKSのPodで実行されているコンテナ内でAWS CLIを実行した場合、タスク/Podに割り当てられたIAMロール（タスクロール）の認証情報が自動的に使われます。

7. インスタンスプロファイル

EC2インスタンス内でAWS CLIを実行した場合、そのインスタンスにアタッチされたIAMロール（インスタンスプロファイル）の認証情報が自動的に使われます。

これは、EC2上でアプリケーションを動かす際の最も安全で推奨される方法です。

現在どの認証情報が使われているか確認する方法

「結局今、どの認証情報でCLIは動いているんだ？」と分からなくなったときは、sts get-caller-identityコマンドが便利です。

aws sts get-caller-identity

実行結果例:

{
    "UserId": "AIDAJQABLZS4A3QDU576Q",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/cli-user"
}

この結果を見れば、現在有効になっているIAMユーザーやロールのARNが分かり、意図した認証情報が使えているかを確認できます。

よくある落とし穴

• 環境変数の消し忘れ: ターミナルで一時的に環境変数を設定した後、unsetし忘れてしまい、~/.aws/credentialsの設定が全く効かなくなるケース。
• credentialsとconfigの混同: ~/.aws/credentialsにrole_arnを書いても機能しません。ロール設定は~/.aws/configに書く必要があります。
• defaultプロファイルの意図しない上書き: aws configureを引数なしで実行すると[default]プロファイルが上書きされるため、注意が必要です。特定のプロファイルを設定したい場合はaws configure --profile <profilename>を使いましょう。

まとめ

AWS CLIの認証情報の優先順位は、以下の通りです。

1. コマンドラインオプション (最優先)
2. 環境変数
3. 共有認証情報ファイル (credentials)
4. CLI設定ファイル (config)
5. コンテナ認証情報
6. インスタンスプロファイル (最後の砦)

この順番をしっかり覚えておけば、認証にまつわるトラブルの多くは解決できます。
困ったときにはaws sts get-caller-identityで現状を確認する癖をつけると、よりスムーズに開発を進められるでしょう。