How to Fix AWS CLI Profile Not Found: Config vs Credentials File Rules

The AWS CLI says a profile "could not be found" when the exact name you passed with --profile or set in AWS_PROFILE doesn't match a section header in either ~/.aws/credentials or ~/.aws/config, character for character. The single most common reason isn't a missing profile at all — it's that the config file and the credentials file use two different bracket formats for the same profile, and almost everyone copies one format into the other at some point.

What "the config profile could not be found" is actually telling you

Jake runs a small phone repair and resale shop, and he'd just talked a customer into waiting five extra minutes while he pulled up her old trade-in photos from a backup bucket he keeps in Amazon S3. He typed the command, added --profile client-backup because that's the name he was sure he'd used, and got this instead of a file listing:

The config profile (client-backup) could not be found

"But I made that profile," he said. "I remember doing it. Two weeks ago, on a Sunday, because that's the only day the shop is quiet enough to sit down and actually configure anything."

"You probably did," Ethan told him. "This error doesn't mean you never created it. It means the AWS CLI looked in exactly two plain-text files on your computer, read every section header in both, and none of them spelled out client-backup the way it expected. That's it. It's not judging your memory, it's reporting a string mismatch."

The AWS CLI's ProfileNotFound error is deliberately blunt. It doesn't tell you which file it checked, whether the name was close, or whether an environment variable silently overrode what you typed on the command line. It just tells you the name you asked for doesn't exist anywhere it looked. That's frustrating when you're standing at a counter with a customer, but it's also fixable in under a minute once you know the handful of places this actually goes wrong.

What makes this error deceptively simple is that it treats a dozen very different underlying problems as one identical message. A missing bracket prefix, a stray capital letter, a leftover environment variable from three terminal sessions ago, and a profile that was quietly redirected to a file that doesn't exist — all four produce the exact same line of text. The rest of this article walks through each of those causes in the order you should actually check them, starting with the one that catches the most people.

The two files, and the one rule that trips up almost everyone

The AWS CLI keeps its settings in two plain-text files, both living in a hidden folder named .aws in your home directory:

• The credentials file — ~/.aws/credentials on macOS and Linux, C:\Users\YourName\.aws\credentials on Windows. This is where long-term access keys and temporary session tokens live.
• The config file — ~/.aws/config on macOS and Linux, C:\Users\YourName\.aws\config on Windows. This holds region, output format, IAM Identity Center (SSO) settings, and role-assumption settings.

Both files use the same basic structure: a bracketed section header, followed by setting_name = value lines underneath it. Lines can even be commented out with a leading #, which is handy for temporarily disabling a profile without deleting it. Where people get burned is that a profile named myprofile is written differently depending on which file you're in.

Notice the pattern: only the config file uses the literal word profile inside the brackets, and only for anything that isn't default. The credentials file never uses that word, ever, for any profile. If you take a section header you wrote correctly in one file and paste it unchanged into the other, you've just created a profile the CLI can't see — because as far as the parser is concerned, [profile client-backup] in the credentials file and [client-backup] in the config file are both meaningless section names that don't match anything you asked for.

"That's genuinely a strange design choice," Jake said. "Why would they do that on purpose?"

"Because the config file also holds section types that aren't profiles at all — things like sso-session blocks," Ethan said. "If profile names in the config file didn't carry a prefix, there'd be no clean way to tell a profile section apart from a differently-typed section that happens to share a name. The credentials file only ever holds credentials, so it doesn't need the prefix. It's consistent once you know the reason. It's just never explained to you at the moment you need it."

There's a second wrinkle worth knowing about even if it isn't the direct cause of your error today: if a profile of the same name has settings in both files — say, an access key in credentials and a region in config — the credentials file wins for any setting both files try to define. The AWS CLI reads it as one merged profile, with the credentials file taking priority whenever there's overlap. That matters if you're ever staring at a profile that seems to be using an old access key you thought you'd removed; check the credentials file first, since it silently outranks the config file for anything it defines.

The full order the CLI checks things in, and why it matters here

A "profile not found" error is really a special case of a much bigger system: the AWS CLI checks for settings and credentials in a strict, fixed order, and whichever layer answers first wins, with everything below it ignored for that particular value. Understanding this order turns troubleshooting from guesswork into elimination.

Two of the environment variables in this chain deserve special attention because they never show up in either file, and they never appear in any command's output unless you specifically ask for them: AWS_CONFIG_FILE, which can redirect the CLI away from ~/.aws/config entirely, and AWS_SHARED_CREDENTIALS_FILE, which does the same for the credentials file. Neither can be set inside a named profile, and neither can be passed as a command-line flag — they only work as environment variables, which is exactly why they're so easy to forget you set.

Diagnose it in under a minute

Before touching either file, run these three checks in order. Each one rules out an entire category of cause, so you're not guessing.

1. List every profile the CLI can currently see. Run aws configure list-profiles. This prints every profile name the CLI found across both files, combined. If the name you're passing isn't on this list, the CLI is telling you the truth — it genuinely isn't there under that name, in either file.
2. Check whether an environment variable is quietly overriding what you typed. Run echo $AWS_PROFILE on macOS/Linux or echo $Env:AWS_PROFILE in PowerShell. If this variable is set, it silently becomes the default profile for every command that doesn't explicitly pass --profile, and it can even be why a command with no --profile flag at all suddenly starts failing after weeks of working fine.
3. Confirm the CLI is reading the files you think it's reading. Run echo $AWS_CONFIG_FILE and echo $AWS_SHARED_CREDENTIALS_FILE. If either of these is set to a custom path, the CLI has completely stopped looking at the default ~/.aws/ location, and the profile you're editing in your text editor may not be the file the CLI is actually consulting.

Run all three before you assume the profile itself is broken. In Jake's case, step one told him everything: client-backup wasn't on the list at all, but profile client-backup was — sitting right there, with the word "profile" baked into the actual name because he'd copied the config-file header style into the credentials file by mistake.

A fourth check worth running once you've narrowed things down: aws configure list --profile client-backup. Unlike list-profiles, which only confirms a name exists, this command shows you where each individual setting for that profile is coming from — the access key, the secret key, and the region — along with the file or environment variable it was pulled from. If the output shows the region coming from an environment variable instead of the file you just edited, that tells you an environment variable is winning the precedence fight for that particular setting, even though the profile name itself resolved correctly.

Cause 1: The profile prefix went in the wrong file (or is missing where it's required)

This is the cause the Quick Answer box points to, and by a wide margin it's the one people hit most. It shows up in two mirror-image forms:

Form A — the word "profile" ended up inside the credentials file. Someone opens ~/.aws/credentials, sees they need a new profile, and out of habit types [profile client-backup] because that's what they remember from a tutorial about the config file. The CLI now thinks the profile's actual name is the literal string profile client-backup, which nobody will ever type on a command line, so any attempt to use --profile client-backup fails. Run aws configure list-profiles after this mistake and you'll see the giveaway sitting right there in the output: a profile literally named profile client-backup, with a space in it.

Form B — the word "profile" is missing from the config file. Someone opens ~/.aws/config and writes [client-backup] instead of [profile client-backup], usually because they just finished editing the credentials file and the pattern is fresh in their head. The region and output settings under that header are now attached to a section the CLI doesn't recognize as a profile, so region lookups silently fall back to whatever the default region is, and if there's nothing usable in the credentials file for that name either, you get the "could not be found" error the moment credentials are needed.

The fix for both is the same: open the file, find the mismatched header, and correct the bracket format to match the table above. There's no command that renames a profile safely across both files at once — you're editing plain text, so a text editor is the right tool, not a script. Save the file, then immediately re-run aws configure list-profiles to confirm the corrected name shows up exactly as you expect before you try the original command again.

Cause 2: A typo, a stray space, or a case mismatch

Profile names are matched exactly, including capitalization. Client-Backup, client-backup, and client_backup are three different profiles as far as the CLI is concerned, and only one of them exists. A trailing space typed after the closing bracket, or a space before the opening bracket, also breaks the match on some shells and text editors, though most modern editors strip that automatically.

The reliable way to rule this out isn't to stare at the bracket and squint — it's to copy the exact name straight out of aws configure list-profiles and paste it into your command, rather than retyping it from memory. If the copied name works and your typed version didn't, you've found the mismatch, and you know exactly which character was wrong. This is also a good moment to standardize: if you catch yourself using both hyphens and underscores across different profiles, pick one style now, because a future you at 11 p.m. will not remember which profile used which.

Cause 3: AWS_PROFILE is set to a name that no longer exists

This one is sneaky because the command that fails often has no --profile flag on it at all. If the AWS_PROFILE environment variable is set in your shell — maybe you exported it weeks ago while testing something, or a script you ran earlier in the session set it and never unset it — every command you run afterward silently uses that name instead of default. If that profile was later deleted, renamed, or never existed under that exact spelling, you'll get "could not be found" on commands that used to work fine, with no explanation of why the behavior changed.

An environment variable always overrides the profile settings that live in either file, and a command-line --profile flag overrides the environment variable in turn. That ordering matters when you're troubleshooting: if you pass --profile default explicitly and it still fails, the problem isn't the environment variable, because the flag would have won that fight. If you pass nothing and it fails, but passing --profile default explicitly succeeds, the environment variable was the culprit the whole time.

Shell startup files are the usual hiding place. If AWS_PROFILE is exported somewhere inside .bashrc, .zshrc, or a PowerShell profile script, it gets set fresh every time you open a new terminal window, which makes it feel less like "something I did" and more like "the computer is broken." It isn't. Open that startup file, search for AWS_PROFILE, and you'll usually find the line that's been quietly running every single time you've opened a terminal for months.

Cause 4: The profile exists, but not in the file this authentication method needs

Not every profile needs an entry in the credentials file at all. Which file a given profile belongs in depends on how it authenticates:

If you set up SSO with aws configure sso and then go hunting for the profile in the credentials file, you won't find it, because that authentication method doesn't touch that file at all. That's expected behavior, not a bug — but if a teammate later tells you "just check your credentials file," you can waste real time looking in the wrong place before realizing the profile was written to config the entire time.

The reverse mistake happens too: someone manually types a role_arn and source_profile pair into the credentials file, because that's the file they associate with "where the important stuff goes." Role-assumption settings only work from the config file. Sitting in the credentials file, they're inert text that the CLI's role logic never reads.

Cause 5: The CLI isn't even reading the files you're editing

Two environment variables can redirect the AWS CLI away from the default ~/.aws/ location entirely: AWS_CONFIG_FILE for the config file, and AWS_SHARED_CREDENTIALS_FILE for the credentials file. Both are meant for situations like running multiple isolated CLI environments on one machine, or pointing a container at a mounted secrets file. Neither can be set from inside a named profile or from a command-line flag — they only take effect as environment variables.

The problem is that these variables have no visible trace once they're set. If you open ~/.aws/credentials in your editor, add a profile, save it, and the CLI still says it can't find that profile, check whether one of these two variables is set in your current shell. If AWS_CONFIG_FILE points somewhere else, every edit you make to the default file is invisible to every command you run, because the CLI was never looking there in the first place.

"I spent forty minutes on this once," Ethan admitted. "Edited the file, ran the command, got the same error, edited it again, still nothing. Turned out a setup script from a client project had exported AWS_CONFIG_FILE pointing at a project-local config folder, and it was still active in that terminal tab three days later. Always check the environment variables before you doubt the file."

A related but less common variant: file encoding. The CLI reads text files using an encoding that matches your system locale by default. On a Windows machine set to a non-UTF-8 locale, a config file saved by an editor that writes UTF-8 with special characters in it can occasionally be misread. If you've genuinely ruled out every other cause on this list and you're on Windows, setting the AWS_CLI_FILE_ENCODING environment variable explicitly to UTF-8 is a legitimate, documented way to remove encoding as a variable.

Fixing it: step by step, by authentication type

Once you know which authentication method the profile is supposed to use, the fastest reliable fix is usually to let the CLI's own commands write the file for you, rather than hand-editing brackets. Manual edits are fine for quick fixes, but the built-in commands guarantee the format is correct.

If it uses long-term IAM access keys

1. Run aws configure --profile client-backup, replacing the name with whichever one you intend to use consistently.
2. Enter the access key ID, secret access key, default region, and output format when prompted.
3. Verify it landed correctly by running aws configure list --profile client-backup. This should show the access key (partially masked) coming from the shared-credentials-file.
4. Test it against a real, harmless call, such as aws sts get-caller-identity --profile client-backup, which confirms the identity AWS thinks you are without touching any resources.

If it uses IAM Identity Center (SSO)

1. Run aws configure sso and answer the prompts for your organization's SSO start URL and region.
2. Choose the account and role you need when the wizard lists them.
3. When asked for a CLI profile name, give it the exact name you plan to type on the command line going forward — this is where a lot of confusion starts, because the wizard suggests an auto-generated name by default and it's easy to accept it without noticing.
4. Run aws sso login --profile client-backup whenever your cached session expires, since SSO credentials are time-limited and re-authenticate through the browser rather than through a static key.

If it's a role you assume from another profile

These live entirely in the config file, and they reference a source_profile that must itself exist and resolve successfully. A "could not be found" error on a role-assuming profile sometimes isn't about the role profile at all — it's about the profile it points to. Check both names independently with aws configure list-profiles before assuming the role definition itself is wrong. You cannot mix source_profile and credential_source in the same profile; if both appear, remove one, since the CLI treats that combination as a configuration error rather than picking one for you.

Windows, macOS, and Linux path differences that cause this too

On macOS and Linux, the files live at ~/.aws/credentials and ~/.aws/config, where ~ resolves to your home directory automatically in almost every context. On Windows, the equivalent location is C:\Users\YourUsername\.aws\credentials and the matching config file. A surprisingly common variant of this error happens when someone is running the CLI from inside WSL (Windows Subsystem for Linux) in one terminal and from native PowerShell in another, without realizing these are two separate home directories with two separate, independent .aws folders. A profile created in one is completely invisible to the other, because as far as either shell is concerned, it's a different computer with a different filesystem.

If you work across both environments, the practical fix is to pick one as your primary and either recreate the profile in the other, or point AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE at a shared location both environments can reach — understanding that doing so means both environments now read the same plaintext file, so file permissions matter more, not less.

File permissions themselves can also silently prevent a profile from being read on macOS and Linux. If ~/.aws/credentials has permissions open enough that other users on a shared machine could read it, some hardened environments and security tooling will refuse to trust it, and depending on your setup this can present as the CLI behaving as if the file were empty. Tightening permissions with chmod 600 ~/.aws/credentials is good practice regardless, since that file holds long-term secrets in plain text. On Windows, the equivalent tightening is done through the file's Properties > Security tab, or with icacls from the command line, restricting read access to your own user account rather than "Everyone" or "Users."

Jake found this out the unglamorous way, on a Monday, which he insists is when everything in his shop goes wrong. He'd set up a shared laptop at the front counter that two part-time staff also log into with their own Windows accounts. He'd configured his AWS profile under his own account and couldn't understand why the same command, run from his coworker's login, said the profile didn't exist. It wasn't a bracket problem at all — his coworker's Windows account has an entirely separate home directory, and therefore an entirely separate, empty .aws folder. Every profile Jake had ever created only ever existed under his own account.

SSO profiles: a slightly different flavor of the same error

IAM Identity Center profiles add a second kind of section to the config file, called sso-session, which groups the URL and region used to acquire an SSO access token. A profile can reference an sso-session block by name, and multiple profiles can share one sso-session to reuse the same login. If the sso_session value inside a profile doesn't exactly match the name of an [sso-session name] block elsewhere in the file, you'll see errors related to the session or the token rather than the classic "profile could not be found" text — but the underlying mistake is the same family of problem: two names that are supposed to match, don't.

Jake ran into a version of this when a friend helped him set up a shared AWS account for a small reseller co-op. The friend's config file had sso_session = reseller-sso inside the profile, but the actual session block further down was written as [sso-session Reseller-SSO] with a capital R. Because names are matched exactly, that capitalization difference was enough to break the login flow entirely.

There's also a legacy SSO configuration style still supported by the CLI, where a profile carries sso_start_url, sso_region, sso_account_id, and sso_role_name directly, with no separate sso-session block and no shared token refresh between profiles. If you're following an older tutorial or an existing config file that predates the session-based approach, don't mix the two styles inside a single profile — either reference an sso-session block, or set the legacy fields directly, but combining half of each tends to produce confusing, inconsistent results rather than a clean error.

Automation, containers, and CI: when there's no profile to find at all

Not every AWS CLI environment uses named profiles, and it's worth knowing when this error simply doesn't apply. On an Amazon EC2 instance with an IAM role attached, or inside an Amazon ECS task with a task role configured, credentials are delivered automatically through the instance or container metadata service, and there's no profile section involved unless you deliberately set one up. If you see a profile-related error on one of these systems, it usually means a script explicitly passed --profile or set AWS_PROFILE somewhere it shouldn't have, since the whole point of instance and container roles is to avoid needing a named profile in the first place.

The credential lookup order the CLI follows matters here: command-line options come first, then environment variables, then assumed-role configuration, then IAM Identity Center settings, then the credentials file, then a custom credential process, then the config file, then container credentials, and finally EC2 instance metadata, last in line. That ordering explains a specific class of confusing behavior: if a leftover AWS_PROFILE environment variable is set on a build server, it will be checked and will fail before the CLI ever gets down to the instance role that would otherwise have worked perfectly on its own.

If you're deliberately running the same deployment scripts on a developer laptop (where a named profile makes sense) and on a build server (where an instance role should just work), a clean pattern is to only export AWS_PROFILE in the developer's own shell configuration, never inside the script or repository itself. That way the script behaves identically in both places: it uses whatever profile the environment hands it, and on the build server, where nothing sets that variable, it falls straight through to the instance role with nothing standing in the way.

When the profile clearly exists and it still won't work

Occasionally you'll list the profile, see it exactly as expected, pass the name exactly as printed, and still hit the error. A few less-common causes are worth ruling out at this stage:

• Invisible characters copied from a chat app or PDF. Smart quotes, non-breaking spaces, and zero-width characters can be pasted into a bracket header without appearing any different on screen. Retype the bracket line by hand instead of pasting it if you suspect this.
• An older AWS CLI version. Very old versions (particularly some CLI v1 builds) have had bugs around how they handle a missing or malformed AWS_PROFILE value, sometimes producing a full stack trace instead of a clean error. Run aws --version and update if you're several major versions behind.
• Two separate installations of the CLI on the same machine. If a package manager and a manual installer both put an aws executable on your system, one might be reading a different home directory or a different bundled configuration than the one you expect. Run which aws (macOS/Linux) or where aws (Windows) to see exactly which binary is running.
• A locale-driven text encoding mismatch on Windows. As covered above, the CLI reads config files using your system's locale encoding by default; setting AWS_CLI_FILE_ENCODING=UTF-8 rules this out entirely if you suspect it.
• A data-path override hiding unrelated model files, not credentials. The AWS_DATA_PATH variable affects where the CLI looks for its internal service definitions, not your profiles, but it's worth ruling out if you're seeing other unrelated CLI misbehavior alongside the profile error, since a broken environment often has more than one variable set unexpectedly.

Once it's fixed: switching profiles without retyping --profile every time

Once a profile is working, the next thing most people ask is how to avoid typing --profile client-backup on every single command for the rest of the afternoon. There are a few honest options, in order of how much they add versus how much they're worth bothering with.

Exporting AWS_PROFILE for the session is the simplest option and needs nothing extra installed. Run export AWS_PROFILE=client-backup (or the PowerShell equivalent) once, and every command in that terminal window uses it until you close the window or unset it. The tradeoff, as the earlier section on environment variables covers, is that it's also the most common way people accidentally leave a stale profile active for days.

A short shell function or alias that wraps export AWS_PROFILE=... with a friendlier name is a reasonable middle ground for anyone who switches between two or three accounts regularly — something like a function named awsp that takes a short nickname and exports the right profile. It's a few lines in a shell startup file and requires no new software.

Directory-scoped environment tools, such as direnv, automatically set and unset environment variables based on which folder you're currently working in. This solves the "I forgot I had a profile exported" problem structurally, since the variable only exists while your terminal is inside that specific project folder. It's genuinely useful if you juggle several client AWS accounts in separate project directories, but it's one more tool to install and maintain, and it's overkill if you only ever use one or two profiles.

Dedicated credential-management tools like aws-vault go further, storing your actual secret keys encrypted in your operating system's keychain rather than in a plain-text credentials file at all, and injecting temporary credentials into a subshell only when you ask for them. This is worth the setup time if you're handling credentials for multiple client AWS accounts professionally and the plain-text credentials file genuinely worries you. It's not worth it for a single personal account doing occasional S3 uploads — the added complexity outweighs the benefit at that scale, and it won't fix a bracket-format mismatch any faster than editing the file directly would.

Before you share your config file with a teammate

Once you've got a working profile, it's tempting to just send the relevant block of text to a coworker who's hitting the same error, especially under time pressure. Before you do, know what's actually sensitive in each file:

• Never share the credentials file, or any block copied from it. Access keys and session tokens are, functionally, a password. Sending one over chat or email means it now exists in a system you don't control, and the honest fix if that happens is to deactivate and rotate the key, not just delete the message.
• The config file is usually safer to share, but not automatically. Region and output format are harmless. An SSO start URL and account ID are typically fine to share within an organization, since they're needed to set the profile up correctly in the first place, but they still reveal internal account structure and generally shouldn't go outside the company.
• If you're pushing project files to a shared repository, keep the entire .aws folder out of it. It's easy to add a project-local AWS config for convenience and forget it's sitting inside a folder that later gets committed. A line excluding that folder in your version control ignore file is worth adding before it becomes a problem rather than after.

For a team that's growing past one or two people sharing static keys informally, moving everyone to IAM Identity Center profiles solves the sharing problem structurally: nobody sends anybody a secret key at all, since each person authenticates through their own browser-based login, and the only thing that ever needs sharing is the SSO start URL, which isn't a credential on its own.

Keeping this from happening again

A few habits prevent almost every recurrence of this error:

• Let aws configure, aws configure sso, and aws configure set write the files for you whenever possible, instead of hand-typing bracket headers from memory.
• Run aws configure list-profiles right after creating anything new, as a two-second confirmation step rather than trusting that the wizard did what you expected.
• Unset AWS_PROFILE when you're done with a temporary task instead of leaving it exported for "just this session," since sessions have a way of lasting longer than intended.
• Keep AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE unset unless you have a specific, deliberate reason to redirect them, and if you do set them for a specific project, unset them again when you switch away from that project.
• Use one consistent naming style across every profile you create — all lowercase with hyphens is a common, low-friction choice — so a typo is easier to spot on sight.

"The whole thing that gets me," Jake said once he'd fixed his own file, "is that the error message doesn't say any of this. It just says 'could not be found,' like the profile evaporated."

"From the CLI's point of view, it did," Ethan said. "It's not being unhelpful on purpose. It genuinely searched two files, top to bottom, for a section header matching the exact string you gave it, and came up empty. Everything else — which file, which format, which environment variable got in the way — is context the error message was never designed to carry. That's what troubleshooting steps are for."

Frequently asked questions

Why does the config file need "profile" in the brackets but the credentials file doesn't?

The config file can hold section types other than profiles, such as sso-session blocks, so the word "profile" in the header is what tells the parser this particular section is a profile rather than something else. The credentials file only ever stores credentials, so there's no ambiguity to resolve and the prefix is unnecessary.

Do I need a profile in both files, or just one?

It depends on the authentication method. Long-term or short-term IAM credentials typically need an entry in the credentials file, with region and output settings optionally in the config file. SSO profiles, assumed-role profiles, and EC2-metadata-based profiles live entirely in the config file and never touch the credentials file at all.

How do I see every profile the CLI currently recognizes?

Run aws configure list-profiles. It reads both files and prints every profile name it finds, which is the fastest way to confirm what actually exists versus what you remember creating. Follow it with aws configure list --profile name to see exactly where each individual setting for that profile is being read from.

I didn't pass --profile at all, so why is it using the wrong one?

Check whether the AWS_PROFILE environment variable is set in your shell with echo $AWS_PROFILE. If it's set, it overrides the default profile for any command that doesn't explicitly specify --profile, and it can point at a profile that no longer exists. Shell startup files are the usual place this gets set and forgotten.

Are profile names case-sensitive?

Yes. Production and production are treated as two different profile names, so capitalization has to match exactly between the name you type and the name in the section header.

Can I rename a profile without recreating it?

There's no built-in rename command. You edit the section header text directly in whichever file (or files) hold that profile, changing the bracket text to the new name while leaving the settings underneath untouched, then update any script or environment variable that referenced the old name.

What's the difference between AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE?

AWS_CONFIG_FILE redirects where the CLI looks for the config file, and AWS_SHARED_CREDENTIALS_FILE redirects where it looks for the credentials file. Both default to the standard ~/.aws/ location and neither can be set from inside a profile itself or as a command-line flag, which is exactly what makes them so easy to forget you've set.

I set up SSO with aws configure sso, but I can't find the profile in my credentials file. Is that normal?

Yes. IAM Identity Center authentication doesn't use the credentials file at all — everything for an SSO profile is stored in the config file, including the account, role, and session details.

Does the default profile need the word "profile" in front of it?

No. [default] is written the same way in both files, with no prefix, even in the config file where every other named profile requires one.

If a profile exists in both files with different settings, which one wins?

When both files contain credentials for a profile of the same name, the values in the credentials file take precedence over the ones in the config file for that specific setting.

Why does a profile that worked yesterday fail today with no changes on my end?

The most common reasons are a temporary session token or SSO login expiring, an environment variable that got set in a new terminal session, or a teammate editing a shared configuration file that both of you point to. Check echo $AWS_PROFILE first, since a new terminal window can pick up a different startup script than the one you used yesterday.

Can I use spaces or special characters in a profile name?

Technically many characters are accepted, but spaces and special characters make the name awkward to type on a command line without quoting, and increase the odds of a typo. A hyphenated, all-lowercase name is easier to work with consistently.

I'm using WSL and PowerShell on the same Windows machine. Do they share profiles?

No, not by default. WSL has its own Linux-style home directory and its own ~/.aws/ folder, completely separate from the Windows home directory that PowerShell uses. A profile created in one is invisible to the other unless you point them at a shared file location using AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE.

What does it mean if the profile assumes a role and the error mentions the source profile instead?

A role-assuming profile in the config file references a source_profile that must resolve on its own first, since that's where the initial credentials come from before the role is assumed. If that referenced profile is misspelled, missing, or in the wrong file, the error can point at the source profile's name rather than the one you actually typed.

Is it safe to just delete both files and start over?

It's safe in the sense that it won't affect anything on the AWS side, but it will remove every profile you've configured, including ones that are working fine. It's usually faster and less disruptive to find the one mismatched header using aws configure list-profiles and the format table earlier in this article than to rebuild everything from scratch.

Does the region setting matter for this specific error?

Not directly. "Profile could not be found" is purely about whether the name matches a section header; a missing or wrong region setting inside a profile that does exist produces a different error, usually about a Region needing to be specified, rather than the profile itself being unfound.

Revision note. Written September 2026, covering the current AWS CLI version 2 configuration and credential file format, including IAM Identity Center (SSO), assumed-role, and EC2 instance metadata profiles. This will need a revisit if AWS changes the section-header syntax in a future major CLI version. If you're mid-troubleshoot and your customer is still waiting at the counter, the fix is almost always smaller than it feels right now — hang in there.