AWS Cloud & DevOps Tutorial 0/70 lessons ~6 min read Lesson 64“IAM, VPC, EC2, Lambda, ECS, EKS, Terraform, CI/CD, and AWS operations”

Project 1: Highly Available Three-Tier AWS Application

Module 6 projects prove you can compose AWS into a portfolio-ready system. **Project 1** builds a **highly available three-tier TechLearningPro application**: presentation (ALB + o

Course progress0%

Focus

15 guided sections

Practice signal

Examples included

Career prep

Interview Q&A included

Project 1: Highly Available Three-Tier AWS Application

AWS Cloud & DevOps Engineering · Lesson 64 · Production Projects and Interview

Lesson Overview

Module 6 projects prove you can compose AWS into a portfolio-ready system. Project 1 builds a highly available three-tier TechLearningPro application: presentation (ALB + optional static assets on S3/CloudFront conceptual edge), application (EC2 Auto Scaling across AZs), and data (Multi-AZ RDS), on a purposeful VPC with public/private subnets, IAM least privilege, encryption, CloudWatch alarms, budgets, IaC (Terraform or CloudFormation outline), deploy and cleanup, plus PRR/runbook artifacts from lesson 63. This is not a console click-tour—it is requirements → architecture → implementation outline → security → monitoring → cost → failure tests → portfolio deliverables.

Reuse networking fundamentals and VPC lessons; do not invent APIs. Prefer small instance classes; set AWS Budgets first; destroy the stack when graded evidence exists. Tag everything Project=tlp-lesson64.

Learning Objectives

State functional and non-functional requirements for the TechLearningPro three-tier app.
Draw Multi-AZ VPC with public/private subnets, ALB, ASG, RDS placement.
Explain traffic flow from client → ALB → app tier → RDS.
Outline IaC modules/stacks (Terraform or CloudFormation) without fake resource properties.
Apply security groups by reference, not sprawling CIDR soup.
Require IAM instance profiles and no long-lived keys on hosts.
Enable encryption at rest for EBS/RDS and in transit to ALB (ACM concepts).
Define ASG health checks integrated with ALB.
Configure RDS Multi-AZ conceptual failover awareness and backup retention.
Build CloudWatch dashboard and alarms for 5xx, unhealthy hosts, CPU, RDS storage.
Write deploy and destroy runbooks; prove cleanup.
Estimate cost dimensions; label figures illustrative with pricing-page dates.
Run failure tests: AZ impairment tabletop, instance terminate, SG deny.
Produce portfolio README, diagrams, ADR, PRR lite checklist.
Use Session Manager for admin (lesson 59/20), not open SSH.
Automate inventory/tag checks (lesson 60) on the stack.
Note supply-chain path if containers introduced later (Projects 2+).
Stay within budget; document spend caps.
Prepare interview walkthrough of the project in five minutes.
Hand off patterns to Project 2 container CI/CD.

Prerequisites

VPC, EC2/ASG, ALB, RDS, IAM, CloudWatch lessons from Modules 1–2.
Lessons 59–63 for Linux, automation, supply chain awareness, PRR/runbooks.
Sandbox account, budget alert, destroy permissions.
Terraform or CloudFormation familiarity sufficient to outline modules.

Detailed Core Concepts

Project requirements (TechLearningPro)

Functional: Serve a simple progress/health web app (or stub API) with a data dependency in RDS (e.g., progress rows). Health endpoint for ALB. Static lesson: even a minimal app proves HA wiring.

Non-functional: Multi-AZ for app and DB; private app/db subnets; ALB in public subnets; no app in public subnets with 0.0.0.0/0 SSH; RPO/RTO targets stated (e.g., RDS automated backups; accept Multi-AZ failover RTO as “minutes-class”—verify current RDS behavior in docs); tagged; monitored; destroyable via IaC.

Three tiers on AWS

Edge/presentation: ALB (and optionally S3+CloudFront for static—optional stretch). ACM certificate concepts for HTTPS listeners (verify validation options).
Application: Launch template + ASG across ≥2 AZs; user data installs app or pulls artifact; SSM agent; CloudWatch agent optional.
Data: RDS Multi-AZ (engine of choice you can operate—PostgreSQL/MySQL common); subnet group private; SG only from app SG.

VPC skeleton

VPC CIDR planned (lesson 5/6 habits).
Public subnets: ALB, NAT gateway(s)—discuss single NAT cost vs HA NAT trade-off in ADR.
Private subnets: ASG instances, RDS.
Route tables: public → IGW; private → NAT for outbound patching/SSM if not using interface endpoints.
Optional VPC endpoints for S3/SSM to reduce NAT spend—document trade-off.

Security groups

ALB SG: inbound 443/80 from allowed clients (0.0.0.0/0 only if public demo justified).
App SG: inbound from ALB SG only on app port.
RDS SG: inbound from app SG on DB port only.
Egress: least practical; avoid casual any-any without ADR.

IAM

Instance profile: CloudWatch agent, SSM, ECR pull if used, Secrets Manager read for DB secret—no * admin. Operators: Session Manager only.

Secrets

DB password in Secrets Manager; rotation concepts optional stretch. Never bake password into launch template plaintext.

IaC outline

Terraform example modules: network, alb, asg, rds, iam, observability. Remote state in S3+DynamoDB lock (or how your org does it). CloudFormation: nested stacks or separate templates with parameters/exports. Outline resources and parameters; verify property names in current docs when coding—do not invent.

Monitoring and PRR lite

Alarms: ALB 5xx, unhealthy host count, ASG in service capacity, RDS free storage/CPU, budget alerts. Runbooks from 63 adapted. Lite PRR before calling the project “done.”

Cost drivers

NAT gateway hours/data, ALB hours/LCUs, EC2, RDS Multi-AZ (roughly doubles DB compute cost class), EBS, data transfer, public IPv4 charges where applicable—verify current pricing pages and date your notes. Prefer t3.micro/t4g.small class sizes for labs if eligible; stop/destroy after evidence.

Cleanup

terraform destroy / delete CloudFormation stack; confirm ENIs, ENI-attached SGs, RDS final snapshot decision, NAT, EIP, ALB gone. Leftover NAT is a classic bill surprise.

Architecture and Design Diagrams

mermaid
flowchart TB
  User[Learners / operators]
  ALB[ALB public subnets Multi-AZ]
  ASG[App ASG private subnets]
  RDS[RDS Multi-AZ private]
  S3[Optional static S3]
  CW[CloudWatch]
  Bud[AWS Budgets]

  User --> ALB --> ASG --> RDS
  User -.-> S3
  ASG --> CW
  ALB --> CW
  RDS --> CW
  Bud -.-> ASG

mermaid
flowchart LR
  subgraph AZ_a[AZ-a]
    PubA[Public subnet ALB node]
    PrivA[Private app]
    DbA[RDS primary]
  end
  subgraph AZ_b[AZ-b]
    PubB[Public subnet ALB node]
    PrivB[Private app]
    DbB[RDS standby]
  end
  PubA --- PubB
  PrivA --- PrivB
  DbA --- DbB

mermaid
flowchart TB
  Req[Requirements + ADR]
  Iac[IaC plan apply]
  Test[Failure tests]
  Prr[PRR lite]
  Ev[Portfolio evidence]
  Des[Destroy / cleanup]
  Req --> Iac --> Test --> Prr --> Ev --> Des

Technical Explanation

Traffic path

Client HTTPS → ALB listener (ACM cert) → target group health checks on /health → healthy ASG instances → app queries RDS endpoint (Secrets Manager credentials fetched at boot or sidecar pattern). On instance failure, ALB stops routing; ASG replaces. On primary RDS impairment, Multi-AZ failover updates DNS to standby—apps should retry with backoff (verify driver behavior).

Deploy path

IaC applies network→IAM→RDS→ALB/ASG. App artifact via user data from S3 or baked AMI. Prefer immutable refresh for changes. Session Manager for debug (lesson 59). Inventory script (lesson 60) verifies tags.

Failure tests (required)

Terminate one app instance: recovery automatic? evidence.
Tabletop: AZ loss—capacity in remaining AZ?
Security group deny from ALB to app: unhealthy hosts; alarm fires?
Optional: stop RDS (non-prod carefully) or simulate credential failure—runbook clarity.

Security review points

No public RDS; encryption; SG references; IMDSv2 hop limit awareness; SSM instead of SSH; CloudTrail enabled in account (org baseline); secrets not in git.

Portfolio narrative

Hiring managers want: diagram, why Multi-AZ, how you destroyed it, what failed in tests, cost awareness, IAM story. Five-minute talk track mandatory deliverable.

Extended project depth: requirements worksheet

Copy into your portfolio README and fill before apply:

Service name and owner
Environments in scope (sandbox only for class)
User stories: health page; optional progress CRUD stub
RTO/RPO targets (stated assumptions)
Data classification (no real PII in labs)
Threat notes: public ALB exposure, SQLi if you add forms (parameterize queries)
Success metrics: healthy ALB; recovery < N minutes after terminate; destroy < 30 minutes
Out of scope: CloudFront multi-region, Aurora Global, full mesh service discovery

Extended project depth: Terraform outline (illustrative modules)

text
modules/
  network/    # VPC, subnets, IGW, NAT, routes, optional endpoints
  security/   # SGs
  iam/        # instance profile policies
  data/       # DB subnet group, RDS, secret
  compute/    # LT, ASG, ALB, listeners, TG
  observe/    # alarms, dashboard JSON
envs/sandbox/main.tf  # wires modules; tags Project=tlp-lesson64

Verify every resource argument against current provider docs while coding. Prefer prevent_destroy off in sandbox. Use terraform plan peer review before apply.

Extended project depth: CloudFormation outline (illustrative)

Nested stacks mirroring the same boundaries; parameters for VpcCidr, InstanceType, DbClass, AlarmEmail. Exports for AppSgId consumed by peers. Delete stack is the cleanup path—practice it twice.

Extended project depth: security checklist (print)

Extended project depth: monitoring checklist

ALB HTTPCode_Target_5XX_Count or equivalent alarm
Unhealthy host count > 0 for N minutes
ASG InService capacity below desired
RDS FreeStorageSpace low
EC2 status check failed metrics as applicable
Synthetic canary optional stretch

Extended project depth: cost worksheet (illustrative)

List dimensions: NAT $/hour, ALB $/hour, EC2 $/hour × count, RDS Multi-AZ $/hour, storage GB-month, public IPv4 if charged. Retrieve AWS pricing pages on ____ (date). Mark all student estimates illustrative. Add destroy confirmation timestamp.

Extended project depth: portfolio deliverables rubric mapping

Deliverable	Rubric area
Architecture Mermaid	Conceptual accuracy
Working ALB health	Implementation
SG/IAM/Secrets	Security
Failure tests + alarms	Reliability/observability
ADR + README + destroy	Documentation

Extended project depth: interview five-minute script

Minute 1: problem and requirements. Minute 2: diagram walk (AZ, SG). Minute 3: IAM/secrets/SSM. Minute 4: failure test + alarm. Minute 5: cost + destroy + what you’d do in Project 2 with containers.

Practical Implementation or Design Walkthrough

Problem

Implement (or fully specify + partially implement under budget) the HA three-tier TechLearningPro app with tests, cost notes, and cleanup.

Steps

Write requirements one-pager + success metrics; enable budget.
ADR: single NAT vs NAT per AZ; instance family; DB engine.
IaC outline/modules; apply network first.
RDS Multi-AZ with Secrets Manager password; private SG.
Launch template + ASG + ALB target group health check.
Prove /health through ALB DNS.
Dashboards/alarms; runbooks linked.
Execute failure tests; capture evidence.
PRR lite checklist signed by peer.
Portfolio README; terraform destroy/stack delete; confirm zero leftovers; save cost explorer screenshot (optional) and destroy proof.

Enterprise Real-World Scenarios

NAT left running

Bill shock after project. Fix: destroy checklist includes NAT/EIP.

RDS public

Data exposure. Fix: private subnets only; SG from app.

SSH open

PRR fail. Fix: SSM only.

No health check

ASG serves dead nodes. Fix: ALB health + ASG ELB health.

Keys on instance

Lesson 60 violation. Fix: instance profile + Secrets Manager.

Best Practices

Budget before apply.
Multi-AZ for app and DB.
SG by reference.
Secrets Manager for DB creds.
ALB health checks drive ASG.
Tag {tag} everywhere.
IaC destroy proven.
Failure tests before portfolio claim.
PRR lite gate.
Session Manager admin.
Encrypt RDS/EBS.
Document cost dimensions with dates.
Small lab sizes.
Runbooks for 5xx and DB failure.
Interview talk track rehearsed.

Common Mistakes and Anti-Patterns

Click-ops only with no destroy path.
Single AZ 'to save money' without ADR accepting risk.
Hardcoded DB password in user data.
0.0.0.0/0 to app port.
Skipping alarms.
Leaving NAT forever.
Inventing CloudFormation properties.
No tags.
Calling it HA without Multi-AZ DB story.
Portfolio screenshots without cleanup proof.

Troubleshooting and Design Review

Symptom	Cause	Action
ALB 502/503	No healthy targets	Check SG, health path, app listen, AZ register
ASG not scaling in	Subnet/LT/IAM	Describe activities; fix launch failures
RDS create fails	Subnet group/SG	Private subnets ≥2 AZ; fix SG
SSM not connected	Agent/IAM/net	Lesson 59/20 path
Destroy stuck	ENI/final snapshot	Delete order; remove protections
Unexpected cost	NAT/RDS Multi-AZ	Destroy; review Cost Explorer

Interview Questions and Answers

Q1: Why three tiers? A: Separate scale/security for edge, app, data. Q2: HA meaning here? A: Multi-AZ ALB/ASG/RDS; replace unhealthy hosts. Q3: Traffic flow? A: Client→ALB→private app→RDS. Q4: SG design? A: Reference ALB→app→db; least inbound. Q5: Secrets? A: Secrets Manager; instance role retrieve. Q6: Health checks? A: ALB path; ASG uses ELB health. Q7: IaC choice? A: Terraform or CFN with destroy path. Q8: Failure test? A: Terminate instance; prove replacement. Q9: Cost drivers? A: NAT, ALB, EC2, Multi-AZ RDS—verify pricing. Q10: Cleanup? A: Destroy stack; confirm NAT/EIP/RDS gone. Q11: SSM why? A: No inbound SSH; IAM audit. Q12: PRR lite? A: Evidence before claiming production-ready. Q13: Single NAT risk? A: AZ impairment of NAT affects egress—ADR. Q14: Portfolio tip? A: Diagram + trade-offs + destroy proof. Q15: Next project? A: Containers CI/CD on ECS/EKS.

Hands-On Exercises

Exercise: Implement HA three-tier TechLearningPro app

Deliverable: requirements, Mermaid architecture, IaC, ALB URL evidence, failure test notes, alarms, cost note, PRR lite, destroy proof, Project=tlp-lesson64 everywhere.

Challenge ADR

Under tighter budget: single NAT + scheduled destroy; accept egress risk explicitly with expiry when funding allows dual NAT.

Lab evidence checklist

Budget on; apply logs; curl health via ALB; terminate-instance recovery; destroy complete; no orphan NAT.

Narrative: destroy is part of the grade

Student left NAT two weeks; bill exceeded lab stipend. Rubric now weights cleanup equally with HA—FinOps is reliability’s twin.

Continuity

Project 1 establishes classic HA baseline. Next: Project 2: Container CI/CD Platform with ECS or EKS adds container delivery on this networking literacy.

Extended practice scenario 1 — 64 project 1 highly available three tier aws application

Confirm AWS Budgets alerts exist; tag every resource Project=tlp-lesson64. Cap spend explicitly before terraform apply/stack create.

In a timed drill for highly available three-tier AWS application project at TechLearningPro, implement or design the core lab with a partner observing. The observer's job is to stop any step that invents API flags, hardcodes secrets, invents pricing numbers presented as current quotes, or skips budget and cleanup. After the drill, rewrite your ADR in ten lines: context, decision, consequences. Attach evidence: IaC repo, diagrams, ALB health proof, failure tests, cost note, destroy confirmation, and destroy confirmation for any lab resources.

Discuss how highly available three-tier AWS application project connects prior AWS lessons (IAM, VPC, EC2/SSM, CI/CD, observability, FinOps) and upcoming Module 6 projects. List two risks you would raise in Project 1 PRR lite, with owners and due dates.

Finally, teach back the lesson overview paragraph from memory, then check against the text. Gaps become flashcards. Premium courses finish when you can operate under time pressure without treating highly available three-tier AWS application project as a mystery.

Extended practice scenario 2 — 64 project 1 highly available three tier aws application

Document the lesson's primary architecture decision in a ten-line ADR: context, decision, status, consequences.

Extended practice scenario 3 — 64 project 1 highly available three tier aws application

Map identity paths: who can create/modify the resources in this lesson; which IAM roles are least privilege.

Extended practice scenario 4 — 64 project 1 highly available three tier aws application

Design observability: CloudWatch metrics/alarms or equivalent signals that prove the control works.

Extended practice scenario 5 — 64 project 1 highly available three tier aws application

Run or design a negative test: denied access, misconfiguration, or failed dependency—capture evidence.

Extended practice scenario 6 — 64 project 1 highly available three tier aws application

Estimate cost dimensions for this lesson's activities. Label figures illustrative; verify pricing pages with dates.

Extended practice scenario 7 — 64 project 1 highly available three tier aws application

Produce a cleanup checklist and execute destroy for any billable lab resources created for this lesson.

Extended practice scenario 8 — 64 project 1 highly available three tier aws application

Cross-link prior course lessons that this design depends on; list two failure modes inherited from those layers.

Extended practice scenario 9 — 64 project 1 highly available three tier aws application

Security review: encryption at rest/in transit, public exposure checks, CloudTrail visibility for management events.

Extended practice scenario 10 — 64 project 1 highly available three tier aws application

Reliability review: failure isolation, rollback, how detection and recovery work under Monday traffic.

Extended practice scenario 11 — 64 project 1 highly available three tier aws application

Performance review: bottlenecks, scaling limits, or saturation signals relevant to this lesson's topic.

Extended practice scenario 12 — 64 project 1 highly available three tier aws application

Write a runbook section for on-call: symptoms, first three diagnostic steps, escalation, rollback.

Extended practice scenario 13 — 64 project 1 highly available three tier aws application

Config/compliance angle: which controls must be true before production promotion.

Extended practice scenario 14 — 64 project 1 highly available three tier aws application

Multi-account consideration: how this control behaves across sandbox, staging, and production accounts.

Extended practice scenario 15 — 64 project 1 highly available three tier aws application

Interview drill: explain the lesson topic to a hiring manager in three minutes without inventing APIs.

Extended practice scenario 16 — 64 project 1 highly available three tier aws application

Pair review: partner stops any invented CLI flags, hardcoded secrets, or fake current prices.

Extended practice scenario 17 — 64 project 1 highly available three tier aws application

FinOps continuity from lesson 47: idle resources, data transfer, and when to decommission lab stacks.

Extended practice scenario 18 — 64 project 1 highly available three tier aws application

DR continuity from lesson 45: ensure this design does not destroy recoverability during change.

Extended practice scenario 19 — 64 project 1 highly available three tier aws application

Produce evidence pack: diagrams, configs, test results, cleanup proof.

Extended practice scenario 20 — 64 project 1 highly available three tier aws application

Challenge constraint: tighter monthly budget—single NAT, smaller RDS class, aggressive destroy SLA—document ADR.

Extended practice scenario 21 — 64 project 1 highly available three tier aws application

Challenge constraint: stricter compliance—what evidence gates release?

Extended practice scenario 22 — 64 project 1 highly available three tier aws application

Challenge constraint: shorter maintenance window—what pre-staging changes?

Extended practice scenario 23 — 64 project 1 highly available three tier aws application

Teach-back: recite the Lesson Overview paragraph, then check against the text; flashcard gaps.

Extended practice scenario 24 — 64 project 1 highly available three tier aws application

Dress rehearsal: tabletop under a timer with observer notes.

Extended practice scenario 25 — 64 project 1 highly available three tier aws application

Final synthesis note: one paragraph connecting this lesson's topic to TechLearningPro production ownership.

Compliance evidence pack for auditors / platform leads

Budget configs, tagging proof (Project=tlp-lesson64), architecture diagram, ADR, negative-test evidence, encryption settings notes, CloudTrail/Config/SSM references where applicable, pricing-page retrieval dates for any dollar claims, cleanup confirmation.

Glossary drill

Define three-tier, Multi-AZ, target group health, launch template, NAT trade-off, final snapshot from memory.

Budget and cleanup sworn statement

I verified budgets remain enabled with alert subscribers. I deleted or scheduled deletion for orphan lab resources from lesson 64 named ____. I labeled every savings or cost figure with pricing-page retrieval dates or marked it illustrative. Signed ________ date ________.

Interview story to memorize

Craft a 60-second story: you shipped a Multi-AZ ALB/ASG/RDS TechLearningPro app with Secrets Manager, SSM, alarms, failure tests, and full IaC destroy—then explained trade-offs in an interview.

Self-assessment rubric

Area	Weight
Conceptual accuracy and service selection	20%
Working design/lab and reproducibility	25%
Security and least-privilege	20%
Reliability, observability, troubleshooting	20%
Documentation, ADR, cleanup	15%

Final synthesis before summary

Project 1 mastery is HA composition with security, evidence, cost honesty, and cleanup—not a forever-running demo VPC.

Extended facilitation script (print for guild leads)

Open with portfolio bar: diagram, HA story, destroy proof. Walk traffic and SG references on a whiteboard. Assign pair destroy verification. Remind no invented resource properties—docs open while coding.

Lesson Summary

Project 1 delivers a highly available three-tier TechLearningPro app—VPC, ALB, ASG, Multi-AZ RDS, IAM/Secrets, monitoring, IaC, failure tests, PRR lite, cost notes, and mandatory cleanup—tagged Project=tlp-lesson64. Next: Project 2: Container CI/CD Platform with ECS or EKS.