AWS

AWS#

Amazon Web Services is the largest public cloud by revenue and catalog. The reference implementation of “infrastructure as an API”; almost every cross-cloud abstraction tracks an AWS service name as the original. The operator who picks up AWS first has the easiest time reading every other provider’s documentation later.

Reference architecture#

A classic cloud-native web application on AWS: stateless compute in an Auto Scaling group split across two Availability Zones, behind an Elastic Load Balancer, against a managed relational database, with object storage for assets and backups and an email path for operational notifications.

        flowchart LR
    users([Users])

    subgraph region[AWS Region]
        direction LR
        elb[Elastic Load Balancer]

        subgraph vpc[VPC]
            direction TB

            subgraph asg[EC2 Auto Scaling group]
                direction LR
                subgraph az1[Availability Zone 1]
                    ec2a[EC2 Instance]
                end
                subgraph az2[Availability Zone 2]
                    ec2b[EC2 Instance]
                end
            end

            rds[("RDS DB Instance<br/>(with regular backups)")]
        end

        ses[Amazon SES]
        s3[(Amazon S3)]
        email([Email Notification])
    end

    users --> elb
    elb --> ec2a
    elb --> ec2b
    ec2a --> rds
    ec2b --> rds
    rds -- monitoring --> email
    rds -- "Simple Email Service" --> ses
    ses --> s3
    rds -- backups --> s3

    classDef aws-compute   fill:#FF9900,stroke:#cc7700,color:#fff;
    classDef aws-network   fill:#8C4FFF,stroke:#6b3acc,color:#fff;
    classDef aws-db        fill:#3B48CC,stroke:#2a36a3,color:#fff;
    classDef aws-storage   fill:#3F8624,stroke:#2b5e19,color:#fff;
    classDef aws-messaging fill:#D13212,stroke:#a82710,color:#fff;
    classDef aws-external  fill:#545b64,stroke:#3a3f47,color:#fff;

    class ec2a,ec2b aws-compute;
    class elb aws-network;
    class rds aws-db;
    class s3 aws-storage;
    class ses aws-messaging;
    class users,email aws-external;

The shape carries three operator stories at once.

High availability across two AZs. The Auto Scaling group spreads identical EC2 instances across Availability Zone 1 and Availability Zone 2. The ELB health-checks each instance and routes only to healthy targets; the loss of an entire AZ costs roughly half the capacity, not the service.
Managed DB with backups. RDS holds the durable state. The arrow to S3 is the operator’s backup path (RDS automated backups land in S3 under the hood; cross-region copies belong here too). Cross-AZ replication for RDS is enabled with Multi-AZ deployments and gives a synchronous standby in the second AZ without changing the diagram shape.
Email path. Operational notifications (alarm digests, health summaries) leave through Amazon SES to the operator’s inbox. The Email Notification node is the receiving inbox, outside the AWS boundary.

CDN edge#

CloudFront fronts the origins (MediaPackage and MediaStore for streaming media, S3 for static objects) and serves viewers from a two-tier cache. Regional Edge Caches sit between the origin and the edge locations; edge locations are the points of presence that terminate the viewer connection. The operator reaches for this shape any time the bytes are larger than the request rate or the audience is geographically wide.

        flowchart LR
    mp[AWS Elemental MediaPackage]
    ms[AWS Elemental MediaStore]
    s3[(Amazon S3)]

    cf[Amazon CloudFront]

    subgraph dist[CloudFront Distribution]
        direction LR
        rec1[Regional Edge Cache]
        rec2[Regional Edge Cache]

        subgraph edges1[Edge locations]
            direction TB
            e1a[Edge location]
            e1b[Edge location]
        end

        subgraph edges2[Edge locations]
            direction TB
            e2a[Edge location]
            e2b[Edge location]
        end
    end

    v1([Viewers])
    v2([Viewers])
    v3([Viewers])
    v4([Viewers])

    mp --> cf
    ms --> cf
    s3 --> cf
    cf --> rec1
    cf --> rec2
    rec1 --> e1a
    rec1 --> e1b
    rec2 --> e2a
    rec2 --> e2b
    e1a --> v1
    e1b --> v2
    e2a --> v3
    e2b --> v4

    classDef aws-network   fill:#8C4FFF,stroke:#6b3acc,color:#fff;
    classDef aws-storage   fill:#3F8624,stroke:#2b5e19,color:#fff;
    classDef aws-messaging fill:#D13212,stroke:#a82710,color:#fff;
    classDef aws-external  fill:#545b64,stroke:#3a3f47,color:#fff;

    class cf,rec1,rec2,e1a,e1b,e2a,e2b aws-network;
    class s3 aws-storage;
    class mp,ms aws-messaging;
    class v1,v2,v3,v4 aws-external;

Two operator notes on the shape.

Cache hierarchy. Regional Edge Caches absorb the long tail the edge locations miss, so a cold object hits the origin once per region rather than once per edge. Sizing the origin for the regional hit rate, not the viewer rate, is the cost trick that makes CloudFront economical.
Origins are interchangeable. S3, MediaStore, MediaPackage, an ALB, or an external HTTP endpoint can all sit upstream of the same distribution. The diagram swaps the leftmost column without changing the rest of the shape.

Data pipeline#

A three-section reference for an analytics-heavy AWS estate. The Web Application column terminates HTTP at API Gateway, fans each verb out to a per-endpoint Lambda, and writes through to DynamoDB while teeing every event into a Kinesis stream. The Data Analytics Pipeline drains the stream through Firehose into S3 blob storage for web-session and usage-analytics data, queries the lake with Athena on a cron, and lands query output back in S3. The Data Warehouse column reacts to those S3 writes, fans through SQS into an EKS data cluster, and lands the modelled rows in Redshift.

        flowchart RL
    subgraph webapp[Web Application]
        direction RL
        api[API Gateway]
        c[Create Endpoint]
        r[Read Endpoint]
        u[Update Endpoint]
        d[Delete Endpoint]
        lc[Lambda]
        lr[Lambda]
        lu[Lambda]
        ld[Lambda]
        ddb[(DynamoDB)]
        ks[Kinesis Stream]
    end

    subgraph pipeline[Data Analytics Pipeline]
        direction RL
        sc[Stream Consumer Lambda]
        fh1[Firehose<br/>Web Session]
        fh2[Firehose<br/>Usage Analytics]
        s3a[(S3 Blob Storage)]
        s3b[(S3 Blob Storage)]
        athena[Athena]
        cron[CRON ETL Lambda]
        qout[(S3 Query Output)]
    end

    subgraph warehouse[Data Warehouse]
        direction LR
        etl[S3 Triggered ETL Lambda]
        sqs[SQS]
        eks[EKS Data Cluster]
        rs[(Redshift)]
    end

    api --> c --> lc --> ddb
    api --> r --> lr --> ddb
    api --> u --> lu --> ks
    api --> d --> ld --> ks
    ks --> sc
    sc --> fh1 --> s3a
    sc --> fh2 --> s3b
    cron --> athena --> qout
    qout --> etl
    etl --> sqs --> eks --> rs
    eks -.-> s3a

    classDef aws-compute   fill:#FF9900,stroke:#cc7700,color:#fff;
    classDef aws-network   fill:#8C4FFF,stroke:#6b3acc,color:#fff;
    classDef aws-db        fill:#3B48CC,stroke:#2a36a3,color:#fff;
    classDef aws-storage   fill:#3F8624,stroke:#2b5e19,color:#fff;
    classDef aws-messaging fill:#D13212,stroke:#a82710,color:#fff;

    class lc,lr,lu,ld,sc,cron,etl,eks aws-compute;
    class api,c,r,u,d,athena aws-network;
    class ddb,rs aws-db;
    class s3a,s3b,qout aws-storage;
    class ks,fh1,fh2,sqs aws-messaging;

Three patterns to notice.

Write-through plus tee. Each mutating verb writes the authoritative copy to DynamoDB and tees a copy onto Kinesis. Reads stay synchronous, writes feed analytics asynchronously.
S3 as the lake. Firehose, Athena query output, and any upstream ingest all land in the same S3 layer. Lifecycle policies, partitioning, and the manifest format are the decisions the operator owns; everything else upstream of the warehouse is replaceable.
Event-triggered ETL. The warehouse half is driven by S3 put events, not a scheduler. The cron Lambda exists only to drive Athena reports; the modelled tables move when new objects appear.

Account model#

AWS Account is the unit of billing, IAM, and resource isolation. Per-environment accounts (dev, stage, prod) is the recommended default.
AWS Organizations federates many accounts under one payer; Service Control Policies cap permissions across the org.
IAM Identity Center (formerly SSO) is the modern SSO front end; long-lived IAM users are legacy.
AWS Control Tower is the opinionated landing-zone provisioner on top of Organizations + Identity Center + Config + CloudTrail.

Catalog at a glance#

Layer	Headline services
Compute	EC2 (VMs), ECS / Fargate (containers), EKS (Kubernetes), Lambda (FaaS), Batch.
Storage	S3 (object), EBS (block), EFS / FSx (file), Glacier (archive).
Database	RDS (Postgres / MySQL / etc.), Aurora, DynamoDB, ElastiCache, OpenSearch, Redshift, Neptune.
Networking	VPC, Route 53, CloudFront, ELB / ALB / NLB, API Gateway, Transit Gateway, Direct Connect, Global Accelerator.
Identity	IAM, Identity Center, STS, Cognito, KMS, Secrets Manager.
Observability	CloudWatch (metrics / logs / alarms), X-Ray, CloudTrail (audit).
Messaging	SQS, SNS, Kinesis, MSK (Kafka), EventBridge.
Edge / serverless	Lambda@Edge, CloudFront Functions, App Runner, Amplify.

CLI and SDKs#

The aws CLI plus the language SDKs (boto3 for Python, aws-sdk-go for Go, aws-sdk-js for Node) cover every service. The CLI shape is aws <service> <verb> [args].

$ aws configure sso                                  # interactive auth setup
$ aws sts get-caller-identity
$ aws ec2 describe-instances --filters Name=tag:env,Values=prod
$ aws s3 ls s3://my-bucket --recursive --human-readable
$ aws logs tail /aws/lambda/my-fn --follow
$ aws ecs update-service --cluster prod --service web --force-new-deployment

Region and AZ#

A region is geographically isolated (us-east-1, eu-west-1). An availability zone (AZ) is one of several independently powered facilities inside a region (us-east-1a, 1b, 1c). For high availability, spread workloads across AZs; for disaster recovery, replicate across regions.

Pricing model#

On-demand is the default; pay per second or per request.
Savings Plans / Reserved Instances trade a 1- or 3-year commitment for 30-70% off list.
Spot Instances are interruptible EC2 capacity at a 60-90% discount; good for batch, bad for stateful.
Egress is the line item that surprises operators. Inside an AZ is free; cross-AZ has a price; cross-region has a higher one; out to the internet has the highest. Architect to minimize it.

IAM in practice#

The standard pattern:

No IAM users in human accounts. Federate through Identity Center to short-lived role assumption.
IAM roles for workloads (IRSA on EKS, instance profiles on EC2, task roles on ECS, execution roles on Lambda). No static credentials baked into images or env vars.
Cross-account role assumption with sts:AssumeRole rather than per-account IAM users.
CloudTrail on, organization-wide. Logs every API call. Ship to a separate account and S3 bucket the workload accounts cannot delete.

When to pick AWS#

Default choice for greenfield in 2026. Largest catalog, deepest third-party ecosystem.
When the workload needs niche services (Bedrock, FinSpace, Outposts, Ground Station) without a peer at another provider.
When the operator’s existing skills are AWS-shaped.

When to pick something else#

When the team’s stack is deeply Microsoft (Azure) or Google (GCP, BigQuery, Vertex).
When the workload is small and the price floor matters (DigitalOcean, Hetzner, Linode).
When the workload is edge / CDN-centric (Cloudflare).

Datacenter locations#

Code	Location
us-east-1	US East (N. Virginia)
us-east-2	US East (Ohio)
us-west-1	US West (N. California)
us-west-2	US West (Oregon)
af-south-1	Africa (Cape Town)
ap-east-1	Asia Pacific (Hong Kong)
ap-east-2	Asia Pacific (Taipei)
ap-south-1	Asia Pacific (Mumbai)
ap-south-2	Asia Pacific (Hyderabad)
ap-southeast-1	Asia Pacific (Singapore)
ap-southeast-2	Asia Pacific (Sydney)
ap-southeast-3	Asia Pacific (Jakarta)
ap-southeast-4	Asia Pacific (Melbourne)
ap-southeast-5	Asia Pacific (Malaysia)
ap-southeast-6	Asia Pacific (New Zealand)
ap-southeast-7	Asia Pacific (Thailand)
ap-northeast-1	Asia Pacific (Tokyo)
ap-northeast-2	Asia Pacific (Seoul)
ap-northeast-3	Asia Pacific (Osaka)
ca-central-1	Canada (Central, Montreal)
ca-west-1	Canada West (Calgary)
eu-central-1	Europe (Frankfurt)
eu-central-2	Europe (Zurich)
eu-west-1	Europe (Ireland)
eu-west-2	Europe (London)
eu-west-3	Europe (Paris)
eu-north-1	Europe (Stockholm)
eu-south-1	Europe (Milan)
eu-south-2	Europe (Spain)
il-central-1	Israel (Tel Aviv)
me-south-1	Middle East (Bahrain)
me-central-1	Middle East (UAE)
mx-central-1	Mexico (Central)
sa-east-1	South America (São Paulo)

References#

Cloud for the cross-cloud taxonomy this page slots into.
AWS Documentation
AWS CLI reference
AWS Well-Architected Framework

AWS

Contents