Terraformエラーの修正: プロバイダー "aws" の有効な認証情報ソースが見つかりません

エラーの内容

Error: No valid credential sources found for provider "aws".

Please see https://registry.terraform.io/providers/hashicorp/aws/latest/docs#authentication
for more information about providing credentials.

With the provider configuration at ...

Terraformが認識しているすべての認証情報ソースを検索しましたが、見つかりませんでした。これは通常、新しいマシン上、シークレットが設定されていないCI/CDパイプライン内、またはAWSプロファイルを切り替えた後に環境変数の更新を忘れた場合に発生します。

根本原因

AWSプロバイダーは固定された順序で認証情報を確認します：

プロバイダーブロックにハードコードされた静的認証情報
環境変数（AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY）
共有認証情報ファイル（~/.aws/credentials）
AWS設定ファイル（~/.aws/config）
EC2インスタンスプロファイル / ECSタスクロール / EKS Podアイデンティティ

5つすべてが該当しない場合にこのエラーが発生します。いずれか1つを設定することで解決できます。

修正方法：複数のアプローチ

オプション1 — 環境変数を設定する（最も手早い方法）

最も素早く問題を解決する方法です。シェルで認証情報をエクスポートしてからTerraformを実行します：

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_DEFAULT_REGION="us-east-1"

Windows（PowerShell）の場合：

$env:AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
$env:AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
$env:AWS_DEFAULT_REGION="us-east-1"

terraform planを再実行すれば完了です。

オプション2 — AWS CLIプロファイルを設定する

すでにAWS CLIがインストールされている場合は、名前付きプロファイルを設定します：

aws configure --profile my-profile

環境変数でTerraformにプロファイルを指定します：

export AWS_PROFILE=my-profile

または、プロバイダーブロックに直接指定することもできます：

provider "aws" {
  region  = "us-east-1"
  profile = "my-profile"
}

オプション3 — 認証情報ファイルを使用する

~/.aws/credentialsが存在し、[default]セクションが含まれているか確認します：

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

~/.aws/configにリージョンが設定されているかも確認します：

[default]
region = us-east-1

新しいワークステーションのセットアップ後に、どちらかのファイルが欠けていることはよくあるミスです。

オプション4 — ロールを引き受ける（CI/CDで一般的）

多くのパイプラインでは、長期間有効なキーの代わりにIAMロールを使用します。プロバイダーブロックでロールの引き受けを設定します：

provider "aws" {
  region = "us-east-1"

  assume_role {
    role_arn     = "arn:aws:iam::123456789012:role/TerraformRole"
    session_name = "TerraformSession"
  }
}

注意点として、assume-roleを実行するベースとなる認証情報はどこかに存在する必要があります — 環境変数またはインスタンスプロファイルのどちらでも機能します。

オプション5 — EC2/ECS/EKSインスタンスプロファイル

AWSコンピュートリソース上でTerraformを実行していますか？インスタンスまたはタスクにIAMロールをアタッチします。認証情報ファイルは不要です — SDKがメタデータサービスから短期間有効なトークンを自動的に取得します。

メタデータサービスが応答するか確認します：

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

ロール名が返ってきた場合、Terraformは次の実行時にそれを使用します。

オプション6 — GitHub Actions / CI の例

キーをリポジトリのシークレット（Settings → Secrets → Actions）として保存し、ワークフローのステップで環境変数として注入します：

- name: Terraform Plan
  env:
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    AWS_DEFAULT_REGION: us-east-1
  run: terraform plan

修正の確認

Terraformを実行する前に、AWSが有効な認証情報を認識しているか確認します：

# アクティブな認証情報を確認
aws sts get-caller-identity

成功した場合のレスポンスは次のようになります：

{
    "UserId": "AIDAIOSFODNN7EXAMPLE",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/terraform-user"
}

次にTerraformを実行します：

terraform init
terraform plan

認証情報エラーの代わりにリソースの差分が表示されれば、問題は解決しています。

ヒント

**定期的にキーをローテーションしてください。**静的な長期有効キーは、本番環境でこのエラーが発生する最大の原因です — 誰かがキーをローテーションしてCIの更新を忘れることがよくあります。aws sso loginやロールの引き受けを通じて短期間有効な認証情報に切り替えることで、この問題を完全に回避できます。
**昨日は動いていたのに今日は壊れている？**IAMアクセスキーがローテーションまたは無効化されていないか確認してください。セキュリティチームが90日間のキーローテーションポリシーを強制している場合に特によく見られます。
複数のAWSアカウントを使用している場合は？AWS_PROFILEまたはプロバイダーのprofile引数が正しいアカウントを指しているか再確認してください。複数のアカウントを同時に扱う際に、ステージングと本番の認証情報を混同することは簡単に起こりえます。
認証情報をバージョン管理にコミットしないでください。dataソース経由で参照するバックエンドパスワードなどのシークレットについては、ToolCraftのパスワードジェネレーターのようなツールをローカルで使って生成してください — ブラウザ上で完全に動作し、情報が外部に送信されることはありません。