Fix Terraform Error: No valid credential sources found for provider "aws"

The Error

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 searched every credential source it knows about and came up empty. This usually happens on a fresh machine, inside a CI/CD pipeline that's missing secrets, or right after you switched AWS profiles and forgot to update the env vars.

Root Cause

The AWS provider checks credentials in a fixed order:

• Static credentials hardcoded in the provider block
• Environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
• Shared credentials file (~/.aws/credentials)
• AWS config file (~/.aws/config)
• EC2 instance profile / ECS task role / EKS pod identity

Strike out all five and you get this error. Pick any one of them to fix it.

Fix: Multiple Approaches

Option 1 — Set Environment Variables (Quickest)

The fastest way to unblock yourself. Export the credentials in your shell, then run Terraform:

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

On Windows (PowerShell):

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

Re-run terraform plan. Done.

Option 2 — Configure the AWS CLI Profile

Already have the AWS CLI installed? Set up a named profile:

aws configure --profile my-profile

Point Terraform to it via an environment variable:

export AWS_PROFILE=my-profile

Or hardcode it in the provider block if you prefer:

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

Option 3 — Credentials File

Check whether ~/.aws/credentials actually exists and has a [default] section:

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

Also confirm ~/.aws/config has a region set:

[default]
region = us-east-1

Missing either file is a common oversight after setting up a new workstation.

Option 4 — Assume a Role (Common in CI/CD)

Many pipelines use IAM roles instead of long-lived keys. Configure role assumption in the provider block:

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

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

One catch: the base credentials doing the assume-role call still need to exist somewhere — env vars or an instance profile both work.

Option 5 — EC2/ECS/EKS Instance Profile

Running Terraform on an AWS compute resource? Attach an IAM role to the instance or task. No credentials file needed — the SDK fetches a short-lived token from the metadata service automatically.

Verify the metadata service responds:

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

If it returns a role name, Terraform will pick it up on the next run.

Option 6 — GitHub Actions / CI Example

Store your keys as repository secrets (Settings → Secrets → Actions), then inject them as environment variables in the workflow step:

- 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

Verify the Fix

Before running Terraform, confirm AWS sees valid credentials:

# Check active credentials
aws sts get-caller-identity

A successful response looks like this:

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

Now run Terraform:

terraform init
terraform plan

A resource diff instead of a credential error means you're good to go.

Tips

• Rotate keys regularly. Static long-lived keys are the #1 cause of this error in production — someone rotates a key and forgets to update CI. Switch to short-lived credentials via aws sso login or role assumption to avoid this entirely.
• Pipeline worked yesterday, broken today? Check whether the IAM access key was rotated or deactivated. This is especially common when security teams enforce 90-day key rotation policies.
• Multiple AWS accounts? Double-check that AWS_PROFILE or the provider's profile argument points to the right account. Confusing staging and production credentials is an easy mistake when juggling several accounts at once.
• Never commit credentials to version control. For secrets like backend passwords referenced via data sources, generate them locally with a tool like the Password Generator on ToolCraft — runs entirely in the browser, nothing leaves your machine.