← Back to all projects

LEARN CLOUD ARCHITECTURE

Learn Cloud Architecture: From Console Clicker to System Designer

Goal: Move beyond “launching a server” to designing resilient, scalable, secure, and cost-effective cloud systems. You will learn Infrastructure as Code (IaC), High Availability (HA), Disaster Recovery (DR), and the trade-offs that define a Cloud Architect’s job.

The Cloud Architect Mindset

A Cloud Architect doesn’t just “make it work.” They ask:

  • Reliability: Will it survive if a data center burns down?
  • Scalability: Will it crash if 1 million users join tomorrow?
  • Security: Can we prove only authorized people have access?
  • Cost: Are we burning money on idle resources?
  • Operational Excellence: Is it automated, or does it require a human at 3 AM?

These projects are designed to force you to answer these questions using the Well-Architected Framework.

Note: I will reference AWS services as the default because they have the largest market share, but I will list the architectural concept so you can build this on Azure (Microsoft) or GCP (Google) if you prefer.

Core Concept Analysis

  1. Compute Paradigms: VMs (EC2) vs. Containers (ECS/K8s) vs. Serverless (Lambda).
  2. Networking: VPCs, Subnets, Routing, DNS, Load Balancing.
  3. Storage: Block (Disk), Object (S3), File (EFS).
  4. Database Patterns: Relational (SQL) vs. NoSQL vs. Caching.
  5. Infrastructure as Code (IaC): Treating infrastructure like software.

Project List

Project 1: The “Manual” 3-Tier Architecture

  • File: LEARN_CLOUD_ARCHITECTURE.md
  • Main Programming Language: HCL (Terraform) - But do this manually first!
  • Alternative Programming Languages: Python (Pulumi), TypeScript (CDK)
  • Coolness Level: Level 1: Pure Corporate Snoozefest (But Essential)
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 1: Beginner
  • Knowledge Area: Networking / Basic Compute
  • Software or Tool: AWS Console / Azure Portal
  • Main Book: “Solutions Architect’s Handbook” by Saurabh Shrivastava

What you’ll build: A classic web application structure containing a Web Tier (Public), App Tier (Private), and Database Tier (Private) inside a custom Virtual Private Cloud (VPC), built entirely by hand-clicking in the console.

Why it teaches Cloud Architecture: You cannot automate what you do not understand. By manually creating subnets, route tables, and Internet Gateways, you learn the “plumbing” of the cloud that is usually hidden by defaults.

Core challenges you’ll face:

  • CIDR math: Calculating IP ranges so subnets don’t overlap.
  • Routing: Making sure the Private subnet can talk to the internet (NAT Gateway) but the internet can’t talk to it.
  • Security Groups: Configuring firewall rules so the Web Tier can talk to the App Tier, but the App Tier can’t be reached directly by the user.

Key Concepts:

  • VPC Design: Public vs. Private Subnets.
  • NAT Gateways: Outbound-only internet access.
  • Security Groups vs. NACLs: Stateful vs. Stateless firewalls.

Difficulty: Beginner Time estimate: Weekend Prerequisites: Basic understanding of IP addresses.

Real world outcome: You navigate to a Load Balancer URL, and it shows a webpage served from a server you cannot SSH into directly, which pulls data from a database you cannot touch directly.

Implementation Hints: Don’t use the “Default VPC”. Create a new one. Create 2 public subnets and 2 private subnets. Put an EC2 instance in the public one (Bastion Host) and your web server in the private one. Try to SSH into the private one. You’ll fail. Now figure out how to use the Bastion to jump to the private server.

Learning milestones:

  1. The Network: You have a VPC with correctly routed subnets.
  2. The Isolation: You understand why databases go in private subnets.
  3. The Access: You can securely administer private resources via a Bastion.

Project 2: The “IaC” Refactor (Terraform Migration)

  • File: LEARN_CLOUD_ARCHITECTURE.md
  • Main Programming Language: HCL (Terraform)
  • Alternative Programming Languages: Python (Pulumi), YAML (Ansible)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Infrastructure as Code
  • Software or Tool: Terraform / OpenTofu
  • Main Book: “Terraform: Up & Running” by Yevgeniy Brikman

What you’ll build: You will delete everything you built in Project 1. Then, you will write code (Terraform) that rebuilds the exact same infrastructure with a single command (terraform apply).

Why it teaches Cloud Architecture: Professional architects don’t click buttons. Clicking is error-prone and unrepeatable. This teaches you “Immutable Infrastructure” and documenting your architecture in code.

Core challenges you’ll face:

  • State Management: Understanding the terraform.tfstate file and why locking it is important.
  • Dependency Graph: Terraform usually knows the order, but sometimes you need to be explicit (e.g., The Internet Gateway must exist before the Route Table).
  • Modularity: Breaking your code into reusable pieces (Network module, Compute module).

Key Concepts:

  • Declarative vs Imperative: Saying “I want 3 servers” vs “Create a server 3 times”.
  • Idempotency: Running the script twice shouldn’t create double the servers.

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Project 1.

Real world outcome: Run terraform destroy, wait 5 minutes. Run terraform apply, wait 5 minutes. Your entire environment is back online. This is the power of IaC.

Implementation Hints: Start by hardcoding values. Once it works, refactor to use variables.tf so you can change the region or instance size without touching the main logic.

Learning milestones:

  1. The Replication: You successfully recreate Project 1 via code.
  2. The Change: You change a variable (e.g., instance count) and apply it to see the update.
  3. The Destruction: You can tear down and rebuild freely.

Project 3: The “Unbreakable” Auto-Scaler

  • File: LEARN_CLOUD_ARCHITECTURE.md
  • Main Programming Language: HCL (Terraform)
  • Alternative Programming Languages: Shell Scripting (User Data)
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: High Availability / Scalability
  • Software or Tool: AWS Auto Scaling Groups (ASG) / ELB
  • Main Book: “Web Scalability for Startup Engineers” by Artur Ejsmont

What you’ll build: A web application that automatically launches new servers when CPU usage spikes and terminates them when traffic drops. It will be fronted by a Load Balancer that distributes traffic across multiple Availability Zones (Data Centers).

Why it teaches Cloud Architecture: This covers Horizontal Scaling (adding more machines) vs Vertical Scaling (making machines bigger). It forces you to design “Stateless” applications—if a server is deleted, no user data should be lost.

Core challenges you’ll face:

  • Statelessness: You can’t save user sessions or uploaded files to the local disk of the server, because that server might be deleted by the auto-scaler. You must use Redis (ElastiCache) for sessions and S3 for files.
  • Health Checks: Configuring the Load Balancer to know when a server is “sick” and needs to be replaced.
  • Bootstrapping: Creating a “Launch Template” so new servers know what software to install immediately upon boot.

Key Concepts:

  • ELB (Elastic Load Balancing): Layer 4 vs Layer 7 load balancing.
  • ASG (Auto Scaling Groups): Dynamic scaling policies.
  • Multi-AZ: Spanning data centers for redundancy.

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Project 2.

Real world outcome: You use a load testing tool (like Apache Bench) to flood your website. You watch the AWS console as it automatically launches 2, then 4, then 8 servers. You stop the test, and watch it scale back down to 2.

Implementation Hints: Use a “Launch Template” with “User Data” (bash script) that installs Apache/Nginx and writes “Hello from server $(hostname)” to index.html. This lets you visually confirm which server you are hitting.

Learning milestones:

  1. The Balancer: Traffic is split between two static servers.
  2. The Image: You create an AMI (Golden Image) for your servers.
  3. The Scale Out: High CPU triggers new instances.
  4. The Scale In: Low CPU terminates instances to save money.

Project 4: The “Serverless” Event Processor

  • File: LEARN_CLOUD_ARCHITECTURE.md
  • Main Programming Language: Python or Node.js
  • Alternative Programming Languages: Go
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Modern Application Architecture
  • Software or Tool: AWS Lambda, API Gateway, DynamoDB
  • Main Book: “Serverless Architectures on AWS” by Peter Sbarski

What you’ll build: An API that accepts an image upload, automatically triggers a function to resize it/convert it to grayscale, and saves the metadata to a NoSQL database. No servers to manage.

Why it teaches Cloud Architecture: Serverless shifts the architect’s focus from “System Administration” to “Event Choreography.” You learn about cold starts, function timeouts, and the cost model (pay-per-millisecond).

Core challenges you’ll face:

  • Event-Driven Design: The resize function isn’t called by a user; it’s called by the event of a file landing in a storage bucket (S3).
  • Permissions (IAM): The function needs permission to Read S3, Write S3, and Write DynamoDB.
  • Statelessness (Extreme): The function lives for milliseconds.

Key Concepts:

  • FaaS (Function as a Service): Lambda/Azure Functions.
  • NoSQL Design: Single Table Design in DynamoDB.
  • Triggers: S3 Events, API Gateway Routes.

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Basic coding skills.

Real world outcome: You upload a 5MB image to an S3 bucket. Seconds later, a thumbnail appears in a different bucket, and a row appears in DynamoDB logs with the image size and timestamp. You did not configure a single server.

Implementation Hints: Architecture: User -> API Gateway -> Lambda (Upload URL generator) -> S3 (Direct Upload) -> S3 Event -> Lambda (Processor) -> DynamoDB.

Learning milestones:

  1. The Trigger: Dropping a file runs code.
  2. The Permission: IAM Role is scoped correctly (Least Privilege).
  3. The Database: Storing unstructured metadata in NoSQL.

Project 5: The “Global” Content Delivery (CDN)

  • File: LEARN_CLOUD_ARCHITECTURE.md
  • Main Programming Language: HCL (Terraform)
  • Alternative Programming Languages: N/A (Config heavy)
  • Coolness Level: Level 2: Practical
  • Business Potential: 3. Service & Support
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Performance / Caching
  • Software or Tool: CloudFront, S3, Route53
  • Main Book: “High Performance Browser Networking” by Ilya Grigorik

What you’ll build: A static website hosted in a storage bucket (S3), distributed globally via a Content Delivery Network (CloudFront), with a custom domain name managed by DNS (Route53) and HTTPS certificate (ACM).

Why it teaches Cloud Architecture: Latency kills businesses. You’ll learn how to push content to the “Edge” (servers close to the user) and how DNS works to route users to the nearest data center.

Core challenges you’ll face:

  • Caching Policies: How long should the CDN hold the file? (TTL). How do you invalidate it when you update the site?
  • DNS Propagation: Understanding A records, CNAMEs, and Alias records.
  • Certificate Validation: Proving you own the domain to get a free SSL certificate.

Key Concepts:

  • Edge Computing: Caching static assets close to users.
  • DNS Resolution: How example.com becomes an IP address.
  • Origin Access Identity: Securing the bucket so only the CDN can read it, not the public.

Difficulty: Intermediate Time estimate: Weekend Prerequisites: Domain name (buy a cheap one).

Real world outcome: You access your website from your computer. Then use a VPN to pretend to be in Japan. The website loads instantly because the data is cached in a Tokyo Edge Location, rather than traveling from your origin server in Virginia.

Implementation Hints: Bucket policy is key. The bucket should not be public. The bucket policy should allow the CloudFront OAI (Origin Access Identity) to read.

Learning milestones:

  1. The Secure Origin: Bucket is private, but site works via CDN.
  2. The Encryption: HTTPS is valid with a custom domain.
  3. The Cache: You update index.html, but still see the old one (until you invalidate).

Project 6: The “Chaos” Disaster Recovery (DR) Simulation

  • File: LEARN_CLOUD_ARCHITECTURE.md
  • Main Programming Language: HCL (Terraform)
  • Alternative Programming Languages: Python (Boto3)
  • Coolness Level: Level 5: Pure Magic
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 4: Expert
  • Knowledge Area: Reliability / Business Continuity
  • Software or Tool: Route53 Failover, RDS Read Replicas
  • Main Book: “Site Reliability Engineering” by Google (The SRE Book)

What you’ll build: You will deploy your application to two different regions (e.g., US-East and US-West). You will set up database replication between them. Then, you will “simulate” a nuclear event by manually deleting the entire US-East stack and watching the system failover to US-West automatically.

Why it teaches Cloud Architecture: This is the pinnacle of architecture. It combines networking, data consistency, and DNS routing. It forces you to think about RTO (Recovery Time Objective) and RPO (Recovery Point Objective).

Core challenges you’ll face:

  • Data Latency: Asynchronous replication means the secondary DB might be a few milliseconds behind.
  • DNS Failover: configuring Route53 health checks to detect when US-East is dead.
  • Cost: Running duplicate infrastructure is expensive. Can you use “Pilot Light” (small version) in the secondary region?

Key Concepts:

  • Active-Active vs Active-Passive: Do both regions take traffic, or is one waiting?
  • Read Replicas: Offloading read traffic and acting as a standby.
  • Global Tables: (If using DynamoDB) Multi-region active data.

Difficulty: Expert Time estimate: 2-3 weeks Prerequisites: Project 3.

Real world outcome: You terminate your primary load balancer. Your website goes down for 30 seconds. Then, DNS updates, and the website comes back online, serving data from the other side of the country.

Implementation Hints: Use Route53 “Health Checks”. Point the health check at the primary Load Balancer. If it returns 404/500, Route53 changes the DNS answer to the Secondary Load Balancer IP.

Learning milestones:

  1. The Replica: Database writes in Region A appear in Region B.
  2. The Switch: DNS Health checks successfully detect failure.
  3. The Recovery: The application works fully in the backup region.

Project 7: The “Container Ship” (Kubernetes/EKS)

  • File: LEARN_CLOUD_ARCHITECTURE.md
  • Main Programming Language: YAML (Kubernetes Manifests)
  • Alternative Programming Languages: HCL (Terraform for EKS setup)
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Container Orchestration
  • Software or Tool: Docker, Kubernetes (EKS), Helm
  • Main Book: “Kubernetes Up & Running”

What you’ll build: A Microservices architecture deployed on a managed Kubernetes cluster (EKS). You will include a Service Mesh (like Istio or Linkerd) to observe traffic between services.

Why it teaches Cloud Architecture: Modern cloud is often just “Kubernetes Management.” You need to understand how K8s interacts with the cloud provider (Load Balancers, EBS Volumes, IAM integration).

Core challenges you’ll face:

  • Networking Overlays: How K8s networking differs from VPC networking.
  • Ingress Controllers: Routing traffic from the internet to internal pods.
  • IAM Integration: Letting a specific Pod access an S3 bucket (IRSA - IAM Roles for Service Accounts).

Key Concepts:

  • Pods & Services: The atoms of K8s.
  • Ingress: The entry point.
  • Sidecars: Helper containers (logging/proxies).

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Docker knowledge.

Real world outcome: You deploy a new version of a microservice using a “Canary Deployment” (send 10% of traffic to the new version). If it errors, you roll back automatically.

Implementation Hints: Don’t install k8s the hard way. Use EKS (AWS) or GKE (Google). Focus on the architecture of the deployment (Deployments, Services, Ingress), not the installation of the control plane.

Learning milestones:

  1. The Cluster: EKS is running and nodes are joined.
  2. The App: Traffic flows from Internet -> ALB -> Ingress -> Service -> Pod.
  3. The Storage: A pod successfully mounts a Persistent Volume (EBS).

Project 8: The “Cost Optimizer” (FinOps Dashboard)

  • File: LEARN_CLOUD_ARCHITECTURE.md
  • Main Programming Language: Python (Boto3)
  • Alternative Programming Languages: JavaScript
  • Coolness Level: Level 2: Practical
  • Business Potential: 3. Service & Support
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Cost Management / Governance
  • Software or Tool: AWS Cost Explorer API, Lambda
  • Main Book: “Cloud FinOps” by J.R. Storment

What you’ll build: A scheduled tool that scans your cloud environment for “waste”: unattached EBS volumes, idle Load Balancers, and old Snapshots. It generates a report and sends it to Slack/Email with the potential money saved.

Why it teaches Cloud Architecture: An architect’s job is to deliver value. Waste reduces value. Understanding the billing model of every resource is crucial for design.

Core challenges you’ll face:

  • API Discovery: finding the right API calls to check “last used” timestamps.
  • Logic: Defining what “idle” means (e.g., CPU < 1% for 7 days).
  • Tagging Strategy: Using resource tags to allocate costs to departments.

Key Concepts:

  • FinOps: The practice of cloud financial management.
  • Reserved Instances vs Savings Plans vs Spot: Purchasing models.
  • Resource Lifecycle: Creation -> Utilization -> Decommissioning.

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Basic Python.

Real world outcome: Every Monday morning, you get a Slack message: “Potential Savings: $45.00. Found 3 unattached volumes.”

Implementation Hints: Use boto3 library in Python. Look for ec2.describe_volumes() filtering by status available (which means unattached).

Learning milestones:

  1. The Scan: Successfully list unused resources.
  2. The Math: Calculate the cost based on size/type.
  3. The Alert: Integrate with a notification system.

Project 9: The “Vault” (Security & Compliance)

  • File: LEARN_CLOUD_ARCHITECTURE.md
  • Main Programming Language: HCL (Terraform)
  • Alternative Programming Languages: Python (Config Rules)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. Service & Support
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Security / Governance
  • Software or Tool: KMS, Secrets Manager, AWS Config
  • Main Book: “AWS Security” by Dylan Shields

What you’ll build: A highly secure environment where no secrets (passwords/keys) are hardcoded. Apps retrieve DB passwords from Secrets Manager at runtime. All storage is encrypted with Customer Managed Keys (KMS). AWS Config rules automatically remediate bad configurations (e.g., auto-close a public S3 bucket).

Why it teaches Cloud Architecture: Security cannot be an afterthought. You will learn “Security by Design.” You will understand encryption at rest, encryption in transit, and secret rotation.

Core challenges you’ll face:

  • Key Management: Who is allowed to use the encryption key? (Key Policy).
  • Secret Rotation: Automating the changing of database passwords without breaking the app.
  • Compliance as Code: Writing rules that enforce security standards.

Key Concepts:

  • KMS (Key Management Service): Envelope encryption.
  • Least Privilege: Giving apps only the exact permissions they need.
  • Remediation: Auto-fixing security holes.

Difficulty: Advanced Time estimate: 2 weeks Prerequisites: Project 1 & 2.

Real world outcome: You try to make an S3 bucket public. Within 30 seconds, an automated script detects it, removes the public policy, and sends you an email warning you to stop.

Implementation Hints: Use AWS Config “Managed Rules” for the S3 check. Use Systems Manager Parameter Store or Secrets Manager for the app credentials.

Learning milestones:

  1. The Secret: Application connects to DB without knowing the password at boot.
  2. The Encryption: All volumes and buckets are encrypted by default.
  3. The Watchdog: Config rules actively police your account.

Project 10: The “Data Lake” Pipeline

  • File: LEARN_CLOUD_ARCHITECTURE.md
  • Main Programming Language: SQL / Python
  • Alternative Programming Languages: Scala
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 5. Industry Disruptor (Big Data)
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Big Data / Analytics
  • Software or Tool: S3, Glue, Athena, Kinesis
  • Main Book: “Designing Data-Intensive Applications” by Martin Kleppmann

What you’ll build: A streaming data pipeline. A script simulates user clicks. Data is streamed into Kinesis Firehose, saved to S3 (Raw Zone), transformed by an ETL job (AWS Glue) into Parquet format (Clean Zone), and queried via SQL using Athena (Serverless Query).

Why it teaches Cloud Architecture: Data is gravity. Architecting for data requires understanding storage tiers, schema evolution, and the difference between OLTP (Transactional DB) and OLAP (Analytical DB).

Core challenges you’ll face:

  • Partitioning: Organizing S3 data (/year=2025/month=01/) so queries are fast and cheap.
  • Schema Discovery: Using Glue Crawlers to figure out the data structure.
  • Format efficiency: Why Parquet/ORC is better than JSON/CSV for analytics.

Key Concepts:

  • ETL (Extract, Transform, Load).
  • Data Lake vs Data Warehouse.
  • Serverless Analytics.

Difficulty: Advanced Time estimate: 2 weeks Prerequisites: SQL basics.

Real world outcome: You run a SQL query: SELECT * FROM website_traffic WHERE country='US'. Even though the data is just files in a folder, you get a table result in seconds.

Implementation Hints: Start simple. Send JSON logs to S3. Use a Glue Crawler to read them. Query with Athena. Then add the transformation step to convert JSON to Parquet.

Learning milestones:

  1. The Ingest: Data flows from source to S3 automatically.
  2. The Catalog: Glue successfully identifies the table structure.
  3. The Insight: You can run SQL queries against raw files.

Project Comparison Table

Project Difficulty Time Key Skill Fun Factor
1. Manual 3-Tier Beginner Weekend Networking Basics 2/5
2. IaC Refactor Intermediate 1 Week Terraform/Automation 3/5
3. Auto-Scaler Intermediate 1-2 Weeks Scalability 4/5
4. Serverless API Intermediate 1 Week Modern Arch 4/5
5. Global CDN Intermediate Weekend Performance 3/5
6. Disaster Recovery Expert 2-3 Weeks Resilience 5/5
7. K8s Cluster Advanced 2-3 Weeks Orchestration 4/5
8. Cost Optimizer Intermediate 1 Week FinOps 3/5
9. The Vault Advanced 2 Weeks Security 3/5
10. Data Lake Advanced 2 Weeks Data Arch 3/5

Phase 1: The Foundation (Mandatory)

Project 1 (Manual 3-Tier) -> Project 2 (IaC Refactor). Why: You must understand the network before you automate it. These two projects are 50% of a Cloud Architect’s daily job.

Phase 2: The Architect (Core)

Project 3 (Auto-Scaler) -> Project 6 (Disaster Recovery). Why: This teaches you the difference between “hosting” and “architecting.” High Availability and Resilience are the defining traits of cloud systems.

Phase 3: Modernization (Specialization)

Project 4 (Serverless) OR Project 7 (Kubernetes). Why: Choose your path. Are you supporting legacy microservices (K8s) or building new event-driven apps (Serverless)?

Final Overall Project: The “Strangler” Migration (Hybrid Cloud)

  • File: LEARN_CLOUD_ARCHITECTURE.md
  • Main Programming Language: Multiple
  • Difficulty: Level 5: Master

What you’ll build:

  1. Start with a “Monolith” application running on a single simulated on-premise server (just a Docker container on your laptop or a single EC2).
  2. Establish a “Hybrid” network (Site-to-Site VPN or simulated via VPC Peering).
  3. Build a “Strangler Facade” (API Gateway) that intercepts all traffic.
  4. Migrate functionality one by one:
    • Move the User Auth to Cognito.
    • Move the Image Processing to Lambda.
    • Move the Search to OpenSearch.
    • Keep the core legacy logic on the old server (for now).
  5. Finalize by shutting down the monolith when all routes are migrated.

Why it teaches Cloud Architecture: Real cloud architecture is rarely greenfield (starting from scratch). It’s usually messy migrations. This project forces you to deal with latency between “on-prem” and cloud, data synchronization, and gradual cutovers.

Real World Outcome: You have a functioning application that is 50% serverless and 50% legacy, working seamlessly together. This is the reality of Enterprise Architecture.

Summary

Project Concept Main Tool
1. Manual 3-Tier Networking VPC/EC2
2. IaC Refactor Automation Terraform
3. Auto-Scaler Scalability ASG/ELB
4. Serverless API Event-Driven Lambda
5. Global CDN Performance CloudFront
6. Disaster Recovery Resilience Route53
7. K8s Cluster Containers EKS
8. Cost Optimizer FinOps Lambda/Boto3
9. The Vault Security KMS/Config
10. Data Lake Analytics Athena/Glue
11. The Strangler Migration API Gateway

Essential Resources

Books (The “Bible” Tier)

  • “Designing Data-Intensive Applications” by Martin Kleppmann (Essential for understanding distributed systems trade-offs).
  • “Solutions Architect’s Handbook” by Saurabh Shrivastava.
  • “Terraform: Up & Running” by Yevgeniy Brikman.

Documentation

  • AWS Well-Architected Framework (Whitepaper) - Read this. It is the gold standard.
  • The Twelve-Factor App (Manifesto) - Rules for modern cloud apps.
  • AWS Architecture Center - Reference diagrams for common patterns.

Tools

  • Terraform/OpenTofu: Industry standard IaC.
  • Draw.io / Lucidchart: Architects draw diagrams. Get good at this.
  • AWS Calculator: Learn to estimate costs before you build.