Hello, AWS

The cheat table: Azure → AWS

If you remember nothing else from this chapter, internalize this table. Every concept the rest of the chapter introduces hangs off one of these rows.

Accounts vs Subscriptions

An AWS account is the fundamental unit of billing, security, and resource isolation. It's most similar to an Azure Subscription, but with one important twist: in AWS, the account is also the strongest practical security boundary. AWS culture leans on "use lots of accounts" - one per environment, one per team, sometimes one per workload. In Azure, you tend to use fewer subscriptions and lean on RGs and AAD groups for isolation.

Side-by-side: the hierarchy

Microsoft Entra tenant
  └─ Management Group (root)
      └─ Management Group (corp)
          └─ Subscription (prod)
              └─ Resource Group (rg-web-prod)
                  └─ App Service (myapi)
                  └─ Storage Account (mystg)
                  └─ Key Vault (kv-prod)

AWS Organization (root)
  └─ OU (corp)
      └─ AWS Account (prod, 123456789012)
          └─ # no RG layer
          └─ Lambda (myapi)        # tagged env=prod
          └─ S3 Bucket (mystg)     # tagged env=prod
          └─ Secrets Manager (kv)  # tagged env=prod

Notice the missing layer on the AWS side. The Resource Group concept just isn't there. In AWS, the way you express "these things belong together" is:

• Tags - env=prod, app=web, team=platform. Tags drive cost allocation, automation, and search.
• Naming conventions - prod-web-api, prod-web-bucket. Yes, really. AWS culture leans on naming a lot more than Azure does.
• Account boundaries - if it's a different account, it's already isolated. No additional sub-grouping needed.
• Resource Groups (AWS) - yes, AWS has a feature literally called "Resource Groups", but it's a saved tag-based query, not a parent container. It does not control billing, lifecycle, or IAM scope.

What's in an Account ID?

Regions and Availability Zones

Both clouds have regions (geographic locations) and within each region, multiple availability zones (physically separate data centers). The naming and the way you reference them is where Azure habits break.

Region naming

# Human-readable, location-based
eastus
westeurope
northeurope
australiaeast
japaneast

# Also has paired regions for DR
# eastus  ↔ westus
# pairs are fixed and prescriptive

# Code-style with sequence numbers
us-east-1      # N. Virginia (default)
us-west-2      # Oregon
eu-west-1      # Ireland
ap-southeast-2 # Sydney
ap-northeast-1 # Tokyo

# No "paired regions" concept
# DR pairing is up to you

The us-east-1 thing

us-east-1 matters more than any other region. It's AWS's oldest region, hosts the most services, and is the default for many global services (IAM, Route 53, CloudFront). Many AWS bugs and outages historically center there. If you're picking a region for a "global" service, default to us-east-1. For everything else, pick by proximity to users.

AZs aren't fixed names

Picking your default region

# Set per command
az group create -n rg-test \
  --location eastus

# Or set a CLI default
az configure --defaults \
  location=eastus

# Set per command
aws s3 ls --region us-east-1

# Or set per profile (typical)
aws configure set region us-east-1

# Or via env var (CI/CD)
export AWS_REGION=us-east-1

CLI auth: az login vs aws configure

Installing the AWS CLI

# Homebrew is the easy path
brew install awscli

# Verify
aws --version
# aws-cli/2.15.0 Python/3.11.6 Darwin/23.0.0

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

The two auth styles

AWS has two ways to authenticate the CLI, and you need to know which one your org expects:

Style 1: long-lived access key (old-school)

# Service principal style
az login --service-principal \
  --username <app-id> \
  --password <client-secret> \
  --tenant <tenant-id>

# Token cached in ~/.azure/

# Interactive, prompts for 4 values
aws configure

# AWS Access Key ID: AKIA...
# AWS Secret Access Key: ********
# Default region: us-east-1
# Default output format: json

# Or set directly:
aws configure set aws_access_key_id AKIA...
aws configure set aws_secret_access_key ********

After aws configure, you have a file:

[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[default]
region = us-east-1
output = json

[default]
access_key_id = AKIAIOSFODNN7EXAMPLE
secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Style 2: SSO / Identity Center (modern)

This is the az login equivalent. Browser-based, short-lived tokens, no secrets on your laptop.

# Created once via `aws configure sso`
[profile dev]
sso_session = my-org
sso_account_id = 123456789012
sso_role_name = DeveloperAccess
region = us-east-1

[profile prod]
sso_session = my-org
sso_account_id = 987654321098
sso_role_name = ReadOnlyAccess
region = us-east-1

[sso-session my-org]
sso_start_url = https://my-org.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

# Once per session (~8-12 hour token)
aws sso login --profile dev

# Then every command picks up the token
aws sts get-caller-identity --profile dev
aws s3 ls --profile dev

SSO and Identity Center

In Azure, AAD handles human identity for the whole tenant. In AWS, IAM was originally per-account, which made multi-account life painful (one IAM user per account!). AWS Identity Center (née AWS SSO) fixed that by acting as a federation layer above all your accounts.

Three things to know about Identity Center:

1. It can use AAD as the upstream IDP. Many enterprises run Microsoft Entra for human identity even when their compute is on AWS. Identity Center federates with AAD via SAML or SCIM.
2. It runs in one account (the "management account" of the AWS Organization) but provisions access to all accounts in the org. Users don't need an IAM identity in each account.
3. Tokens are short-lived (default 1-12 hours). When the CLI says ExpiredToken, run aws sso login --profile <name> to refresh.

Profiles and multi-account life

Because AWS pushes you toward multi-account, profiles become essential. Almost every AWS user has at least 2-3 profiles in their ~/.aws/config.

Side-by-side: switching context

# List subscriptions
az account list -o table

# Switch active subscription
az account set --subscription "prod-sub"

# Then all subsequent commands
# use that subscription
az group list

# List configured profiles
aws configure list-profiles

# Pass --profile per command
aws s3 ls --profile prod

# Or set for the shell session
export AWS_PROFILE=prod
aws s3 ls   # now uses prod

A realistic ~/.aws/config

[sso-session my-org]
sso_start_url = https://my-org.awsapps.com/start
sso_region = us-east-1

[profile sandbox]
sso_session = my-org
sso_account_id = 111111111111
sso_role_name = AdministratorAccess
region = us-east-1
output = json

[profile dev]
sso_session = my-org
sso_account_id = 222222222222
sso_role_name = DeveloperAccess
region = us-east-1
output = json

[profile prod-readonly]
sso_session = my-org
sso_account_id = 333333333333
sso_role_name = ReadOnlyAccess
region = us-east-1
output = json

# Role chaining: assume a role in prod from your dev creds
[profile prod-deploy]
source_profile = dev
role_arn = arn:aws:iam::333333333333:role/DeployerRole
region = us-east-1

That last profile is worth a closer look. source_profile + role_arn is the AWS equivalent of "run this command as a different identity that I'm allowed to switch into". You stay authenticated as your normal dev user, but for this profile the CLI silently calls sts:AssumeRole and uses the returned credentials. We'll dig into this in Chapter 2.

Try it: prove you're connected

# If you set up SSO:
aws sso login --profile dev

# If you used aws configure (access keys), skip the login.

aws sts get-caller-identity

{
  "UserId": "AROA...EXAMPLE:sunilt",
  "Account": "123456789012",
  "Arn": "arn:aws:sts::123456789012:assumed-role/DeveloperAccess/sunilt"
}

Bonus: poke around

# What region am I defaulting to?
aws configure get region

# What regions exist?
aws ec2 describe-regions \
  --query 'Regions[].RegionName' --output table

# Any S3 buckets in this account?
aws s3 ls

# Account-level summary (free)
aws iam get-account-summary

Quick check

Gotchas for Azure devs

Project Compass: a service you'll build across the doc

From here on, every chapter has a Project Compass section that advances one fictional NVIDIA-flavored service: gfn-reports. It reads GeForce NOW session telemetry from a queue, aggregates it, exposes a query API, and emits alerts. By chapter 12 you'll have wired up almost the whole AWS stack to support it.

Compass exists so you're not learning services in isolation. Each chapter's slice connects to the previous one - the IAM role you create in chapter 2 will get S3 permissions in chapter 5, Lambda permissions in chapter 11, and Terraform-managed in chapter 12.

aws configure sso --profile compass
# Walks through SSO start URL, account, role, region
aws sso login --profile compass
aws sts get-caller-identity --profile compass

aws configure --profile compass
# Paste your access key, region (us-east-1), output (json)
aws sts get-caller-identity --profile compass

Recap & next

What stuck?

• AWS Account = Azure Subscription, but used more aggressively for isolation (one per env, not one per company).
• No Resource Group. Tags + naming + account boundaries do the same job.
• Regions look familiar but use code names (us-east-1) and AZ letters are randomized per account.
• Two auth styles: long-lived access keys (legacy / personal) vs Identity Center SSO (modern / corp). Pick the right one for your context.
• Profiles + AWS_PROFILE are how you switch context between accounts. Equivalent to az account set but more explicit.
• aws sts get-caller-identity is the "who am I" command you'll run constantly.

Common pitfalls so far