Terraform and AWS Credentials: Environment Variables, Shared Files and Profiles Compared (AWS Provider 6.71)

Tue, 10 May 2022 00:00:00 +0000

TL;DR

TL;DR

The AWS provider reads credentials from six places, first match wins: provider block arguments, environment variables, the shared credentials file, the shared config file, container credentials, then the EC2 instance profile. I confirmed the first three with Terraform 1.17.1 and AWS provider 6.71.0 on 2026-11-04.

Never put access_key and secret_key in the provider block. They beat everything else, including the environment variables you set to override them, and they end up in Git.

Use AWS_PROFILE or the environment variables on a laptop, and a role (container credentials or an instance profile) in CI. AWS itself recommends temporary credentials over long-term access keys.

shared_credentials_file is gone. In provider 6.71.0 it fails with Unsupported argument ... Did you mean "shared_credentials_files"?. The new argument takes a list.

Different error? If Terraform complains about a variable instead, read Value for undeclared variable; if you want the full secrets-with-Vault story, read Securing AWS secrets with HashiCorp Vault and Terraform.

Every Terraform project on AWS starts with the same question: where do the keys live? I first wrote this post in 2022 with three options (hard-coded, shared file, environment variables). The options are still the same, but the provider has changed underneath them, so on 2026-11-04 I re-ran all of it. This version shows the real precedence, the real error messages, and what I would pick today.

AWS on Jhooq

Terraform and AWS Credentials: Environment Variables, Shared Files and Profiles Compared (AWS Provider 6.71)

TL;DR