Switching profiles in AWS CLI keeps each command pointed at the intended AWS account, role, or IAM Identity Center session. That matters when the same workstation or admin shell moves between engineering, production, billing, or audit work.
A named profile is any saved entry under ~/.aws/config and ~/.aws/credentials. Use --profile for a one-command override, or export AWS_PROFILE when several commands in the same shell should use the same saved profile. The same selection flow works for access-key profiles, assumed-role profiles, and IAM Identity Center profiles after they are already configured.
Current AWS documentation puts command-line parameters above environment variables and environment variables above profile files. Raw credential variables such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY still override the credentials behind a named profile, so check the resolved source before commands that can change live resources.
$ aws configure list-profiles default engineering production
The target name must already exist in the shared config or credentials files before it can be selected.
$ aws configure list --profile production NAME : VALUE : TYPE : LOCATION profile : production : manual : --profile access_key : ****************DUCE : shared-credentials-file : secret_key : ****************EKEY : shared-credentials-file : region : eu-west-1 : config-file : ~/.aws/config
The profile row should show manual from --profile, which confirms this command is not falling back to [default] or a shell-level profile export.
$ aws sts get-caller-identity --profile production --query Account --output text 210987654321
--profile affects only that one command, so the next command returns to the current shell default unless you select a profile again.
Related: How to check the current caller identity in AWS CLI
$ export AWS_PROFILE=production
Unset AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN first if they are already exported in the shell, because those variables override the credentials that the named profile would otherwise supply.
$ aws configure list NAME : VALUE : TYPE : LOCATION profile : production : env : ['AWS_PROFILE', 'AWS_DEFAULT_PROFILE'] access_key : ****************DUCE : shared-credentials-file : secret_key : ****************EKEY : shared-credentials-file : region : eu-west-1 : config-file : ~/.aws/config
An explicit --profile on a later command still overrides this shell default for that one request.
$ unset AWS_PROFILE AWS_DEFAULT_PROFILE
Use AWS_PROFILE as the normal shell selector, and clear AWS_DEFAULT_PROFILE too if your shell or wrapper scripts exported it.
$ aws configure list NAME : VALUE : TYPE : LOCATION profile : <not set> : None : None access_key : ****************MPLE : shared-credentials-file : secret_key : ****************EKEY : shared-credentials-file : region : us-east-1 : config-file : ~/.aws/config
If the profile row still shows env, another exported variable or shell wrapper is still overriding the session.