AWS CLI and SDK: scripting against AWS instead of clicking console

The AWS CLI is a command-line tool that maps almost every AWS API action to a shell command — aws <service> <action>, the same commands used throughout this domain's earlier bash examples (aws s3 cp, aws ec2 run-instances, aws route53 create-hosted-zone). It's the fastest way to run a one-off operational task without opening the console or writing a script.

The CLI (and every AWS SDK) resolves credentials through a defined chain, checking sources in order until one is found:

This ordering matters practically: a leftover AWS_ACCESS_KEY_ID environment variable from testing something else will silently override the credentials you actually intended to use (like an assumed role), producing confusing "wrong account" or "access denied" errors that have nothing to do with the permissions themselves — checking aws sts get-caller-identity (which reports exactly which identity is currently active) is the fastest way to rule this out before debugging anything else.

Named profiles let one machine hold credentials or role configurations for multiple AWS accounts or roles, selected explicitly per command instead of relying on whatever's currently in environment variables:

This is the practical, everyday tool for the exact problem the AWS Organizations lesson later in this domain covers structurally (multiple accounts) — named profiles are how a single engineer's machine switches between them without juggling separate credential exports.

The SDK (available for every major language — boto3 for Python, the AWS SDK for JavaScript, etc.) is how application code calls AWS services directly at runtime, rather than through a shell command. It follows the exact same credential-resolution chain as the CLI, which is why application code running on an EC2 instance or in Lambda, with no credentials configured anywhere in its code, still works — it's picking up the IAM role attached to that compute resource automatically.

Notice neither call includes an access key anywhere — in a properly-configured deployment (an EC2 instance profile, an ECS task role, a Lambda execution role, all covered via IAM roles in this domain's IAM lesson), the SDK finds credentials automatically through the same chain the CLI uses, which is exactly the "no long-lived static keys in application code" pattern this whole curriculum keeps returning to.

Beyond one-off convenience, CLI/SDK usage matters for two real reasons: reproducibility (a documented script is a record of exactly what was done, re-runnable and reviewable, unlike a sequence of console clicks nobody wrote down) and automation (a CI/CD pipeline, covered in its own domain, has no way to click through a web console — every automated deployment step is, underneath, CLI or SDK calls). Terraform itself, used throughout this domain and the Cloud Computing domain, is built on top of the same underlying AWS APIs the CLI and SDK call — three different interfaces to the identical set of operations.