How to fix Error loading state: AccessDenied: Access Denied status code: 403 in Terraform

Ensure your AWS credentials are set up and accessible to Terraform. Check via:

aws sts get-caller-identity

This command returns the AWS account ID, ARN, and username. Verify it matches the account and user you expect. If this fails, configure credentials using:

aws configure

Or set environment variables:

export AWS_ACCESS_KEY_ID=your_access_key
export AWS_SECRET_ACCESS_KEY=your_secret_key
export AWS_DEFAULT_REGION=us-east-1

Use AWS CLI to directly test access to the S3 bucket:

aws s3 ls s3://your-bucket-name/

If this command fails with "NoSuchBucket" or an access denied error, the bucket either does not exist or your credentials cannot access it. If it succeeds, proceed to check IAM permissions. Double-check the bucket name in your Terraform configuration (terraform/backend.tf) for typos.

Your IAM user or role needs these minimum permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketVersioning"
      ],
      "Resource": "arn:aws:s3:::your-bucket-name"
    },
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:DescribeTable",
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:DeleteItem"
      ],
      "Resource": "arn:aws:dynamodb:*:*:table/your-lock-table"
    }
  ]
}

If using DynamoDB for state locking, include the DynamoDB permissions. Check your IAM policy in the AWS Console under "Users" or "Roles" to ensure these actions are allowed.

Delete the local .terraform directory and terraform.tfstate files to remove any stale references:

rm -rf .terraform terraform.tfstate terraform.tfstate.backup

Then reinitialize:

terraform init

This forces Terraform to fetch the latest state from the S3 backend fresh. This resolves issues where local state refers to deleted buckets or old backend configurations.

Get more details about what Terraform is doing when accessing S3:

export TF_LOG=DEBUG
terraform init 2>&1 | tee terraform-debug.log

Search the log for lines starting with "ERROR" or containing "Access Denied" to see the exact AWS API call failing. This helps identify whether the issue is s3:ListBucket, s3:GetObject, or a different permission.

The S3 bucket itself may have a policy explicitly denying access. View and modify the bucket policy via:

aws s3api get-bucket-policy --bucket your-bucket-name

Look for any Deny statements targeting your AWS account or IAM principal. If found, remove or modify the policy to allow your IAM user/role access. To set a permissive policy:

aws s3api put-bucket-policy --bucket your-bucket-name --policy file://policy.json

where policy.json contains your desired policy.

Check your backend configuration for typos and correct values:

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    # Optional: enable state locking
    dynamodb_table = "terraform-locks"
  }
}

Common mistakes:
- Typo in bucket name
- Region does not match bucket location
- Missing or incorrect key path
- Using assume_role without proper credential chain setup

In CI/CD environments, explicitly provide credentials in the backend block instead of relying on environment discovery:

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    access_key     = var.aws_access_key
    secret_key     = var.aws_secret_key
  }
}

Or pass credentials via environment variables during terraform init:

export AWS_ACCESS_KEY_ID=$CI_AWS_ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=$CI_AWS_SECRET_KEY
terraform init

This prevents profile mismatches between local and CI environments.