Regions / AZs

// 1) The hierarchy
// AWS
// └── Region                       e.g. ap-southeast-2 (Sydney), us-east-1 (N. Virginia)
//     └── Availability Zone        e.g. ap-southeast-2a, 2b, 2c  (multiple data centres)
//         └── Edge / Cluster        physical buildings
//
// • Resources are scoped to a Region (or sometimes a specific AZ)
// • Most AWS services are Region-isolated; an S3 bucket in us-east-1 is a SEPARATE bucket from same-named in eu-west-1
// • Some services are Global: IAM, Route 53, CloudFront, WAF (mostly), Organizations

// 2) Pick a Region
awscli> aws ec2 describe-regions --query 'Regions[].RegionName' --output table
// Common choices for an Australian audience:
//   ap-southeast-2 (Sydney)      — lowest AU latency, AU data residency
//   ap-southeast-4 (Melbourne)   — newer; check service coverage
//   us-east-1 (N. Virginia)       — biggest, cheapest, every service
//   us-west-2 (Oregon)           — green energy, full service coverage
//   eu-west-2 (London)            — UK data residency

// 3) Why region choice matters
// LATENCY
//   Round-trip from Sydney to:
//   ap-southeast-2 ≈ <10 ms
//   us-east-1       ≈ 200 ms
//   eu-west-1       ≈ 270 ms
// PRICING
//   EC2 + bandwidth costs differ by 10-30% across Regions
//   Free Tier is per-account, not per-Region
// COMPLIANCE
//   Data residency rules (Australian Privacy Principles, GDPR, HIPAA)
//   Some workloads can't leave a country/Region
// SERVICE COVERAGE
//   New services land in us-east-1 first; some never reach smaller Regions
//   Check https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services
// COST OF TRANSFER
//   Cross-Region data transfer is EXPENSIVE ($0.02-0.09/GB depending on direction)
//   In-Region traffic is cheap or free; cross-AZ is small but billable

// 4) Availability Zones
// • Each Region has 2-6 AZs
// • AZs are physically separated (km apart) with independent power, cooling, network
// • Spread workloads across >= 2 AZs to survive a single-AZ outage
awscli> aws ec2 describe-availability-zones --region ap-southeast-2 --query 'AvailabilityZones[].ZoneName'
// ap-southeast-2a, 2b, 2c
// NOTE: zone names are per-ACCOUNT (us-east-1a in account A may be us-east-1b in account B —
// AWS randomises to balance load). Use ZoneId for consistency across accounts.

// 5) Multi-AZ patterns
// • RDS Multi-AZ: synchronous replica in another AZ; automatic failover
// • Aurora: storage spans 3 AZs by default; up to 15 read replicas
// • DynamoDB: replicates across 3 AZs automatically
// • EC2: Auto Scaling Group across >= 2 AZs; ALB targets multiple subnets
// • S3: redundantly stored across 3+ AZs in the Region — no setup needed

// 6) Pick the Region in the SDK / CLI
// JS SDK v3
import { S3Client } from '@aws-sdk/client-s3';
const s3 = new S3Client({ region: 'ap-southeast-2' });

// Boto3
import boto3
s3 = boto3.client('s3', region_name='ap-southeast-2')

// CLI
awscli> aws s3 ls --region ap-southeast-2
awscli> AWS_REGION=ap-southeast-2 aws s3 ls
awscli> aws configure set region ap-southeast-2

// Terraform
provider "aws" {
    region = "ap-southeast-2"
}

// 7) Working across Regions
// • Provision a stack in each Region you need (Terraform/CDK with one provider per Region)
// • Use Route 53 latency-based or geolocation routing to send users to the nearest copy
// • Replicate critical data:
//     S3: CRR / SRR (Cross-Region / Same-Region Replication)
//     DynamoDB Global Tables: multi-Region active-active
//     Aurora Global Database: low-latency cross-Region read + DR
//     RDS: cross-Region read replicas (asynchronous)
//     KMS: multi-Region keys for cross-Region encryption operations

// 8) Latency-based routing example (Route 53)
awscli> aws route53 change-resource-record-sets --hosted-zone-id Z1 --change-batch '{
    "Changes": [{
        "Action": "UPSERT",
        "ResourceRecordSet": {
            "Name": "api.example.com", "Type": "A",
            "SetIdentifier": "sydney", "Region": "ap-southeast-2",
            "AliasTarget": { "DNSName": "alb-sydney…", "HostedZoneId": "Z…", "EvaluateTargetHealth": true }
        }
    }]
}'

// 9) Edge networks
// CloudFront — 600+ POPs globally; cache assets at edge
// Global Accelerator — anycast IPs route traffic to nearest healthy Region
// AWS Wavelength / Local Zones — closer to specific metro areas (5G, low-latency apps)
// AWS Outposts — racks on YOUR premises running AWS services with low-latency to local apps

// 10) GovCloud + China Regions
// • us-gov-west-1, us-gov-east-1 — separate IAM, separate console, contractors / DOD
// • cn-north-1, cn-northwest-1 — operated by AWS China partners; separate accounts
// You need explicit access and separate accounts for these.

// 11) Disaster recovery — pick a target Region
// • Pilot light: keep core data replicated; spin up compute only on failover
// • Warm standby: scaled-down version always running
// • Active-active: full capacity in 2+ Regions (most expensive, lowest RTO)
// • Decide RTO (how fast must we recover?) and RPO (how much data loss is acceptable?) before architecture

// 12) Cost-saving tip — Spot, Savings Plans, Reserved
// Spot pricing differs across Regions; sometimes cheaper to run batch jobs in us-east-1 even with transfer cost
// Savings Plans are Region-specific; if you move workloads, the plan may stop applying

// 13) Service quotas — per Region
// EC2 instance counts, EBS storage, EIPs — all have per-Region soft limits
awscli> aws service-quotas list-service-quotas --service-code ec2 --region ap-southeast-2
// Request increases ahead of launches; quota grants can take days.

// 14) Sovereign cloud + data residency
// • If contracts require data to stay in Australia: use ap-southeast-2 / -4
// • Many AWS services log to us-east-1 by default — audit endpoints carefully
// • Enable AWS Config to detect resources created in non-approved Regions

// 15) Restrict to approved Regions via SCP (Organizations)
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
            "StringNotEquals": {
                "aws:RequestedRegion": ["ap-southeast-2", "us-east-1"]
            }
        }
    }]
}
// Attach as a Service Control Policy. Even an account admin can't create resources outside the allowlist.

// 16) Common bugs
//   • Resources created in the wrong Region — easy to do via console region picker; use SCPs
//   • Cross-Region transfer fees blow the budget — check the bill ALWAYS before doing replication at scale
//   • SDK falls back to us-east-1 if no region set — set AWS_REGION in env
//   • IAM is global but assumes US-style account; some role chaining is Region-aware (STS endpoints)
//   • S3 bucket names are GLOBAL — same name can't exist in two Regions even though buckets are Regional
//   • SES + KMS + ACM are per-Region; certificates issued in one Region can't be used by CloudFront unless in us-east-1
//   • Service rollout — assuming a feature exists in your Region; check the regional services page before designing for it

# us-east-1 (N. Virginia) is largest, oldest, cheapest for many things.
# Pick the region closest to your users.