Searched "delete profile" hoping to remove an IAM instance profile, SageMaker user profile, or AppConfig configuration profile? Wrong guide - see the FAQ. This one removes a named profile from ~/.aws/config and ~/.aws/credentials.
Here's what trips most people up: there is no aws configure delete-profile command. AWS has never shipped one, despite an 8-year-old open GitHub issue. Removing a profile means a manual edit - exactly where accidents happen.
This covers static, role, and SSO profiles, the caches they leave behind, and how to confirm the removal stuck. Haven't set up or switched profiles yet? Start with our AWS CLI profile guide first.
Why There's No aws configure delete-profile Command
The aws configure command group has eleven subcommands - list, list-profiles, get, set, import, export-credentials, sso, sso-session, add-model, agent-toolkit, mfa-login - none of which delete anything. set only writes or updates a value.
That's the first trap. Running aws configure set aws_access_key_id "" doesn't remove the key - it writes an empty value, leaving a bare aws_access_key_id = line behind. The profile still shows up in list-profiles. If you want it gone, edit the file directly.
Delete a Single AWS CLI Profile Without Breaking the Others
Back up both files first - this undoes any mistake. AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE relocate those files, so resolve the active paths instead of assuming the defaults:
AWS_CONFIG="${AWS_CONFIG_FILE:-$HOME/.aws/config}"
AWS_CREDS="${AWS_SHARED_CREDENTIALS_FILE:-$HOME/.aws/credentials}"
cp "$AWS_CONFIG" "$AWS_CONFIG.bak"
cp "$AWS_CREDS" "$AWS_CREDS.bak"
The rest of this guide names the default paths for readability. If either variable is set on your machine, edit $AWS_CONFIG and $AWS_CREDS instead - and remember the CLI reads the override, not the default, so editing ~/.aws/config while AWS_CONFIG_FILE points elsewhere changes nothing.
The files use different header formats, which is where edits go wrong: ~/.aws/config uses [profile name]; ~/.aws/credentials uses just [name]. If a profile exists in both with overlapping keys, the credentials file wins.
Check nothing else depends on it. A role profile borrows credentials through source_profile, so deleting the source breaks every profile chained to it:
grep -nE "source_profile[[:space:]]*=[[:space:]]*staging" "${AWS_CONFIG_FILE:-$HOME/.aws/config}"
Repoint or remove those too. Then delete staging from both files:
# ~/.aws/config
[profile staging]
region = eu-west-1
output = json
# ~/.aws/credentials
[staging]
aws_access_key_id = AKIAEXAMPLE
aws_secret_access_key = wJalrXExample
A widely-read Stack Overflow thread has a top-voted answer telling you to delete the entire credentials file, and a comment pushing back - with 50+ credentials in one file, that means rebuilding everything. Both are right, situationally: delete the whole file only with one profile; otherwise remove just the block.
Windows: %USERPROFILE%\.aws\config and %USERPROFILE%\.aws\credentials - same rule.
Remove an AWS SSO or Identity Center Profile
SSO profiles come in two shapes, depending on how you set up the AWS CLI with IAM Identity Center: an older inline form, and a newer form where the profile references a shareable [sso-session] block:
[profile my-dev-profile]
sso_session = my-sso
sso_account_id = 123456789011
sso_role_name = readOnly
[sso-session my-sso]
sso_region = us-east-1
sso_start_url = https://my-sso-portal.awsapps.com/start
Delete [profile my-dev-profile] like any other. Leave [sso-session my-sso] alone if another profile references it. Once nothing does, removing it is tidiness, not a requirement: verified on AWS CLI 2.36.20, an orphaned [sso-session] block produces no error or warning.
Then decide whether to run aws sso logout. Treat it as optional security cleanup rather than a deletion step, because it is not profile-scoped: its output reads "Successfully signed out of all SSO profiles," so every SSO profile on that machine needs re-authentication - including the ones using an [sso-session] you deliberately kept. If a colleague or another terminal is mid-task, remove just the token for the portal you're done with. Files in ~/.aws/sso/cache are JSON that records the portal URL they belong to, so match on that rather than guessing at the hashed filename:
grep -l "my-sso-portal.awsapps.com" ~/.aws/sso/cache/*.json
Delete only what that prints. Neither route touches config entries, and neither revokes role sessions already issued - those run for up to the permission set's session duration, up to 12 hours.
Clear the Caches a Deleted Profile Leaves Behind
Deleting the block and logging out leaves two on-disk caches that keep a "deleted" profile partially alive.
| Cache directory | Stores | Clear it with |
|---|---|---|
~/.aws/sso/cache | SSO access/refresh tokens | aws sso logout signs out every profile; to keep other sessions alive, delete only the token file matching that portal URL |
~/.aws/cli/cache | Temp credentials from role/SSO exchange | rm -r ~/.aws/cli/cache or del /s /q %UserProfile%\.aws\cli\cache - AWS-documented |
~/.aws/cli/cache is shared across every profile that assumes an IAM role - clearing it resets all of them. AWS doesn't document whether an entry survives its profile's deletion, so clear it anyway.
Confirm the Profile Is Actually Gone
Run aws configure list-profiles before and after editing. If the deleted name still shows up, you edited the wrong file, missed a block, or AWS_CONFIG_FILE/AWS_SHARED_CREDENTIALS_FILE points elsewhere.
More common: the profile is gone but commands still work or fail oddly. AWS_PROFILE pointing at the deleted name throws "could not be found" until unset. AWS CLI v2 honors AWS_DEFAULT_PROFILE for the same setting too, though only AWS_PROFILE is documented - unset both before trusting the result.
If both are unset and aws sts get-caller-identity still returns an identity, the credential chain is resolving something else: raw key exports, cached role credentials, or instance metadata on EC2. Tracing which identity is actually active tells you which one.
Cleanup depends on how the profile got its credentials:
Deleting a Profile Doesn't Revoke Access - Here's What Does
Removing a profile is local cleanup only - zero effect on whether the credential still works elsewhere: another machine, a CI runner, a forgotten script.
For a long-term IAM access key, deactivate for a reversible step, then delete:
aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name Bob
aws iam delete-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --user-name Bob
Inactive allows reactivation; deletion is permanent.
For IAM Identity Center, revocation is layered: ending a sign-in session doesn't end role sessions already issued. Real revocation means ending the active session in the console, removing permission-set assignments, and for urgent cases a deny-all SCP.
Don't confuse "deleted the profile" with "revoked the access" - only one touches AWS. AWS's newer aws login command (v2.32.0+) sidesteps some of this with short-lived, auto-rotated console credentials.
Next step
Your CLI Profile Is Gone. Is the Access Key Still Live?
Deleting a profile only cleans up your laptop. An AWS Security Review validates your IAM configuration and hands you a prioritized, engineer-ready remediation plan.
What to Do Next
Back up both files, remove the matching block, and for SSO profiles run aws sso logout. Clear both caches, then confirm with aws configure list-profiles and check for dangling AWS_PROFILE/AWS_DEFAULT_PROFILE.
Deleting a profile is entirely local. A long-term access key or Identity Center session stays live until revoked directly.
Adding a replacement or moving between the profiles you kept? Our AWS CLI profile guide covers both.