Console, CLI, SDK and CloudShell

By the end of this lesson you will be able to

• Explain why the Management Console, the CLI, the SDKs and CloudShell all see the same resources: each one is just a client of the same AWS APIs.
• Describe what an access key is, what it can and cannot do, and how a request is signed with it without the secret ever leaving your machine.
• Configure the AWS CLI with aws configure, read its two files, use named profiles, and predict which credentials it will use.
• Use CloudShell and know its limits: whose permissions it has, what it stores, for how long, and where.
• Diagnose the everyday failures: wrong Region, missing or invalid credentials, a bad signature, a skewed clock, and access denied.
• Respond correctly to a leaked access key, and design so that there is no long-term key to leak.

#Every road leads to the same API

In lesson 1.2 you saw where AWS keeps its data centres. This lesson is about how you, sitting at your laptop, tell those data centres what to do.

There are four everyday ways in:

1. The AWS Management Console: the website you sign in to with a password. You click.
2. The AWS CLI (Command Line Interface): a program in your terminal. You type aws s3 ls.
3. An AWS SDK (Software Development Kit): a library inside your own program. Your code calls s3.list_buckets().
4. AWS CloudShell: a terminal that opens inside the console, already signed in as you.

They look completely different, but underneath they do exactly the same thing. Every action in AWS, from launching a server to reading a file, is an API call: an HTTPS request to a service endpoint such as ec2.us-east-1.amazonaws.com, carrying a signature that proves who sent it. The console builds that request when you press a button; the CLI builds it from your command; the SDK builds it from your function call. AWS cannot tell, and does not care, which one you used. It checks two things only: who is asking (authentication) and are they allowed (authorization).

That has a practical consequence the exam likes to test: anything you create in the console is visible from the CLI and the SDK, and the other way round. There is no “console copy” of your account.

#Endpoints and Regions

Most AWS services are regional: EC2 in us-east-1 is a separate deployment from EC2 in eu-west-1, with its own endpoint (ec2.us-east-1.amazonaws.com, ec2.eu-west-1.amazonaws.com). Every request goes to exactly one Region. In the console, the Region is the selector at the top right; in the CLI and SDK it is the region setting, an environment variable, or the --region option.

A few services are global, IAM being the one you meet first: users and policies are the same whatever Region the console shows, and the console displays “Global” instead of a Region name. (Lesson 1.2 lists which services are global and which are regional.)

#The Management Console

The console is where everyone starts. You open the AWS sign-in page and sign in as one of two kinds of identity:

• The root user: the email address and password used to create the account. It has unlimited power over the account and should be locked away after setup (lesson 2.3).
• An IAM user: you enter the account ID (12 digits) or the account's alias, then a user name and password, and usually an MFA code. Each account has its own sign-in link of the form https://<account-id>.signin.aws.amazon.com/console.

After sign-in the console holds a temporary session, and every page you open makes API calls with it. A few things worth knowing:

• The Region selector decides which regional endpoint each page talks to. It is per page, not per account.
• The search bar finds services, features and documentation; you can pin favourite services.
• The console is a client like any other: if your permissions do not allow an action, the console shows an access denied banner, exactly where the CLI would print an error.
• Click-by-click work is hard to repeat and hard to review. People jokingly call it ClickOps. Use the console to learn and to look; use the CLI, the SDK or infrastructure as code for anything you need to do twice.

#Access keys: identity for programs

A program cannot type a password into a web page, so AWS gives programs a different kind of credential: an access key. An access key is a pair:

What you must know about them:

• They are for the CLI, the SDKs and direct API calls only. You cannot sign in to the Management Console with an access key, and you cannot use your console password in the CLI. They are two separate credentials for two separate doors.
• They belong to one IAM user (or, dangerously, to the root user) and carry exactly that user's permissions.
• The secret is shown only once, when you create the key. If you lose it, you cannot look it up again: create a new key and delete the old one.
• A user can have at most two access keys. That is not a limit to work around; it exists so you can rotate without downtime: create the second key, move your applications to it, then deactivate and delete the first.
• A key is Active or Inactive. Making it inactive stops it immediately but lets you turn it back on if something breaks; deleting it is final.
• Long-term keys never expire on their own. Their IDs start with AKIA. Temporary credentials, the kind a role or aws login hands out, have IDs starting with ASIA, come with a third part called a session token, and expire after minutes or hours.
• The root user should have no access keys at all. If one exists, delete it.

#How a request is signed (SigV4)

If the secret is like a password, how does the CLI prove it knows the secret without sending it? It uses Signature Version 4 (SigV4), the signing recipe every AWS API uses.

1. Build the request

   The CLI turns your command into an HTTPS request: method, endpoint, path, parameters, a hash of the body, and the current time.

2. Derive a signing key

   From the secret access key it derives a key that is valid only for this date, this Region and this service. A signature made for EC2 in us-east-1 today is useless for S3 in another Region tomorrow.

3. Sign

   It computes a signature over the request using that derived key and adds it to the request's Authorization header, together with the access key ID and the scope (date, Region, service). The secret itself is never in the request.

4. AWS repeats the calculation

   AWS looks up the secret that belongs to the access key ID, performs the same calculation on the request it received, and compares. Same signature: the request really came from the key's owner and was not changed on the way. Then IAM checks permissions.

Because of this design, a signature protects three things at once:

• Identity: only someone holding the secret could have produced it.
• Integrity: changing a single parameter (one instance into fifty) changes the hash and breaks the signature.
• Freshness: in most cases a request must reach AWS within five minutes of its timestamp, so a captured request cannot be replayed later.

You almost never sign anything yourself: the CLI and the SDKs do it for you. You only meet SigV4 when it fails, and the error tells you which of the steps went wrong.

#Reading the common errors

Notice the difference between the first five rows and the sixth. The first five are authentication failures: AWS does not know or trust who you are. Access denied is an authorization failure: AWS knows exactly who you are and has decided you may not do this. The exam and real incidents both depend on telling them apart.

#The AWS CLI

The AWS CLI is an open-source program (its code is on GitHub) that gives you direct access to the public APIs of AWS services from a terminal. Anything you can do in the console you can do with it, and usually a few things more, because some features appear in the API before they appear in the console.

• Install version 2. Version 1 is in maintenance mode and only gets critical fixes; AWS recommends moving to version 2.
• It runs on Linux, macOS and Windows, and it is preinstalled in CloudShell and in Amazon Linux.
• Every command has the same shape: aws <service> <operation> [options], for example aws ec2 describe-instances --region eu-west-1. The operation name is the API action in lowercase with hyphens: DescribeInstances becomes describe-instances.
• Output is JSON by default; --output table or --output text are easier to read or to feed into shell scripts, and --query picks out just the fields you need.
• Many EC2 commands accept --dry-run: AWS checks your permissions and parameters without doing anything.
• aws <service> help (or aws <service> <operation> help) prints the full reference offline.

#aws configure and the two files

The quickest way to give the CLI credentials is aws configure. It asks four questions and writes the answers into two plain-text files in a hidden .aws folder in your home directory:

$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-east-1
Default output format [None]: json

# ~/.aws/credentials   (Windows: C:\Users\<you>\.aws\credentials)
[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[prod]
aws_access_key_id = AKIAI44QH8DHBEXAMPLE
aws_secret_access_key = je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

# ~/.aws/config        (Windows: C:\Users\<you>\.aws\config)
[default]
region = us-east-1
output = json

[profile prod]
region = eu-west-1

• credentials holds secrets: key IDs, secret keys, session tokens.
• config holds everything else: Region, output format, role settings, IAM Identity Center settings.
• Each section is a profile. default is used when you do not name one. Other profiles are named [prod] in the credentials file but [profile prod] in the config file, a small difference that trips people up.
• Use a profile with --profile prod on one command, or export AWS_PROFILE=prod (PowerShell: $env:AWS_PROFILE = "prod") for the whole terminal session.
• The files are plain text. Anyone who can read your home directory can read your secrets, which is one more reason to prefer short-lived credentials.

Two commands answer “what is the CLI actually using?”:

• aws sts get-caller-identity shows the account and the identity your credentials belong to. It needs no permissions, so it always works when the credentials are valid.
• aws configure list shows each value (key, secret, Region, profile) and where it came from: the files, an environment variable, or something else.

#Where the CLI looks for credentials

The CLI and the SDKs search a fixed list of places and use the first one that has credentials. In simplified order:

1. Command-line options such as --profile or --region.
2. Environment variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_PROFILE, AWS_REGION.
3. The shared files, ~/.aws/credentials and ~/.aws/config, for the selected profile (this includes profiles that assume a role, use IAM Identity Center or use aws login).
4. Container credentials, for code running in a container task with a role.
5. The EC2 instance role, fetched from the instance metadata service (IMDS).

The order explains surprises. Environment variables beat the files, so a key you exported an hour ago silently wins over your carefully chosen profile. And the last two steps are why code on AWS compute needs no configuration at all: with a role attached, credentials simply appear.

#Short-term credentials for people

Long-term keys on laptops are what leak. Two better options exist for humans:

• aws login (CLI version 2.32.0 and later) signs you in through the browser with your normal console credentials and gives the CLI temporary credentials, refreshed automatically for up to 12 hours. Nothing permanent is stored.
• IAM Identity Center (aws configure sso, then aws sso login) is the organisation-wide option: people sign in once and get short-lived credentials for whichever accounts and permission sets they are assigned. You will meet it in lesson 2.4 and again in the advanced identity chapter.

Access keys still have their place, for example a script outside AWS that cannot sign in interactively, but they should be the exception, kept to the least privilege needed and rotated.

#The AWS SDKs

The AWS SDKs are libraries that let your own code call AWS. There is one per popular language: Python (boto3), JavaScript and TypeScript, Java, Go, .NET, PHP, Ruby, C++, Rust and more, plus mobile libraries for Android and iOS (through Amplify) and device SDKs for small IoT hardware. The CLI itself is built on botocore, the core of the Python SDK.

import boto3

ec2 = boto3.client("ec2", region_name="us-east-1")
for r in ec2.describe_instances()["Reservations"]:
    for i in r["Instances"]:
        print(i["InstanceId"], i["State"]["Name"])

import { S3Client, ListBucketsCommand } from "@aws-sdk/client-s3";

const s3 = new S3Client({ region: "us-east-1" });
const { Buckets } = await s3.send(new ListBucketsCommand({}));
console.log(Buckets.map((b) => b.Name));

What the SDK does for you:

• Finds credentials using the same kind of search the CLI uses, so the same code works on your laptop (profile or aws login), in a pipeline (environment variables) and on EC2 or Lambda (its role) without a single change.
• Picks the endpoint for the Region and signs every request with SigV4.
• Retries throttled or temporarily failed requests with exponential backoff.
• Pages through long results and turns responses into native objects.

The rule that matters most: never write credentials into your code. Notice that neither example above mentions a key. The code just creates a client; where the credentials come from is decided by the environment it runs in.

#AWS CloudShell

CloudShell is a terminal in your browser, opened from the icon in the console's top bar. Behind it AWS starts a small Linux environment for you with the AWS CLI, Python, Node.js, git and common tools already installed.

What makes it useful:

• No setup and no keys. CloudShell automatically uses the credentials of the person signed in to the console. You do not run aws configure, and there is no access key on disk to leak.
• Exactly your permissions. CloudShell can do what you can do in the console, nothing more. It is not a back door. Using CloudShell itself also requires permission (AWS provides the AWSCloudShellFullAccess managed policy), so administrators can deny it to people who should not have a shell with internet access.
• No extra charge. You pay only for the AWS resources your commands create.

Its limits, which the exam and daily use both care about:

Each Region has its own home directory, so a script saved in us-east-1 is not there when you open CloudShell in eu-west-1. You can upload and download files through the Actions menu, or move them through S3. CloudShell can also be started inside one of your VPCs to reach private resources; those VPC environments have no persistent storage at all.

#Leaked keys: the most expensive mistake

Because an access key works from anywhere on the internet, without a password or MFA, a leaked key is a leaked account. The classic story goes like this: a developer writes a key into a config file “just to test”, pushes the project to a public GitHub repository, and within minutes automated scanners have found it. The attacker never touches the console; they call the API from their own machines and launch large instances in every Region, usually to mine cryptocurrency. The bill can reach thousands of dollars in a day.

AWS scans public code too. When it finds one of your keys, it attaches the AWSCompromisedKeyQuarantineV3 managed policy to the user, which denies risky actions such as launching instances or creating users, opens a support case and emails you. This limits the damage. It does not undo what was already launched, and you should not remove the policy yourself; follow the support case instead.

What to do, in this order:

1. Make the key useless

   Deactivate it (or delete it) in IAM immediately. Deleting the file or the commit is not enough: the key remains in git history, in forks and in every copy the scanners already took.

2. Replace it

   Give the application a replacement, ideally an IAM role rather than a new key. If a key is truly needed, create the new one first (that is what the second key slot is for), switch over, then delete the old one.

3. Find out what happened

   Use CloudTrail to list every API call made with that access key ID, in all Regions: resources created, users or keys added, policies changed.

4. Clean up

   Terminate unknown instances and other resources, delete any users, keys or roles the attacker created, check the bill, and work through the AWS support case.

Prevention is mostly design, not discipline:

• No credentials in code, ever. Let the SDK find them.
• Roles for workloads on AWS, short-term credentials for people (aws login, IAM Identity Center).
• Least privilege for any key that must exist, so a leak does limited damage.
• A .gitignore that excludes .aws/ folders and .env files, and a secret-scanning hook that blocks commits containing key-like strings.
• Regular audits: the IAM credentials report shows every key's age and last use (lesson 2.4). A key nobody has used for months should be deleted.

#Beyond typing commands: infrastructure as code

The CLI is great for single tasks, but a real system has hundreds of resources. Creating them with a long script of CLI commands is fragile: what if step 40 fails, or you need the same setup in another Region? That is the job of infrastructure as code (IaC): you describe the result you want in a file, and a tool works out and makes the API calls.

• AWS CloudFormation reads a template (JSON or YAML) and creates, updates or deletes all its resources together as one stack. Delete the stack and everything it made is removed.
• The AWS CDK (Cloud Development Kit) lets you write the same thing in TypeScript, Python, Java or another language; it generates a CloudFormation template and deploys it.
• Terraform and similar third-party tools do the same job across several clouds.

Underneath, all of them use the same APIs and the same credentials and permissions as the CLI. They appear throughout this course whenever “repeatable”, “across accounts” or “across Regions” shows up in a design.

#Choosing the right door

#Try it yourself

# 1. Install or check the CLI (version 2)
aws --version                              # aws-cli/2.x ...

# 2. Sign in without long-term keys (CLI 2.32.0+), or configure keys if you must
aws login                                  # opens the browser, temporary credentials
# aws configure                            # writes ~/.aws/credentials and ~/.aws/config

# 3. Who am I, and where did each setting come from?
aws sts get-caller-identity
aws configure list

# 4. Same question, two Regions: see the Region boundary for yourself
aws ec2 describe-instances --region us-east-1 --query "Reservations[].Instances[].InstanceId"
aws ec2 describe-instances --region eu-west-1 --query "Reservations[].Instances[].InstanceId"

# 5. A second profile, used once and for the whole session
aws configure --profile prod
aws s3 ls --profile prod
export AWS_PROFILE=prod && aws sts get-caller-identity && unset AWS_PROFILE

# 6. Ask AWS whether you could launch an instance, without launching it
aws ec2 run-instances --dry-run --instance-type t3.micro \
  --image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64
# "Request would have succeeded, but DryRun flag is set" = you have permission

# 7. Rotate an access key with no downtime (replace the user name and key IDs)
aws iam list-access-keys --user-name dev-alice
aws iam create-access-key --user-name dev-alice              # second key; save its secret now
aws iam update-access-key --user-name dev-alice --access-key-id AKIA_OLD_KEY_ID --status Inactive
aws iam delete-access-key --user-name dev-alice --access-key-id AKIA_OLD_KEY_ID

Then open CloudShell from the console, run aws sts get-caller-identity there (it shows your console identity without any setup), create a file with echo hi > ~/note.txt, switch the console to another Region, open CloudShell again and run ls ~: the file is not there.

#Summary

Key takeaways

• Console, CLI, SDK and CloudShell are four clients of the same APIs. Every action is a signed HTTPS request to a service endpoint in one Region; AWS checks who you are, then whether you are allowed.
• Most services are regional: the wrong Region shows an empty account, not a deleted one. IAM is global.
• Access keys = access key ID (like a user name) + secret access key (like a password). For the CLI, SDKs and API only, never for console sign-in. Secret shown once; maximum two per user, for rotation; Active or Inactive; root should have none. AKIA = long-term, ASIA = temporary with a session token.
• SigV4 signs each request with a key derived from the secret for one date, Region and service. The secret is never sent; the signature proves identity, integrity and freshness (about five minutes).
• aws configure writes ~/.aws/credentials (secrets) and ~/.aws/config (Region, output, profiles as [profile name]). Use --profile or AWS_PROFILE; check with aws sts get-caller-identity and aws configure list.
• The CLI and SDKs search options → environment variables → shared files → container role → instance role, and use the first credentials they find. Leftover environment variables beat your profile.
• Prefer short-term credentials: aws login or IAM Identity Center for people, IAM roles for code on AWS.
• CloudShell: browser terminal with your console permissions, no keys, no charge, 1 GB persistent home per Region, deleted after 120 days unused, idle timeout 20–30 minutes, about 12 hours maximum.
• Leaked or hardcoded keys: deactivate and rotate immediately, investigate with CloudTrail, clean up, and move the workload to a role.
• Infrastructure as code (CloudFormation, CDK, Terraform) turns a description into the same API calls, so environments are repeatable and deletable.

Self-check: Console, CLI, SDK and CloudShell30 questions