Global infrastructure and accounts

Where AWS runs your resources, how accounts separate them, and how you talk to AWS from a terminal.

Regions

Also called AWS region, eu-west-2, us-east-1

What: A region is a separate geographic cluster of data centres, such as eu-west-2 (London). Most services are regional: a bucket, VPC or database lives in exactly one region and is managed there.
Why: The region sets latency to users, price, which services and instance types exist, and where data legally resides.

Watch out

Forgetting that the console and CLI act on one region at a time, then thinking resources have vanished when they are in another region.

Availability zones

Also called AZ, multi-AZ

What: Each region has several availability zones: one or more data centres with independent power, cooling and networking, linked by low-latency private fibre. Zone names such as eu-west-2a map to different physical zones per account.
Why: Spreading instances, subnets and databases across at least two zones lets a workload survive the loss of one data centre, which is the baseline for high availability on AWS.

Watch out

Running everything in one zone to save a little on cross-zone data transfer, then losing the whole service in a zone outage.

Edge locations and global services

Also called points of presence, PoP

What: Edge locations are hundreds of smaller sites in cities worldwide that run CloudFront, Route 53 and Global Accelerator close to users. A few services, including IAM and Route 53, are global rather than regional.
Why: Edge sites cut latency for content and DNS, and global services explain why an IAM role works in every region without being copied.

Shared responsibility model

What: AWS secures the cloud: hardware, facilities, the hypervisor and managed service internals. You secure what you put in it: identities, data, network rules, operating systems on EC2 and your code. The split shifts towards AWS as services become more managed.
Why: It tells you what you must patch and configure yourself. Almost every cloud breach is a customer misconfiguration, not a provider failure.
Example: On EC2 you patch the OS. On RDS, AWS patches the database engine but you still own users, network access and encryption settings. On Lambda you own only code and permissions.

Accounts and the root user

Also called AWS account, account ID

What: An AWS account is a container for resources and the hard boundary for billing, quotas and security. It is created with a root user that has unrestricted access and cannot be limited by IAM policies.
Why: Using separate accounts for production, staging and experiments means a mistake or breach in one cannot touch the others, which IAM alone does poorly.

Watch out

Using the root user day to day or giving it access keys. Protect it with MFA, lock the credentials away and use it only for the few tasks that need it.

AWS Organizations and SCPs

Also called service control policy, OU, Control Tower, landing zone

What: Organizations groups accounts under a management account, arranged in organisational units, with consolidated billing. Service control policies set the maximum permissions for accounts in an OU. Control Tower builds a governed multi-account setup, called a landing zone, on top.
Why: SCPs enforce guardrails no account admin can bypass, such as denying unused regions or blocking CloudTrail from being turned off.

Watch out

Expecting an SCP to grant access. SCPs only limit; a user still needs an IAM policy that allows the action. SCPs also do not apply to the management account.

ARNs

Also called Amazon Resource Name

What: An ARN uniquely names a resource: arn:partition:service:region:account-id:resource. Global or account-less services leave parts empty, as in arn:aws:s3:::my-bucket.
Why: Policies, CLI calls and cross-service wiring all reference resources by ARN, and wildcards in ARNs set how far a permission reaches.
Example: arn:aws:iam::123456789012:role/app-api is an IAM role (no region, since IAM is global). arn:aws:s3:::uploads/* is every object in the uploads bucket.

AWS CLI, profiles and queries

Also called aws configure, JMESPath, --query

What: The AWS CLI calls every service API from a shell. Named profiles hold credentials and a default region; --query filters JSON output with JMESPath and --output sets the format.
Why: Scripts, runbooks and quick checks all use the CLI. aws sts get-caller-identity answers the first question of any access problem: who am I right now?

Shell

aws configure sso --profile dev
aws sso login --profile dev
export AWS_PROFILE=dev
aws sts get-caller-identity
aws ec2 describe-instances \
  --query 'Reservations[].Instances[].InstanceId' \
  --output text

Watch out

Long-lived access keys in ~/.aws/credentials. Prefer IAM Identity Center sign-in, which issues short-lived credentials.

Go deeper