The AWS CLI & Infrastructure Basics

In one line

The AWS CLI is the single tool underlying every example in this course — configuring it correctly, and understanding a resource's ARN, is the foundation everything else builds on.

0/4 · 0%

Key ideas

01
The AWS CLI is a command-line tool that talks to AWS's own APIs directly — exactly like kubectl talks to a Kubernetes cluster's API server (that course's Phase 0.4) or git talks to a repository — every single AWS Console action has an exact CLI equivalent, and most real, automated infrastructure work (including the Terraform/IaC course this collection will eventually cover) ultimately goes through these same underlying APIs.
02
aws configure sets up your LOCAL credentials — an access key ID and secret access key, tied to a specific IAM user (never root, per Topic 0.3) — stored locally so every subsequent CLI command authenticates automatically as that specific identity, with its own specific, scoped permissions.
03
Every single AWS resource has a genuinely unique ARN (Amazon Resource Name) — a structured identifier like arn:aws:s3:::my-bucket or arn:aws:iam::123456789012:user/your-name — genuinely essential to understand, since IAM policies (Phase 1) reference EXACTLY these ARNs to grant or restrict access to specific resources, not resource names or descriptions.
04
An ARN's structure is genuinely consistent and readable once you know the pattern: arn:partition:service:region:account-id:resource — arn:aws:ec2:us-east-1:123456789012:instance/i-0abc123 tells you immediately this is an EC2 instance, in us-east-1, owned by a specific account, with a specific instance ID — genuinely all the information needed to identify that exact resource unambiguously anywhere in AWS.
05
aws <service> <action> is the CLI's consistent shape across every single AWS service — aws s3 ls, aws ec2 describe-instances, aws iam list-users all follow the identical pattern, meaning learning the CLI's general shape once transfers directly to every new service this course covers, rather than needing to learn an entirely new tool for each one.
06
--profile lets you configure and switch between MULTIPLE separate sets of credentials on one machine (a personal account, a work account, different IAM users with different permission levels) — aws s3 ls --profile work runs that specific command as a genuinely different identity than your default profile, without needing to reconfigure credentials every time you switch contexts.

Code & diagrams

cli-basics.shmarkdown

Configuration, the universal command shape, and reading a real ARN.

# One-time setup, using the IAM user's credentials from Topic 0.3
aws configure
# AWS Access Key ID: ...
# AWS Secret Access Key: ...
# Default region: us-east-1
# Default output format: json

# Confirm which identity you're actually operating as
aws sts get-caller-identity

# The universal shape: aws <service> <action>
aws s3 ls
aws ec2 describe-instances
aws iam list-users

# Reading an ARN — every piece has a specific, consistent meaning
# arn:aws:iam::123456789012:user/your-name
#     |    |         |             |
#  partition service  account-id   the actual resource

# Working with multiple identities on one machine
aws configure --profile work
aws s3 ls --profile work        # runs as the "work" identity specifically
aws s3 ls                        # runs as your default identity

Explain it without notes

Why does an IAM policy reference a resource by its ARN specifically, rather than just its name?

You need to run AWS CLI commands as two genuinely different identities on the same machine, without constantly reconfiguring credentials. What's the correct way to do this?

Practice

Configure the AWS CLI with your own IAM user's credentials and run aws sts get-caller-identity to confirm it returns your expected identity.

Read the ARN arn:aws:s3:::my-app-bucket and arn:aws:lambda:us-west-2:123456789012:function:my-function piece by piece, identifying the service, region (if present), and resource for each.

Trade-offs

↔
The CLI's consistent aws <service> <action> shape makes it genuinely fast to explore and script against once learned, but it also means every single service has its own genuinely large set of possible actions and parameters — nobody memorizes all of it; aws <service> help and the official AWS CLI documentation remain the correct, expected reference tools for anything beyond the handful of commands used routinely, exactly the same reasonable expectation as man pages in Linux's own course.

Done when you can

I can configure the AWS CLI with IAM user credentials and confirm my identity with aws sts get-caller-identity.
I can read and interpret the structure of a real ARN.
I can use named profiles to switch between multiple AWS identities on one machine.