Console and AWS CLI v2

You have a safe account and an admin identity. Clicking through the console works for a first look, but Lantern’s maintainers want something they can repeat, paste into a runbook and review in a pull request. Every console button calls an AWS API, and the AWS CLI v2 lets you call the same APIs from your terminal.

Console or CLI?

Use the console to explore, read dashboards, and do one-off tasks you want to see visually, such as the first look at a bill. Use the CLI for anything you will do twice, anything a colleague should review, and anything you want to undo exactly. A command in a script is documentation; a sequence of clicks is a memory.

If you can’t install anything, AWS CloudShell gives you a browser terminal in the console with the CLI already installed and signed in as your console identity.

Install and check the version

Install from the official package for your system. On Linux x86-64:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws --version

On macOS, AWS publishes a .pkg installer, and on Windows an .msi. Whichever you use, aws --version should print aws-cli/2. followed by a version number. You need 2.32.0 or later for the sign-in command below; if you have an old version 1 install, remove it first, because the two behave differently.

Sign in without access keys

The old way was aws configure, pasting a long-term access key ID and secret into ~/.aws/credentials. Those keys never expire, and they leak through backups, screenshots and Git commits. Today you sign in with your console identity instead:

aws login --profile lantern-admin

The CLI asks for a default Region the first time (enter Lantern’s), opens your browser, and after you sign in with your password and MFA it stores short-term credentials that refresh automatically for up to 12 hours. Your ~/.aws/config gains a profile like this, and notice there is no secret in it:

[profile lantern-admin]
login_session = arn:aws:iam::111122223333:user/amara
region = eu-west-1

An IAM user needs permission to use this flow; the AdministratorAccess policy from the last lesson already includes it, and for narrower users AWS provides the SignInLocalDevelopmentAccess managed policy. Teams that use IAM Identity Center sign in with aws configure sso and aws sso login instead, which you meet in section two. When you are finished, aws logout --profile lantern-admin deletes the cached credentials.

Who am I?

The most useful command in AWS is also the most boring:

aws sts get-caller-identity --profile lantern-admin

{
  "UserId": "AIDAEXAMPLEUSERID1234",
  "Account": "111122223333",
  "Arn": "arn:aws:iam::111122223333:user/amara"
}

It needs no permissions and changes nothing, so even a brand-new identity with no policies attached can run it. If it fails, the problem is your credentials, not your permissions: expired session, wrong profile name, or no network. It tells you which account and which identity every following command will use. Run it before anything destructive, and in scripts, check that Account is the one you expect before going further.

Shaping the output

Responses are JSON by default, and often long. Two global options help:

• --output picks the format: json, text, table or yaml.
• --query filters the response with a JMESPath expression on your machine before printing.

aws s3api list-buckets --profile lantern-admin \
  --query "Buckets[].Name" --output text

That prints only the bucket names, tab-separated, ready for a shell loop. Because --query runs locally, it does not reduce what AWS returns or what the call costs; it only reduces what you have to read.

That closes section one: you know where AWS runs things, who secures what, and how to drive the account safely. Section two looks inside IAM, the system that decides whether each of those other calls is allowed. (get-caller-identity is the one exception: it works even when a policy denies it.)