1.1 Why cloud exists (the power-plant analogy)

Imagine every apartment building running its own diesel generator in the basement. That is classic on-premises IT: you buy capacity for peak summer heat, pay for it year-round, hire people to maintain it, and still risk blackouts. Cloud computing is the municipal power grid for compute, storage, and networking. You plug in with APIs instead of copper, and you pay for kilowatt-hours of capacity-time rather than owning the turbines.

AWS is one of those grids — the largest by many measures — exposing hundreds of services behind a consistent identity, billing, and regional topology. Your job as an engineer is not to memorize every service logo; it is to understand the control planes (APIs that create/configure) and data planes (paths that carry traffic and bytes), then compose them into reliable systems.

1.2 Service models: IaaS, PaaS, SaaS (and where AWS sits)

Think of building a pizza business. IaaS rents you the kitchen (ovens, counters, utilities) — you bring recipes and chefs. PaaS gives you a managed kitchen line that auto-refills dough — you focus on toppings and orders. SaaS is ordering pizza from an app — you consume the finished product.

• IaaS examples: Amazon EC2, Amazon VPC, Amazon EBS — maximum control, maximum responsibility.
• PaaS-like: Elastic Beanstalk, App Runner, many ECS/EKS patterns with managed control planes — less OS toil.
• SaaS-like: Amazon WorkMail, managed collaboration tools — you configure, rarely SSH.
• Serverless compute: AWS Lambda sits near PaaS but with event-driven billing and no server lifecycle for you to manage.

1.3 Shared Responsibility Model (memorize this early)

AWS is responsible for security of the cloud: data centers, hardware, virtualization hosts, and the managed control planes of services. You are responsible for security in the cloud: identities, network reachability you configure, guest OS patches on EC2, application code, encryption choices, and data classification.

1.4 Prerequisites checklist

1.5 Creating an AWS account (safe day-one sequence)

1. Create the account at aws.amazon.com — verify email and phone.
2. Enable MFA on the root user immediately (hardware key preferred; TOTP app acceptable).
3. Do not create root access keys. Ever, unless a rare break-glass procedure demands it — and then delete them.
4. Create an administrator via IAM Identity Center (recommended) or an IAM user with MFA for daily console use.
5. Turn on AWS CloudTrail (management events) in all Regions via a trail writing to a dedicated S3 bucket.
6. Create a billing alarm / AWS Budget (e.g., actual cost > $5 or $10).
7. Note your 12-digit Account ID; treat it as public-ish metadata, not a secret — but don’t paste credentials anywhere.

Free Tier is a training wheels allowance, not a force field. NAT Gateways, idle load balancers, public IPv4 addresses, and forgotten gp3 volumes are classic “why is my bill $40?” stories.

1.6 Install and verify the AWS CLI (v2)

The CLI is your thin client to every service API. Prefer AWS CLI v2.

macOS (official pkg) or package managers:

# macOS (Homebrew example)
brew install awscli

# Verify
aws --version

# After configuring credentials / SSO:
aws sts get-caller-identity

Modern teams prefer IAM Identity Center (SSO) profiles over long-lived access keys:

aws configure sso
# follow prompts: start URL, Region, account, role
aws sso login --profile my-admin
aws sts get-caller-identity --profile my-admin

Expected shape of a successful identity call:

{
  "UserId": "AROA...:session-name",
  "Account": "123456789012",
  "Arn": "arn:aws:sts::123456789012:assumed-role/..."
}

1.7 Console, APIs, SDKs — one control plane, many cockpits

The AWS Management Console, CLI, Terraform/CloudFormation, and SDKs (boto3, AWS SDK for JavaScript/Java/Go) all speak the same service APIs. If you can do it in the console, there is almost always an API equivalent — and production automation should prefer the API/IaC path so changes are reviewable.

1.8 First-week mission control flow

1.9 Cost primitives you must know before labbing

• On-Demand: flexible, highest unit price — fine for labs if you terminate resources.
• Savings Plans / Reserved Instances: commit spend/usage for discounts — rarely needed for learning accounts.
• Spot: spare capacity at steep discounts with interruption risk — advanced compute module territory.
• Data transfer: ingress often free; egress and cross-AZ/cross-Region transfer can dominate bills.

Bookmark the AWS Pricing Calculator and learn to read Cost Explorer filters by service and Region.

1.10 Multi-account foreshadowing

Serious AWS estates use AWS Organizations: separate accounts for prod, non-prod, security tooling, and logging. Service Control Policies (SCPs) set guardrails. You do not need Organizations on day one of learning — but you should know that a single “playground” account is a sandbox, not a production pattern.

1.11 Lab: prove your cockpit works

1. Sign in as non-root admin with MFA.
2. Confirm billing alerts deliver to your email.
3. Run aws sts get-caller-identity successfully.
4. In the console, open EC2 → Regions dropdown — notice how the world is sliced (Module 02).
5. Intentionally create nothing billable yet; destroy habits beat create habits.

2.1 The infrastructure stack from orbit

Picture Earth from orbit. AWS paints it with Regions — geographic areas like “Europe (Ireland)” or “US East (N. Virginia)”. Zoom in: each Region contains multiple Availability Zones (AZs) — one or more discrete data centers with independent power, cooling, and networking. Zoom to the surface near users: edge locations and regional edge caches accelerate content. Special extensions — Local Zones, Wavelength Zones, and Outposts — push select AWS primitives even closer to metros, 5G networks, or your own data center floor.

2.2 Choosing a Region — the four-constraint problem

Region choice is an engineering + legal + product decision:

1. Latency: place data planes near users and dependent systems.
2. Compliance / residency: some data must not leave a country or union.
3. Service & feature parity: brand-new features often land in a subset of Regions first.
4. Price: the same instance class is not priced identically everywhere.

us-east-1 is historically the “default gravity well”: many tutorials, some global service endpoints, and earliest feature launches. That popularity is not automatically a production recommendation — concentrate risk consciously.

2.3 Availability Zones — failure domains you design against

An AZ is intentionally isolated. AWS interconnects AZs in a Region with high-bandwidth, low-latency links so you can run synchronous systems (Multi-AZ RDS, mirrored application fleets behind a load balancer) without pretending machines share a single rack.

Critical nuance: the label us-east-1a in your account may not be the same physical AZ as us-east-1a in a teammate’s account. AWS remaps letters to balance capacity. For multi-account consistency, use Availability Zone IDs (like use1-az6).

aws ec2 describe-availability-zones --region us-east-1 \
  --query 'AvailabilityZones[*].[ZoneName,ZoneId]' --output table

2.4 High availability patterns on the map

2.5 Edge services you will meet constantly

• Amazon CloudFront: CDN — cache content at PoPs, integrate with WAF, Shield, custom origins.
• Amazon Route 53: authoritative DNS with health checks and routing policies (latency, failover, geolocation).
• AWS Global Accelerator: anycast IPs that ingress onto the AWS backbone for TCP/UDP apps needing stable entry points.
• AWS WAF / Shield: edge-adjacent protection layers (details in security modules).

2.6 Local Zones, Wavelength, Outposts — when the Region is not close enough

2.7 Global vs Regional services (design implications)

Some configurations are global in scope (classic examples students meet early: IAM principals/policies, many Route 53 and CloudFront configurations). Most data services are Regional: an VPC in eu-central-1 does not magically exist in ap-south-1. Your IaC state, DR runbooks, and credential strategies must respect that boundary.

# Explicit Region — never rely on ambient defaults in automation
export AWS_REGION=ap-south-1
aws ec2 describe-vpcs --region ap-south-1

2.8 How VPCs sit on the map (preview)

A VPC is Region-scoped. You carve subnets that each live in exactly one AZ. Public subnets route to an Internet Gateway; private subnets often egress via NAT Gateway (which itself usually sits in a public subnet). Multi-AZ therefore means repeating subnet tiers per AZ — a pattern you will implement in the VPC module with full diagrams.

2.9 Control plane vs data plane (Regional outages make sense now)

When you RunInstances, you talk to a control plane API. The packets your users send to an application flow through the data plane. Architectures that only replicate data planes but forget control-plane dependencies (AMI copies, IaC apply Region, ECR pull-through) fail in surprising ways during DR. Note dependencies explicitly.

2.10 Lab: read the sky map from your account

1. List Regions: aws ec2 describe-regions --query 'Regions[].RegionName' --output text
2. Map AZ names to AZ IDs in two Regions you care about.
3. Open CloudFront in the console — note how distribution config feels “global” compared to EC2.
4. Price-compare a t3.micro in two Regions using the Pricing Calculator.
5. Write three sentences: primary Region, DR Region, and why (latency/compliance/cost).

2.11 Mental model card (keep this)

3.1 Why IAM is the real control plane

Every AWS API call is authenticated (who are you?) and authorized (are you allowed?). IAM answers both for AWS identities. Think of a spacecraft airlock: badges (credentials) prove who you are; door permissions (policies) decide which compartments you may enter. Root is the master key to the whole ship — you almost never use it after day one.

3.2 Principals: users, roles, groups, and the root user

• Root user: account owner identity. MFA on, no access keys, break-glass only.
• IAM users: long-lived identities in one account. Fine for tiny labs; enterprises prefer Identity Center.
• Groups: attach policies to sets of users (permission bundling, not a principal that can sign requests).
• Roles: identities meant to be assumed — temporary credentials via STS. Machines, apps, and humans (via federation) should prefer roles.
• IAM Identity Center (SSO): workforce identities → permission sets → account assignments. The modern human path.

3.3 Policy documents — the grammar of authorization

An identity-based policy is JSON: Version, Statement[] with Effect (Allow/Deny), Action, Resource, and optional Condition. Resource-based policies (S3 bucket policies, KMS key policies, SQS) live on the resource and can name principals in other accounts.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ListOwnBucket",
    "Effect": "Allow",
    "Action": ["s3:ListBucket"],
    "Resource": "arn:aws:s3:::orbit-labs-123",
    "Condition": {
      "StringEquals": { "aws:RequestedRegion": "ap-south-1" }
    }
  }]
}

ARNs address everything: arn:aws:service:region:account:resource. Wildcards (*) are powerful — and dangerous. Prefer least privilege: start narrow, expand with evidence.

3.4 Policy evaluation logic (explicit Deny wins)

Mentally run this algorithm on every request: start from implicit deny → gather all applicable identity policies, resource policies, permission boundaries, SCPs, session policies → if any applicable explicit Deny matches, deny → else if an Allow matches (and SCPs/boundaries permit), allow → else deny.

3.5 Roles & trust policies

A role has two policy faces: permissions policy (what the role can do) and trust policy (who may assume it). EC2 instance profiles, Lambda execution roles, and cross-account access all hinge on trust.

# Trust EC2 to assume this role
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

Cross-account: principal is another account’s root or role ARN; always add ExternalId or org conditions for third-party access patterns.

3.6 Federation & Identity Center

Humans should not live as IAM users with long-lived keys. Federate from Okta/Azure AD/Google via SAML or OIDC into Identity Center, map groups to permission sets, assign to accounts. Temporary credentials rotate automatically; revoke by disabling the IdP user.

3.7 Permission boundaries & SCPs

• Permission boundaries: max permissions a user/role can ever receive — used to safely delegate IAM admin subsets.
• SCPs (Organizations): account-wide ceilings (e.g., deny leaving org, deny disabling CloudTrail, deny Regions). SCPs do not grant; they only restrict.

3.8 Credentials hygiene

• Prefer roles + instance/task profiles over embedding keys.
• If access keys must exist: rotate, scope tightly, never commit to git.
• Enable MFA for console; consider MFA-conditioned API access for sensitive actions.
• Use Access Analyzer and IAM Credential Report regularly.

aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 --decode | head

3.9 Lab: least-privilege role for S3 read

1. Create a role trusted by your IAM user (or SSO role) with only s3:GetObject / s3:ListBucket on one bucket ARN.
2. aws sts assume-role and export temporary keys.
3. Prove list/get works; prove s3:PutObject fails.
4. Add a Deny condition for non-TLS (aws:SecureTransport) on the bucket policy.

4.1 What an instance really is

An EC2 instance is a virtual machine (or bare-metal offering) scheduled onto AWS hardware in an AZ you choose (or that AWS picks). You select a family/size (e.g., t3.micro, m7g.xlarge, c7i.4xlarge), an AMI (boot disk image), networking (subnet, SG, optional public IP), storage (EBS/instance store), and an IAM instance profile.

4.2 Instance families — picking the right chassis

Graviton (g suffix) = Arm — often better price/performance if your stack supports it.

4.3 AMIs, user data, and golden images

An AMI snapshots root volume + launch permissions + block device mapping. User data runs at first boot (cloud-init) for bootstrap. Mature teams bake golden AMIs with Ansible/Packer instead of lengthy user-data scripts — faster boot, fewer snowflakes.

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --subnet-id subnet-aaa \
  --security-group-ids sg-bbb \
  --iam-instance-profile Name=OrbitEC2Role \
  --user-data file://bootstrap.sh

4.4 Instance storage paths

• EBS: network-attached durable volumes (Module 05 deep-dive). Survive stop/start; snapshot to S3-backed backups.
• Instance store: physically attached ephemeral NVMe — blazing fast, gone on stop/hibernate/hardware failure. Use for caches/scratch only.

4.5 Lifecycle: start, stop, hibernate, terminate

Stop keeps EBS, releases ephemeral and typically public IP (Elastic IP stays). Hibernate writes RAM to EBS (supported types/AMIs). Terminate destroys the instance; root EBS deletes by default unless DeleteOnTermination=false.

4.6 Placement groups & tenancy

• Cluster: low latency / high PPS inside one AZ — HPC, tight chatty apps.
• Spread: separate hardware racks — reduce correlated failure for small fleets.
• Partition: large distributed systems (Kafka, Cassandra) with failure domains.
• Dedicated host / dedicated instance: compliance / licensing constraints.

4.7 Purchase options

4.8 Auto Scaling groups & load balancers

An ASG maintains desired capacity across AZs using a launch template. Scale on CPU, ALB request count, custom metrics, or schedules. Pair with ALB/NLB health checks so unhealthy nodes are replaced. Stateless app tiers scale; sticky state belongs in DB/cache/S3.

4.9 Instance metadata & IMDSv2

The metadata service (169.254.169.254) exposes identity credentials for the instance profile. Require IMDSv2 (session-oriented PUT+GET) to mitigate SSRF credential theft. Never treat user-data secrets as safe.

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id

4.10 Lab: launch, tag, verify, destroy

1. Launch t3.micro / t4g.micro in a public subnet with SSH or SSM only from your IP / via SSM Session Manager (preferred — no SSH port).
2. Attach an instance profile that can read one S3 object; prove it from the instance.
3. Create an AMI from the instance; terminate the original; launch from AMI.
4. Delete everything; confirm no leftover EBS volumes or Elastic IPs.

5.1 Choosing storage by access pattern

Analogy: S3 is an infinite warehouse with barcode scanners (object API). EBS is a hard drive bolted to one shuttle (single-instance block). EFS/FSx is a shared network filesystem many shuttles mount at once.

5.2 Amazon S3 — object storage deep dive

Buckets are Region-scoped containers; objects are keys with data + metadata. Durability design target is extremely high (eleven nines classically cited) via checksums and multi-AZ replication inside the Region. Consistency: strong read-after-write for new objects; understand overwrite/list nuances from current docs when building systems.

• Storage classes: Standard, Intelligent-Tiering, Standard-IA, One Zone-IA, Glacier Instant/Flexible/Deep Archive — trade retrieval time vs cost.
• Security: block public access defaults, bucket policies, IAM, SSE-S3 / SSE-KMS / SSE-C, Object Lock for WORM.
• Versioning + MFA Delete: protect against ransomware/oops deletes.
• Lifecycle rules: transition/expire automatically.
• Replication: CRR/SRR for DR and locality.

aws s3 mb s3://orbit-lab-$(aws sts get-caller-identity --query Account --output text) --region ap-south-1
aws s3api put-public-access-block --bucket ... --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
aws s3 cp ./manifest.json s3://orbit-lab-.../data/

5.3 EBS volumes — block for EC2

gp3 is the default general-purpose SSD (baseline IOPS/throughput configurable). io2 for mission-critical high IOPS. st1/sc1 for throughput HDD workloads. Volumes live in one AZ; to move AZs: snapshot → create volume in target AZ → attach.

Snapshots are incremental and stored durably (S3-backed). Encrypt volumes with KMS; snapshots of encrypted volumes stay encrypted.

5.4 EFS & FSx — shared filesystems

• EFS: NFS for Linux, multi-AZ regional file system, scales automatically. Great for shared web content, home dirs, some CMS.
• FSx for Windows / Lustre / NetApp / OpenZFS: specialized performance and protocol needs (HPC scratch, Windows SMB, enterprise NAS).

5.5 Moving data at scale

• S3 Transfer Acceleration / multipart upload: large object efficiency.
• AWS DataSync: online sync NAS ↔ S3/EFS/FSx.
• Snow Family: petabyte offline ship-the-box when networks choke.
• Storage Gateway: hybrid file/volume/tape illusions over cloud backends.

5.6 Cost & performance traps

• Small-object chatty workloads can burn request costs on S3.
• Cross-AZ EFS mount targets and data transfer add charges.
• Orphaned EBS volumes and old snapshots silently bill for months.
• Public S3 misconfig is still a top breach pattern — Access Analyzer + Block Public Access.

5.7 Lab: secure bucket + lifecycle + EBS snapshot

1. Create a private bucket; enable versioning and default SSE-S3 or SSE-KMS.
2. Add lifecycle: transition logs/ to IA after 30 days; expire noncurrent versions after 90.
3. Attach a gp3 volume to a lab instance; write a file; snapshot; restore to a new volume.
4. Tear down; verify zero leftover volumes/snapshots you do not intend to keep.

6.1 VPC & CIDR planning

A VPC is a Region-scoped isolated network. You assign an IPv4 CIDR (commonly 10.0.0.0/16) and optionally IPv6. Plan non-overlapping CIDRs across accounts for future peering/TGW. Subnets carve the VPC into AZ-local segments — each subnet lives in exactly one AZ.

# Example allocation
# VPC:           10.20.0.0/16
# Public AZ-a:   10.20.0.0/24
# Public AZ-b:   10.20.1.0/24
# Private AZ-a:  10.20.10.0/24
# Private AZ-b:  10.20.11.0/24
# Data AZ-a:     10.20.20.0/24
# Data AZ-b:     10.20.21.0/24

6.2 Route tables, IGW, NAT

• Internet Gateway (IGW): horizontally scaled VPC attachment for public internet. Public subnet: route 0.0.0.0/0 → igw-… plus public/Elastic IP on the ENI.
• NAT Gateway: managed egress for private subnets (0.0.0.0/0 → nat-…). Place in public subnet; one per AZ for HA. Costs add up — watch idle NAT.
• Egress-only IGW: IPv6 private→internet without inbound.

6.3 Security Groups vs Network ACLs

Prefer SG references (SG-id as source) over wide CIDRs for tier-to-tier traffic: ALB-SG → App-SG → DB-SG on 5432 only.

6.4 VPC endpoints — private path to AWS APIs

• Gateway endpoints: S3 and DynamoDB via route table prefixes — no NAT needed for those.
• Interface endpoints (PrivateLink): ENIs in your subnets for SSM, ECR, Secrets Manager, etc. Pay hourly + data; buy security and private routing.

6.5 Connecting networks

• VPC Peering: 1:1, non-transitive. Good for simple pairs; CIDRs must not overlap.
• Transit Gateway: hub-and-spoke for many VPCs/VPN/Direct Connect — transitive routing hub.
• Site-to-Site VPN / Direct Connect: hybrid on-prem connectivity (DX for consistent private bandwidth).
• PrivateLink: expose a service ENI-to-ENI without sharing the whole VPC CIDR.

6.6 DHCP, DNS, and reachability mental model

VPC DNS (enableDnsHostnames / enableDnsSupport) matters for private hosted zones and interface endpoints. Debug with: route tables → NACL → SG → OS firewall → app bind address. VPC Reachability Analyzer automates path proofs.

6.7 Lab: build a two-AZ skeleton

1. Create VPC /16 with 2 public + 2 private subnets across AZs.
2. Attach IGW; public routes to IGW; private routes to NAT in matching AZ.
3. Launch bastion or (better) VPC endpoints for SSM — no SSH from 0.0.0.0/0.
4. Private instance: confirm outbound HTTPS via NAT; confirm no inbound from internet.
5. Add S3 gateway endpoint; prove private subnet can aws s3 ls without NAT dependency for S3.

6.8 Mental model card

7.1 Choosing a database — access pattern first

Analogy: a relational DB is a meticulously indexed ship’s log (joins, transactions, schema). DynamoDB is a bank of sealed lockers addressed by key (massive scale, simple access patterns). ElastiCache is the whiteboard next to the pilot — blazing fast, intentionally forgetful. Pick from queries and consistency needs, not from logo familiarity.

7.2 Amazon RDS — managed relational engines

RDS runs engines you know (PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Db2) with automated patching options, backups, Multi-AZ failover, and read replicas. You still design schema, indexes, and connection pooling — AWS runs the host and managed control plane.

• Multi-AZ: synchronous standby in another AZ; failover on primary failure (high availability, not a read scale-out by itself on classic Multi-AZ).
• Read replicas: async copies for read scale (and cross-Region DR patterns).
• Parameter / option groups: engine knobs without SSH to the box.
• Storage: gp3/io autoscaling patterns; monitor free storage and IOPS.

7.3 Amazon Aurora — cloud-native relational

Aurora re-architects the storage layer: a distributed, self-healing volume replicated across AZs, with compute (writer/readers) decoupled. Aurora PostgreSQL/MySQL-compatible endpoints, Aurora Serverless v2 for variable load, and Global Database for cross-Region latency/DR.

# Conceptual endpoints
# writer:  mydb.cluster-xxxx.region.rds.amazonaws.com
# reader:  mydb.cluster-ro-xxxx.region.rds.amazonaws.com

7.4 DynamoDB — keys, partitions, and scale

Tables need a primary key (partition key, optional sort key). Item collections live in partitions hashed by the partition key — hot keys throttle you. Model access patterns first (single-table design is common), then add GSIs/LSIs carefully (every GSI has cost and consistency nuances).

• On-Demand vs Provisioned (+ Auto Scaling): traffic shape decides billing.
• DynamoDB Streams: change data capture into Lambda.
• TTL, Streams, Transactions, PartiQL: features for real apps — learn when each applies.
• Global Tables: multi-Region active-active with conflict caveats.

aws dynamodb create-table \
  --table-name OrbitSessions \
  --attribute-definitions AttributeName=pk,AttributeType=S AttributeName=sk,AttributeType=S \
  --key-schema AttributeName=pk,KeyType=HASH AttributeName=sk,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST

7.5 ElastiCache & MemoryDB

Redis/Memcached (ElastiCache) and Redis-compatible MemoryDB sit in front of databases for session stores, leaderboards, and read-heavy caches. Cache invalidation is still one of the hard problems — define TTLs and write-through/write-behind consciously. Never expose cache SG to the world.

7.6 Analytics glance (know the map)

Rule: do not crush an OLTP database with huge analytical scans — ship events/snapshots to a lake/warehouse.

7.7 Backups, encryption, and connections

• Encrypt at rest (KMS) and in transit (TLS); rotate credentials via Secrets Manager.
• RDS automated backups + manual snapshots; test restore before you need it.
• Place DBs in private subnets; SG only from app tier; prefer RDS Proxy / pooling for serverless churn.

7.8 Lab: Multi-AZ mindset without burning cash

1. Create a small DynamoDB on-demand table; put/get items; enable Streams to a log Lambda (or just inspect stream ARN).
2. Sketch an RDS Multi-AZ + read replica topology on paper for a blog app.
3. Price Aurora Serverless v2 vs a fixed db.t4g.micro for spiky traffic in Pricing Calculator.
4. Delete lab tables; confirm no idle RDS instances remain.

8.1 Compute spectrum reminder

EC2 = you manage the OS. ECS/EKS = you ship containers, AWS (or you) runs the control plane pieces. Lambda = you ship a handler; AWS scales the invoke path. Move right for less undifferentiated heavy lifting — move left when you need exotic kernels, GPUs, or sticky long processes.

8.2 AWS Lambda deep dive

• Handler + runtime: zip/container image; memory setting also scales CPU allocation.
• Triggers: API Gateway, SQS, SNS, S3, EventBridge, DynamoDB Streams, ALB, etc.
• Concurrency: reserved/provisioned concurrency tame noisy neighbors and cold starts.
• IAM execution role: least privilege to downstream services; VPC ENIs add cold-start cost — use sparingly.
• Idempotency: at-least-once delivery means design safe retries.

# Minimal Python mental model
def handler(event, context):
    # parse event (API GW / SQS / S3 shape differs)
    return {"statusCode": 200, "body": "ok"}

8.3 API Gateway — HTTP, REST, WebSocket

HTTP APIs are cheaper/simpler for many JWT/Lambda cases; REST APIs offer richer features (API keys, usage plans, broader integrations); WebSocket APIs for bidirectional chatty clients. Always think auth (Cognito JWT, IAM, Lambda authorizers) and stage/deploy.

8.4 Event-driven backbone

Pattern: SNS → SQS → Lambda for fan-out with per-subscriber isolation; EventBridge for routing on event shape.

8.5 Step Functions — orchestration

When workflows need retries, branching, human approval, or long-running sagas, Step Functions beat nested Lambda spaghetti. Standard vs Express workflows trade duration/history vs high-volume event processing.

8.6 Containers: ECS & EKS

• ECS: AWS-native orchestrator; Fargate removes node management; EC2 launch type for denser control.
• EKS: Managed Kubernetes control plane — portable skills/ecosystem, more moving parts (RBAC, CNI, upgrades).
• ECR: private container registry; scan images; least-privilege pull roles.

8.7 Lab: serverless hello + event

1. Deploy a Lambda behind an HTTP API returning JSON.
2. Add an S3 trigger (or EventBridge schedule) writing a log line.
3. Attach a DLQ (SQS) for asynchronous invoke failures.
4. Tear down API, function, and roles; confirm zero residual charges.

9.1 The three pillars of observability

Metrics tell you something is wrong; logs tell you what happened; traces tell you where time went across services. CloudWatch covers metrics/logs/alarms; X-Ray (and OpenTelemetry collectors) cover distributed traces.

9.2 CloudWatch essentials

• Namespaces, metrics, dimensions; custom metrics from apps.
• Alarms → SNS → email/Slack/Pager; composite alarms reduce noise.
• Log groups/streams; retention policies; Logs Insights queries.
• Dashboards for golden signals: latency, traffic, errors, saturation.

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

9.3 Tracing with X-Ray / OTel

Instrument API Gateway, Lambda, and HTTP clients so a single request ID stitches a service map. Sampling keeps cost sane. Use traces to find the slow dependency, not to replace metrics for SLOs.

9.4 AWS Config, CloudTrail, GuardDuty

• CloudTrail: who called which API — security forensics baseline.
• Config: record resource state; managed rules (e.g., S3 public prohibited); conformance packs.
• GuardDuty: intelligent threat findings from logs/VPC flow/DNS.

9.5 Systems Manager — ops without SSH sprawl

Session Manager replaces open port 22. Patch Manager, State Manager, Parameter Store, and Run Command automate fleet ops. Prefer SSM over bastions when possible; still lock IAM tightly.

aws ssm start-session --target i-0abc123def456

9.6 AWS Backup & disaster rehearsal

Central backup policies across EBS, RDS, DynamoDB (where supported), EFS, etc. Define RPO/RTO per system. A backup never tested is a rumor. Schedule restore drills into non-prod accounts.

9.7 IaC & change management glance

CloudFormation / CDK / Terraform make environments reproducible; CodePipeline/CodeBuild or GitHub Actions promote changes. Pair with CloudWatch alarms on deploy and automatic rollback strategies (ECS circuit breakers, Lambda aliases/versions).

9.8 Lab: alarm + Insights + SSM path

1. Create a billing or EC2 CPU alarm to SNS email.
2. Generate logs from a Lambda; run a Logs Insights query for errors.
3. Connect to a lab instance via Session Manager (no SSH port).
4. Document your RPO/RTO for one sample app in three sentences.

10.1 Reference mission: Orbit Catalog API

Build a public product catalog: users browse via CloudFront; API is Regional behind an ALB or API Gateway; catalog data in DynamoDB (hot path) with images in S3; writes go through authenticated admin path; async image processing via SQS → Lambda; observability everywhere.

10.2 Six pillars — applied checklist

10.3 Explicit tradeoffs (senior thinking)

• API Gateway + Lambda vs ALB + ECS: ops simplicity vs long-lived connections/websocket needs and cold starts.
• DynamoDB vs Aurora: access-pattern scale vs ad-hoc SQL flexibility.
• Multi-Region active-active vs warm standby: UX vs cost/complexity.
• WAF everywhere vs only at edge: defense depth vs rule maintenance.

10.4 Running a Well-Architected Review

Use the AWS WA Tool questions per pillar; record risks (high/medium); create improvement plan with owners and dates. Re-review after major launches. This is a conversation with evidence — not a paperwork ritual.

10.5 Your continuing flight plan

1. Build the Orbit Catalog in a sandbox account with IaC.
2. Add CI/CD, alarms, and a chaos/failover note.
3. Sit a practice Solutions Architect exam section weekly — map misses back to modules.
4. Read AWS Architecture Blog posts in your domain (fintech, media, SaaS).

10.6 Closing mnemonic