The AWS CLI as the SDK's Shared Credential Backbone
The AWS CLI is a command-line tool for calling AWS APIs from a terminal.
//
Search across all documentation pages
The AWS CLI is a command-line tool for calling AWS APIs from a terminal.
But it does something quietly important that reaches far beyond the terminal: it writes the credential files that both AWS SDKs read.
When you run aws configure or aws sso login, the CLI stores identity and region settings in a shared location. The Python SDK (boto3) and the TypeScript SDK (AWS SDK for JavaScript v3) both look in that same location. This is why "set up the CLI first" is the standard opening move for any AWS project.
The AWS CLI v2 is a standalone program you install once per machine.
It talks to AWS by signing HTTPS requests with your credentials, exactly the way an SDK does.
To sign a request, it needs three things: an identity (access key or a session token), a default region, and an output format. aws configure collects those and saves them.
Two files hold the result. Credentials live in ~/.aws/credentials, and non-secret settings like region live in ~/.aws/config.
# ~/.aws/credentials
[default]
aws_access_key_id = AKIAEXAMPLE
aws_secret_access_key = wJalrEXAMPLEKEY# ~/.aws/config
[default]
region = us-east-1
output = jsonThe important idea is that these files are not private to the CLI.
They are a documented, shared convention. Any AWS tool that follows the standard reads them.
boto3 reads them. The AWS SDK for JavaScript v3 reads them. Terraform, the CDK, and countless other tools read them too.
So configuring the CLI once configures your whole local AWS toolchain at the same time.
The bridge between CLI setup and SDK code is the default credential provider chain.
When your SDK creates a client without explicit credentials, it walks an ordered list of sources and uses the first one that produces valid credentials.
The order is roughly: explicit code, then environment variables, then the shared credentials file, then the shared config file (including SSO), then container and instance metadata.
Because the shared files sit in that chain, code that names no credentials at all still authenticates. The SDK simply finds what the CLI wrote.
Here is the same "who am I" call in both SDKs, with no keys in the code.
# --- Python (boto3) ---
import boto3
# No keys passed. boto3 resolves them via the default provider chain,
# which includes the shared files the CLI wrote.
sts = boto3.client("sts")
identity = sts.get_caller_identity()
print(identity["Account"], identity["Arn"])// --- TypeScript (AWS SDK v3) ---
import { STSClient, GetCallerIdentityCommand } from "@aws-sdk/client-sts";
// No credentials passed. The v3 client resolves them via the same
// default provider chain that reads ~/.aws/config and ~/.aws/credentials.
const sts = new STSClient({});
const identity = await sts.send(new GetCallerIdentityCommand({}));
console.log(identity.Account, identity.Arn);Both snippets print the account and identity that aws configure set up.
The AWS_PROFILE environment variable selects which named profile the chain uses. Set it once in a shell and every SDK call in that shell targets that profile.
Region resolves the same way. The SDK uses AWS_REGION if set, otherwise the region from the active profile in the config file.
This shared resolution is the whole point. Setup happens once at the CLI layer, and every downstream tool inherits it.
The shared-file model is ideal for local development but wrong for production servers.
On an EC2 instance, a container, or a Lambda function, you should not copy key files around. Those environments provide credentials through instance or container metadata, which sits later in the same chain.
So the mental model scales cleanly: locally the chain resolves to your CLI-written files, and in production the same chain resolves to a role. Your SDK code does not change between the two.
Long-lived access keys in ~/.aws/credentials are the riskiest part of this setup. They do not expire on their own.
Modern practice replaces them with IAM Identity Center (SSO), where aws sso login writes short-lived, auto-refreshing credentials into the SSO cache instead of a static key file.
| Credential source | Strength | Weakness | Best Fit |
|---|---|---|---|
| Static keys in credentials file | Simple, works offline-ish | Long-lived, easy to leak | Quick local experiments |
| IAM Identity Center (SSO) | Short-lived, central control | Needs org setup | Teams and companies |
| Instance/container role | No files, auto-rotated | Only in AWS runtime | Production servers |
The practical takeaway is that CLI setup is not busywork before "real" coding.
It is the configuration layer your application code depends on. Getting it right once means your SDK code stays clean, portable, and free of secrets.
aws configure is only for using the CLI." - Its main long-term value is seeding the shared files every SDK reads.~/.aws/config, not a secret.aws sso login issues short-lived credentials that refresh, not static keys.Yes. All three follow the shared-config convention and read ~/.aws/config and ~/.aws/credentials from the same paths.
It prompts for an access key, secret key, default region, and output format, then writes those into the shared credentials and config files.
The default credential provider chain finds credentials for you - typically from the shared files the CLI wrote or from environment variables.
It is an ordered list of credential sources the SDK checks in turn, using the first that yields valid credentials.
Select a named profile, usually by setting the AWS_PROFILE environment variable or passing a profile name to the client.
From AWS_REGION if present, otherwise the region in the active profile in ~/.aws/config.
It works, but it is the least safe option because those keys do not expire. Prefer IAM Identity Center (SSO) where possible.
Not strictly, but installing and running the CLI is the easiest way to create the shared files your SDK then reads.
The credentials file holds secrets like access keys; the config file holds non-secret settings like region, output, and SSO details.
The same chain works, but production should resolve to an instance or container role, not copied key files.
Yes, through named profiles - each profile is a separate identity in the shared files.
Your code reads the files when it resolves credentials, so a new process or a re-created client picks up the change.
aws configure for your first profile.Stack versions: This page was written for the AWS CLI v2, boto3 1.43.x (Python 3.10+), and the AWS SDK for JavaScript v3 (Node.js 18+).
Reviewed by Chris St. John·Last updated Jul 23, 2026