Stop 03 · Linux & Scripting BasicsTopics · 9/9

Working With Cloud CLIs

Part of the Cloud Computing Roadmap

In short

The web console is great for exploring. Real cloud work runs on the command line: it's faster, it can be scripted, and you can paste the exact command into a runbook for the next person.

Each major provider offers a command-line interface (AWS CLI, gcloud, az) for scripting and automating infrastructure tasks — often faster than the web console once you're comfortable with it.

The blob character taps a phone and tosses a stack of paper forms past an empty bank counter.

Think of it like this

UPI app vs bank queue

You could stand in the bank queue and fill a paper form to send money. Or open your UPI app and do it in ten seconds, with a record of every payment. The console is the queue. The CLI is the app.

Watch it happen

One CLI command, end to end

You
aws CLI
AWS API

aws sso login

1/6You sign in once. The CLI stores short-lived credentials for your profile.

The big ideas

What you need to know

Three CLIs, one pattern

aws, gcloud and az all follow 'tool, service, action, flags'. Learn one and the others feel familiar.

Profiles for accounts

Use named profiles (--profile dev) so you always know which account a command will hit.

Filter the output

--query on AWS, --format on gcloud and --query on az trim huge JSON into what you need.

Commands become scripts

Any command that works in your terminal can go into a bash script, a CI job or a runbook.

How it works

Getting set up the first time

  1. 1

    Install

    Install the CLI from the provider's official docs and check it with aws --version.

  2. 2

    Sign in

    Use aws configure sso, gcloud auth login or az login. Avoid long-lived access keys.

  3. 3

    Pick defaults

    Set a default region like ap-south-1 and an output format.

  4. 4

    Try read-only first

    Run list and describe commands before anything that creates or deletes.

See it in code

Walk through the code

bash
1aws sts get-caller-identity --profile dev     # who am I, which account?2 3aws ec2 describe-instances --profile dev \4  --filters Name=instance-state-name,Values=running \5  --query "Reservations[].Instances[].[InstanceId,InstanceType]" \6  --output table7 8gcloud compute instances list --format="table(name,status)"9az vm list --output table

1/3Confirm the account before you touch anything. It's the cheapest safety check there is.

Always run get-caller-identity before a risky command. It tells you exactly which account and role you're using.

Save yourself the pain

Common mistakes

Oops

Running a delete command without checking which account the CLI is pointing at.

Do this instead

Run aws sts get-caller-identity or use explicit --profile flags. Many accidents are 'wrong account' accidents.

Oops

Creating long-lived access keys for your personal user.

Do this instead

Prefer SSO or short-lived credentials. If you must use keys, rotate them and never commit them.

Your mission

Console to CLI

~25 min

Quick check

You're about to run a command that deletes resources. What's the best quick check first?

Go deeper

  1. 1Install and configure the CLI for your primary cloud provider.
  2. 2Practice creating and listing a resource entirely from the CLI, without touching the console.
  3. 3Learn to use CLI output formatting (e.g. --output json) to pipe results into other scripts.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge