aws configureSet up AWS CLI credentials, region and profiles
aws configure stores the credentials, default region and output format the AWS CLI uses, in ~/.aws/credentials and ~/.aws/config, optionally as named profiles. Knowing where the CLI actually gets its credentials from (flags, env vars, profiles, SSO, instance roles) explains most 'wrong account' and 'access denied' surprises.
aws configure [--profile NAME] | aws configure list | get KEY | set KEY VALUE | list-profiles | ssoYou have a fresh laptop or VM and an access key for a lab account. Get the CLI working.
awsThe AWS CLI v2, a single program for every AWS service.
aws configure only writes INI files: keys go to ~/.aws/credentials, everything else to ~/.aws/config (named profiles appear there as [profile prod]). The interesting part is how every later command finds credentials: the first source that has them wins. In order: --profile on the command line; the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN environment variables; then the profile chosen by AWS_PROFILE or default, which can hold static keys, an IAM Identity Center (SSO) session, a role_arn to assume through STS, or a credential_process; then container credentials (ECS task roles, EKS Pod Identity) and web identity tokens (EKS IRSA); and finally the EC2 instance profile through IMDSv2. Temporary credentials are cached under ~/.aws/cli/cache. Each request is then signed with SigV4 using the secret key, the date, the region and the service, so a wrong clock or region breaks it.
The CLI tries credential sources in a fixed order; the first one that has credentials wins.
Before sending anything, the CLI must find an access key, secret and maybe a session token, plus a region. --profile on the command line short-circuits the search.
aws configurePrompt for access key, secret, region and output format--profile NAMERead or write a named profile instead of defaultlistShow which credentials, region and profile are in effect, and where each came fromlist-profilesList every profile defined in the config filesget / set KEYRead or write one setting non-interactivelyaws configure ssoSet up an IAM Identity Center (SSO) profile; then aws sso loginAWS_PROFILE / AWS_REGIONEnvironment variables that pick the profile and regionaws sts get-caller-identity'Who am I?': the account and ARN the CLI is really usingUsing the root user's access keys with aws configureRoot keys can't be limited by IAM policies; if leaked, the whole account is gone.
Delete root keys; use IAM Identity Center (aws configure sso) or an IAM user/role with least privilegeexport AWS_ACCESS_KEY_ID=... in ~/.bashrcEnv vars override every profile, so --profile-less commands always use them, and they leak into every child process.
Named profiles, with --profile or AWS_PROFILE set per command or per terminalCOPY ~/.aws into a Docker image or committing it to gitPlain-text secrets end up in image layers and repo history, where scanners and attackers find them.
Use roles: instance profiles, ECS task roles, EKS Pod Identity or IRSAAssuming the CLI is in the region where your resources areMost AWS APIs are regional; listing in the wrong region returns an empty result, not an error.
Check aws configure get region, and pass --region explicitly in scriptsTry these on a Linux machine of your own. Each task has a hint and a solution.
The aws CLI here talks to a practice AWS account. First run aws configure with the keys in ~/aws-access-keys.csv. Then edit ~/.aws/config with a default profile in us-east-1 (json output) and a profile named prod in eu-west-1 that assumes arn:aws:iam::210987654321:role/ops-admin from default.
Lock down the folder: make ~/.aws and everything in it readable only by you, and check the result.
List the profile names defined in your ~/.aws/config, the way aws configure list-profiles would.
Run the command that tells you which identity and account your credentials belong to, printing only the ARN.
aws configureSet up AWS CLI credentials, region and profiles
aws configure stores the credentials, default region and output format the AWS CLI uses, in ~/.aws/credentials and ~/.aws/config, optionally as named profiles. Knowing where the CLI actually gets its credentials from (flags, env vars, profiles, SSO, instance roles) explains most 'wrong account' and 'access denied' surprises.
aws configure [--profile NAME] | aws configure list | get KEY | set KEY VALUE | list-profiles | ssoYou have a fresh laptop or VM and an access key for a lab account. Get the CLI working.
awsThe AWS CLI v2, a single program for every AWS service.
aws configure only writes INI files: keys go to ~/.aws/credentials, everything else to ~/.aws/config (named profiles appear there as [profile prod]). The interesting part is how every later command finds credentials: the first source that has them wins. In order: --profile on the command line; the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN environment variables; then the profile chosen by AWS_PROFILE or default, which can hold static keys, an IAM Identity Center (SSO) session, a role_arn to assume through STS, or a credential_process; then container credentials (ECS task roles, EKS Pod Identity) and web identity tokens (EKS IRSA); and finally the EC2 instance profile through IMDSv2. Temporary credentials are cached under ~/.aws/cli/cache. Each request is then signed with SigV4 using the secret key, the date, the region and the service, so a wrong clock or region breaks it.
The CLI tries credential sources in a fixed order; the first one that has credentials wins.
Before sending anything, the CLI must find an access key, secret and maybe a session token, plus a region. --profile on the command line short-circuits the search.
aws configurePrompt for access key, secret, region and output format--profile NAMERead or write a named profile instead of defaultlistShow which credentials, region and profile are in effect, and where each came fromlist-profilesList every profile defined in the config filesget / set KEYRead or write one setting non-interactivelyaws configure ssoSet up an IAM Identity Center (SSO) profile; then aws sso loginAWS_PROFILE / AWS_REGIONEnvironment variables that pick the profile and regionaws sts get-caller-identity'Who am I?': the account and ARN the CLI is really usingUsing the root user's access keys with aws configureRoot keys can't be limited by IAM policies; if leaked, the whole account is gone.
Delete root keys; use IAM Identity Center (aws configure sso) or an IAM user/role with least privilegeexport AWS_ACCESS_KEY_ID=... in ~/.bashrcEnv vars override every profile, so --profile-less commands always use them, and they leak into every child process.
Named profiles, with --profile or AWS_PROFILE set per command or per terminalCOPY ~/.aws into a Docker image or committing it to gitPlain-text secrets end up in image layers and repo history, where scanners and attackers find them.
Use roles: instance profiles, ECS task roles, EKS Pod Identity or IRSAAssuming the CLI is in the region where your resources areMost AWS APIs are regional; listing in the wrong region returns an empty result, not an error.
Check aws configure get region, and pass --region explicitly in scriptsTry these on a Linux machine of your own. Each task has a hint and a solution.
The aws CLI here talks to a practice AWS account. First run aws configure with the keys in ~/aws-access-keys.csv. Then edit ~/.aws/config with a default profile in us-east-1 (json output) and a profile named prod in eu-west-1 that assumes arn:aws:iam::210987654321:role/ops-admin from default.
Lock down the folder: make ~/.aws and everything in it readable only by you, and check the result.
List the profile names defined in your ~/.aws/config, the way aws configure list-profiles would.
Run the command that tells you which identity and account your credentials belong to, printing only the ARN.