AWS is the world’s largest cloud platform, offering 200+ services for compute, storage, databases, networking, machine learning, and more. This path covers the core services and architectural patterns you need to build production systems.

Prerequisites#

• Networking basics (IP, DNS, HTTP)
• Linux command line
• Basic understanding of servers and databases

1. AWS Global Infrastructure#

Regions and Availability Zones#

flowchart TD
    subgraph AWS Global
        subgraph eu_central ["Region: eu-central-1 (Frankfurt)"]
            AZ1["AZ: eu-central-1a"]
            AZ2["AZ: eu-central-1b"]
            AZ3["AZ: eu-central-1c"]
        end
        subgraph us_east ["Region: us-east-1 (Virginia)"]
            AZ4["AZ: us-east-1a"]
            AZ5["AZ: us-east-1b"]
            AZ6["AZ: us-east-1c"]
        end
    end
    
    AZ1 <-->|"Low-latency links"| AZ2
    AZ2 <-->|"Low-latency links"| AZ3

Choosing a Region#

Consider:

1. Compliance — data residency requirements
2. Latency — proximity to users
3. Service availability — not all services in all regions
4. Cost — pricing varies by region

Key Takeaway#

Design for multi-AZ from the start. A single AZ failure should not take down your application. Regions are isolated — cross-region replication is explicit and costs money.

2. IAM (Identity and Access Management)#

Core Concepts#

flowchart TD
    U["User / Role / Service"] --> P["Policy (JSON)"]
    P --> |"Allow/Deny"| A["Action (s3:GetObject)"]
    A --> R["Resource (arn:aws:s3:::my-bucket/*)"]
    
    subgraph Policy Evaluation
        E1["Explicit Deny?"] -->|Yes| DENY["DENY"]
        E1 -->|No| E2["Explicit Allow?"]
        E2 -->|Yes| ALLOW["ALLOW"]
        E2 -->|No| DENY2["DENY (implicit)"]
    end

Policy Structure#

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::my-bucket/*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": "eu-central-1"
                }
            }
        }
    ]
}

IAM Entities#

Least Privilege Principle#

// BAD — too broad
{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
}

// GOOD — specific actions on specific resources
{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
        "arn:aws:s3:::my-app-assets",
        "arn:aws:s3:::my-app-assets/*"
    ]
}

Key Takeaway#

IAM is the foundation of AWS security. Use roles (not users) for applications. Apply least privilege. Explicit deny always wins. Use conditions to further restrict access.

3. Compute#

EC2 (Elastic Compute Cloud)#

Virtual machines in the cloud:

Lambda (Serverless)#

Run code without managing servers:

# lambda_function.py
import json

def handler(event, context):
    name = event.get("name", "World")
    return {
        "statusCode": 200,
        "body": json.dumps({"message": f"Hello, {name}!"})
    }

ECS/Fargate (Containers)#

flowchart TD
    subgraph ECS Cluster
        SVC["Service (desired count: 3)"]
        SVC --> T1["Task 1"]
        SVC --> T2["Task 2"]
        SVC --> T3["Task 3"]
    end
    
    TD["Task Definition"] --> |"Image, CPU, Memory"| SVC
    ALB["Application Load Balancer"] --> T1
    ALB --> T2
    ALB --> T3

When to Use What#

Key Takeaway#

Default to Fargate for containerized workloads (no server management). Use Lambda for event-driven, short-lived functions. Use EC2 only when you need OS-level control or specific instance types.

4. Storage#

S3 (Simple Storage Service)#

Object storage — unlimited capacity, 99.999999999% (11 nines) durability.

s3://my-bucket/path/to/object.json
       │              │
       bucket         key (not a folder — flat namespace)

EBS (Elastic Block Store)#

Block storage attached to EC2 — like a hard drive:

EFS (Elastic File System)#

Shared file system — multiple EC2/containers can mount simultaneously. NFS protocol. Auto-scales.

Key Takeaway#

S3 for objects (files, backups, static assets). EBS for block storage (databases, OS volumes). EFS for shared file systems (multiple instances need the same files).

5. Databases#

RDS (Relational Database Service)#

Managed relational databases:

Multi-AZ: Synchronous replication to standby in another AZ. Automatic failover.

Read Replicas: Asynchronous replication for read scaling. Up to 15 replicas.

DynamoDB#

Fully managed NoSQL (key-value + document):

Table: Orders
├── Partition Key: customer_id
├── Sort Key: order_date
└── Attributes: items, total, status

Access patterns drive table design — unlike relational databases, you design DynamoDB tables around your queries, not your data model.

ElastiCache#

Managed Redis or Memcached:

Key Takeaway#

Use RDS/Aurora for relational data with complex queries. Use DynamoDB for high-scale, simple access patterns. Use ElastiCache to reduce database load and improve latency.

6. Networking: VPC#

VPC Architecture#

flowchart TD
    subgraph VPC ["VPC: 10.0.0.0/16"]
        subgraph AZ1 ["AZ: eu-central-1a"]
            PUB1["Public Subnet: 10.0.1.0/24"]
            PRIV1["Private Subnet: 10.0.10.0/24"]
        end
        subgraph AZ2 ["AZ: eu-central-1b"]
            PUB2["Public Subnet: 10.0.2.0/24"]
            PRIV2["Private Subnet: 10.0.20.0/24"]
        end
        
        IGW["Internet Gateway"]
        NAT["NAT Gateway"]
    end
    
    Internet["Internet"] --> IGW
    IGW --> PUB1
    IGW --> PUB2
    PUB1 --> NAT
    NAT --> PRIV1
    NAT --> PRIV2

Components#

Security Groups vs NACLs#

Subnet Design#

VPC: 10.0.0.0/16 (65,536 IPs)
├── Public subnets (internet-facing)
│   ├── 10.0.1.0/24 (AZ-a) — ALB, NAT Gateway, bastion
│   ├── 10.0.2.0/24 (AZ-b)
│   └── 10.0.3.0/24 (AZ-c)
├── Private subnets (application tier)
│   ├── 10.0.10.0/24 (AZ-a) — ECS tasks, EC2 instances
│   ├── 10.0.20.0/24 (AZ-b)
│   └── 10.0.30.0/24 (AZ-c)
└── Data subnets (database tier)
    ├── 10.0.100.0/24 (AZ-a) — RDS, ElastiCache
    ├── 10.0.110.0/24 (AZ-b)
    └── 10.0.120.0/24 (AZ-c)

Key Takeaway#

Put load balancers in public subnets, applications in private subnets, databases in isolated subnets. Use security groups for instance-level control. Design for multi-AZ from day one.

7. Load Balancing#

Application Load Balancer (ALB)#

Layer 7 (HTTP/HTTPS) — content-based routing:

flowchart LR
    Client --> ALB["ALB"]
    ALB -->|"/api/*"| TG1["Target Group: API"]
    ALB -->|"/static/*"| TG2["Target Group: Static"]
    ALB -->|"Host: admin.*"| TG3["Target Group: Admin"]
    
    TG1 --> I1["Instance 1"]
    TG1 --> I2["Instance 2"]
    TG2 --> I3["Instance 3"]

Routing rules: path-based, host-based, header-based, query string, source IP.

Network Load Balancer (NLB)#

Layer 4 (TCP/UDP) — ultra-high performance:

Health Checks#

Target Group Health Check:
- Protocol: HTTP
- Path: /health
- Healthy threshold: 3 consecutive successes
- Unhealthy threshold: 2 consecutive failures
- Interval: 30 seconds
- Timeout: 5 seconds

Key Takeaway#

Use ALB for HTTP workloads (most web applications). Use NLB for TCP/UDP or when you need static IPs and extreme performance. Always configure health checks.

8. DNS: Route 53#

Record Types#

Routing Policies#

Key Takeaway#

Use Alias records for AWS resources (free, supports zone apex). Use latency-based routing for multi-region deployments. Route 53 health checks enable automatic failover.

9. Messaging#

SQS (Simple Queue Service)#

Fully managed message queue:

flowchart LR
    P["Producer"] --> Q["SQS Queue"]
    Q --> C1["Consumer 1"]
    Q --> C2["Consumer 2"]
    Q --> C3["Consumer 3"]

Dead Letter Queue (DLQ): Messages that fail processing N times are moved to a DLQ for investigation.

SNS (Simple Notification Service)#

Pub/sub — one message to many subscribers:

flowchart LR
    P["Publisher"] --> T["SNS Topic"]
    T --> S1["SQS Queue"]
    T --> S2["Lambda"]
    T --> S3["Email"]
    T --> S4["HTTP endpoint"]

EventBridge#

Event bus for event-driven architectures:

{
    "source": "com.myapp.orders",
    "detail-type": "OrderCreated",
    "detail": {
        "orderId": "12345",
        "customerId": "67890",
        "total": 99.99
    }
}

Rules match events and route to targets (Lambda, SQS, Step Functions, etc.).

When to Use What#

Key Takeaway#

SQS for point-to-point decoupling. SNS for fan-out. EventBridge for event-driven architectures with complex routing rules. Combine them: SNS → SQS for reliable fan-out with buffering.

10. Monitoring#

CloudWatch#

Key Metrics to Monitor#

CloudTrail#

Audit log of all API calls in your AWS account:

• Who did what, when, from where
• Essential for security and compliance
• Enable in all regions

X-Ray#

Distributed tracing — follow a request across services:

Client → ALB → Service A → Service B → DynamoDB
                    └→ SQS → Lambda → S3

Key Takeaway#

CloudWatch for metrics and logs. CloudTrail for audit. X-Ray for distributed tracing. Set up alarms on critical metrics before you need them.

11. Containers: ECS, ECR, EKS#

ECR (Elastic Container Registry)#

Private Docker registry:

# Authenticate
aws ecr get-login-password | docker login --username AWS --password-stdin $ACCOUNT.dkr.ecr.$REGION.amazonaws.com

# Build and push
docker build -t my-app .
docker tag my-app:latest $ACCOUNT.dkr.ecr.$REGION.amazonaws.com/my-app:latest
docker push $ACCOUNT.dkr.ecr.$REGION.amazonaws.com/my-app:latest

ECS Task Definition#

{
    "family": "my-app",
    "cpu": "256",
    "memory": "512",
    "networkMode": "awsvpc",
    "containerDefinitions": [
        {
            "name": "app",
            "image": "123456789.dkr.ecr.eu-central-1.amazonaws.com/my-app:latest",
            "portMappings": [{ "containerPort": 8080 }],
            "environment": [
                { "name": "ENV", "value": "production" }
            ],
            "secrets": [
                { "name": "DB_PASSWORD", "valueFrom": "arn:aws:secretsmanager:..." }
            ],
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-group": "/ecs/my-app",
                    "awslogs-region": "eu-central-1"
                }
            }
        }
    ]
}

ECS vs EKS#

Key Takeaway#

ECS + Fargate is the simplest path to running containers on AWS. Use EKS only if you need Kubernetes specifically (multi-cloud, existing K8s expertise, specific K8s features).

12. Serverless Patterns#

API Gateway + Lambda + DynamoDB#

flowchart LR
    C["Client"] --> AG["API Gateway"]
    AG --> L["Lambda"]
    L --> D["DynamoDB"]
    L --> S["S3"]
    
    AG --> |"Auth"| COG["Cognito"]

Event-Driven Processing#

flowchart LR
    S3["S3 (file upload)"] --> L1["Lambda (process)"]
    L1 --> DDB["DynamoDB"]
    L1 --> SNS["SNS (notify)"]
    SNS --> L2["Lambda (email)"]
    SNS --> SQS["SQS (queue)"]
    SQS --> L3["Lambda (batch)"]

Serverless Benefits and Limitations#

Key Takeaway#

Serverless is ideal for event-driven, variable-traffic workloads. Not ideal for long-running processes, consistent high-throughput, or when you need full runtime control.

13. Well-Architected Framework#

Six Pillars#

flowchart TD
    WAF["Well-Architected Framework"] --> P1["Operational Excellence"]
    WAF --> P2["Security"]
    WAF --> P3["Reliability"]
    WAF --> P4["Performance Efficiency"]
    WAF --> P5["Cost Optimization"]
    WAF --> P6["Sustainability"]

Design Principles#

• Design for failure — everything fails, plan for it
• Decouple components — reduce blast radius
• Think parallel — scale horizontally
• Automate everything — infrastructure, deployments, recovery
• Use managed services — reduce undifferentiated heavy lifting
• Measure everything — you can’t improve what you don’t measure

Key Takeaway#

The Well-Architected Framework is a checklist for production readiness. Review it before launching any system. Focus on reliability and security first — cost optimization comes after you have a working, secure system.

Summary#

AWS is vast. Start with VPC + ECS/Fargate + RDS + S3 + ALB — that covers 80% of web application needs. Add services as requirements demand, not because they exist.