AWS CLI & AWS Vault トラブルシューティング | よくあるエラーと解決策まとめ

URLをコピーしました！

はじめに

AWS CLI や AWS Vault は、一度設定してしまえば非常に快適なツールですが、導入初期や久しぶりに使う際、「謎のエラー」 に遭遇してハマることがよくあります。

「急に AccessDenied になった…」
「aws-vault コマンドがうんともすんとも言わない…」
「時刻ズレで署名エラーが出る…」

特に Linux（Ubuntu / WSL）環境では、GPG などのバックエンド設定が絡むため、トラブルシューティングの難易度が少し高めです。

本記事では、AWS CLI および AWS Vault の利用中に遭遇しやすい代表的なエラーと、その具体的な解決策をまとめました。「今まさにエラーが出て困っている」という方は、以下のリストから自分の症状に近いものを探してみてください。

この記事でわかること

Vault のネスト: error: exec: aws-vault sessions should be nested with care
GPG/Pass 関連: gpg: decryption failed や Inappropriate ioctl for device
時刻ズレ: SignatureDoesNotMatch（WSL ユーザー必見）
権限・MFA: AccessDenied が発生する意外な原因
デバッグ: どうしても解決しない時の切り分けフロー

AWS Vault 関連のエラーと対策

AWS Vault はセキュリティが高い反面、Linux 環境（Ubuntu / WSL）ではバックエンド（Pass/GPG）との連携でつまずくことが多いツールです。ここでは代表的な3つのパターンを紹介します。

Case

“sessions should be nested with care”（ネストエラー）

エラーメッセージ

aws-vault: error: exec: aws-vault sessions should be nested with care, unset $AWS_VAULT to force

原因

このエラーは、aws-vault exec で起動したシェル（サブシェル）の中で、さらに aws-vault exec を実行しようとした場合 に発生します。

「金庫の中でさらに金庫を開こうとしている」状態と考えると分かりやすいと思います。

対策

基本的には、今いるサブシェルから抜けるのが正解です。

# 現在のサブシェルを終了する
exit

もし、サブシェルから抜けてもこのエラーが出る（環境変数が残ってしまっている）場合は、以下のコマンドで強制的に変数を解除することで解決します。

# 環境変数を解除する（$マークは不要です）
unset AWS_VAULT

Case

“GPG key” や “pass” 関連のエラー（Linux/Ubuntu）

エラーメッセージ

gpg: decryption failed: No secret key
# または
Inappropriate ioctl for device

原因

これらは Ubuntu や WSL 環境で非常に多いエラーです。 AWS Vault が認証情報を読み書きしようとした際、バックエンドの GPG がパスフレーズ入力画面（pinentry）を正しく表示できない ことで発生します。

対策

~/.bashrc や ~/.zshrc に以下の環境変数設定を追加し、GPG が現在のターミナル（TTY）を認識できるようにします。

export GPG_TTY=$(tty)

設定後は source ~/.bashrc で反映させてください。なお、そもそも pass や gpg の初期設定が完了していない場合は、以下の記事を参考にバックエンドの構築を行ってください。

プロファイルの有効期限切れ

症状

長時間かかるスクリプトや作業の途中で、急に認証エラー（AccessDenied）が発生する。

原因

AWS Vault が発行する一時的な認証情報（STS トークン）には有効期限があります（デフォルトは通常 1 時間）これを超えると、セッション中であっても権限を失います。

対策

長時間作業することが分かっている場合は、--duration オプションで有効期限を延ばして実行します。

# 12時間有効なセッションを開始する例
aws-vault exec my-profile --duration 12h -- aws s3 ls

ただし、AWS 側の IAM ロールやユーザー設定で「最大セッション期間」が制限されている場合は、そちらの上限が優先されます。

AWS CLI 共通のエラーと対策

AWS Vault を使っていても、そうでなくても発生する AWS CLI の一般的なエラーです。

もし aws コマンドが見つからない場合や、バージョンが古くてオプションが使えない場合は、インストール自体がうまくいっていない可能性があります。以下の記事でインストール手順を確認し、入れ直してみてください。

“SignatureDoesNotMatch”（時刻ズレ）

エラーメッセージ

An error occurred (SignatureDoesNotMatch) when calling the ListBuckets operation: Signature expired: 20231025T012345Z is now earlier than 20231025T012845Z (20231025T013345Z - 5 min.)

原因

AWS の API リクエストには、セキュリティ対策として現在時刻が含まれています。クライアント（あなたのPC）の時刻が、AWS サーバー側の時刻と 5分以上 ずれていると、リクエストは不正とみなされて拒否されます。

特に WSL（Windows Subsystem for Linux）や仮想マシン（VM）環境では、ホスト PC がスリープから復帰した際に Linux 側の時刻が遅れたままになる現象が頻発します。

対策

以下のコマンドを実行して、システム時刻を正しく同期させてください。

# 方法1: ハードウェアクロックと同期させる（WSLで手軽な方法）
sudo hwclock -s

# 方法2: NTP サーバーと同期させる（ntpdate が必要）
# sudo apt install ntpdate  <-- 未インストールの場合
sudo ntpdate pool.ntp.org

Case

“AccessDenied”（権限不足）

エラーメッセージ

An error occurred (AccessDenied) when calling the PutObject operation: Access Denied

原因

「権限がない」という単純なエラーですが、原因はいくつか考えられます。

IAM ポリシー不足: その操作（例: s3:PutObject）が許可されていない。
MFA 未認証: ポリシーで MFA 認証が必須なのに MFA トークンなしでアクセスしている。
別人で実行している: 意図しないプロファイルや、以前の認証情報が残っている。

対策

闇雲に IAM ポリシーをいじる前に、まず 「今、自分は誰として認識されているか？」 を確認するのが鉄則です。以下のコマンドを実行してください。

aws sts get-caller-identity

出力例

{
    "UserId": "AROA1234567890EXAMPLE:botocore-session-123",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/MyRole/botocore-session-123"
}

この Arn の部分を見て、

期待している IAM ロール/ユーザーになっているか？
スイッチロールに失敗して、元のユーザーのままになっていないか？ を確認してください。もし期待と異なる場合は、プロファイル指定 (--profile) や AWS Vault の実行方法を見直しましょう。

それでも解決しない時のデバッグ技

ここまで紹介したパターンに当てはまらない場合、「詳細なログ（デバッグ情報）」 を見ることで、何が起きているかを突き止めることができます。

最強のオプション –debug の使い方

AWS CLI には、通信内容をすべて表示する隠しオプションのような --debug があります。これをコマンドの末尾に付けて実行すると、「どんなリクエストを送って、AWS からどんなエラーが返ってきたか（または返ってこなかったか）」 がわかります。

実行例

aws s3 ls --debug

出力例（抜粋）

2023-10-25 10:00:00,123 - MainThread - botocore.endpoint - DEBUG - Making request for OperationModel(name=ListBuckets) with params: ...
2023-10-25 10:00:00,456 - MainThread - botocore.parsers - DEBUG - Response: {'Error': {'Code': 'InvalidAccessKeyId', 'Message': 'The AWS Access Key Id you provided does not exist in our records.'}, ...}

このログを見れば、「通信はできているがキーが無効（InvalidAccessKeyId）」なのか、「そもそも通信がタイムアウトしている（ConnectTimeout）」なのかが一目瞭然です。

まとめ

本記事では、AWS CLI と AWS Vault の利用時によく遭遇するエラーとその解決策を紹介しました。

まずは、AWS Vault の問題なのか、CLI の権限設定の問題なのかを特定しましょう。
Linux 環境（WSL含む）では、GPG や時刻ズレといった「OS 側の設定」が原因であることが多いです。
エラーメッセージだけで悩まず、デバッグログを見るのが解決への近道です。

以上、最後までお読みいただきありがとうございました。

図解即戦力　Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書　［改訂2版］ [ 小笠原種高 ]

created by Rinker

¥2,200 (2026/03/05 10:29:56時点楽天市場調べ-詳細)

おすすめ書籍

よかったらシェアしてね！

URLをコピーしました！

この記事を書いた人

とも

インフラ（クラウド/NW/仮想化）から Web 開発まで、技術領域を横断して活動するエンジニア💻 コンシューマー向けエンタメ事業での新規開発・運営経験を活かし、実戦的な技術ノウハウを発信中

[ Certs ] CCIE Lifetime Emeritus / VCAP-DCA ✒️ [ Life ] 技術書・ビジネス書愛好家📖 / 小・中学校で卓球コーチ👟