Friday, June 5, 2026
Cohort 3 | Project CloudIgnite Topics: AWS Cloud Adoption Framework (CAF), AWS Well-Architected Framework, Reliability & High Availability, Lab 16 Duration: ~3 hours
Key Takeaways
- AWS Cloud Adoption Framework (CAF): 6 perspectives (3 business: Business/People/Governance, 3 technical: Platform/Security/Operations) — planning tool for migration
- AWS Well-Architected Framework (WAF): 6 pillars (Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability) — design/operational tool
- Reliability vs Availability: Reliability = system works as expected (MTBF); Availability = system is up and running (% uptime, measured in "nines")
- High Availability prime factors: Fault tolerance (redundant components), Scalability (Auto Scaling), Recoverability (restore after failure)
- The "nines": 99.999% = 5-nines = ~5 minutes max downtime/year; Amazon S3 = 11 nines durability
- Traditional → AWS mapping: Physical server → EC2, SAN → EBS, NAS → EFS, tape backup → S3, AD → AWS Directory Service
- Lab 16: Aurora/RDS challenge — launch DB, connect from EC2, run SQL queries
Table of Contents
- AWS Cloud Adoption Framework (CAF)
- AWS Well-Architected Framework (WAF)
- Well-Architected Design Principles
- Reliability and High Availability
- Traditional → AWS Service Mapping
- Lab 16: Amazon Aurora / RDS Challenge
- CLF-C02 Exam Alignment
1. AWS Cloud Adoption Framework (CAF)
What is it?
A guideline to plan and successfully transition from on-premises infrastructure to the cloud. It is a planning tool, not a deployment tool.
The 6 Perspectives
CAF breaks cloud adoption into 6 perspectives — 3 Business and 3 Technical.
Business Perspectives
| Perspective | Focus Areas |
|---|---|
| Business | IT finance, IT strategy, benefit realization, business risk management |
| People | Organizational change management, employee training, skills readiness |
| Governance | Project management, IT performance, business alignment, license management |
Technical Perspectives
| Perspective | Focus Areas |
|---|---|
| Platform | Compute provisioning (EC2), network (VPC), storage (EBS, S3), application design |
| Security | Identity (IAM), data protection, security controls, incident response |
| Operations | Monitoring, maintenance, performance, disaster recovery |
Key Takeaway
Before moving to cloud, evaluate all 6 perspectives. Even if technology is ready, failure to train people or align governance will cause the migration to fail.
2. AWS Well-Architected Framework (WAF)
What is it?
A guideline for designing and operating cloud systems efficiently, securely, and cost-effectively. It is an operational/design tool (post-planning phase).
| CAF | WAF | |
|---|---|---|
| Purpose | Plan the transition | Design and operate in the cloud |
| Phase | Pre-migration | Post-migration / ongoing |
Features
- Questions to critically evaluate architectural decisions
- Domain-specific labs and hands-on guidance
- AWS Well-Architected Tool (self-service review)
- Does not prescribe implementation details — that is up to the team
The 6 Pillars
| Pillar | Core Question | Key Actions |
|---|---|---|
| Operational Excellence | Are we delivering business value and improving? | Perform ops as code, make small reversible changes, anticipate failure, learn from events |
| Security | Are we protecting our systems and data? | Use IAM, enable traceability, apply security at all layers, automate security best practices, encryption at rest & in transit |
| Reliability | Can the system recover and meet demand? | Test recovery procedures, auto-recover from failure, scale horizontally, stop guessing capacity |
| Performance Efficiency | Are we using resources efficiently? | Use right-sized instances, go serverless where possible, experiment often, use data to drive decisions |
| Cost Optimization | Are we eliminating waste? | Use consumption-based model, measure efficiency, reduce data center spend, attribute costs |
| Sustainability | Is our cloud usage environmentally responsible? | Understand energy impact, set sustainability goals, maximize utilization, adopt efficient hardware/software |
📝 Instructor Note: Reliability and High Availability is the most important pillar for this KC and exam. Sustainability has only 1 KC question — just have a general idea.
Each Pillar Provides Two Types of Guidance
- Design Principles
- Best Practices
3. Well-Architected Design Principles
These are the core design principles of the WAF (cross-pillar):
| Principle | Explanation |
|---|---|
| Stop guessing capacity | Use Auto Scaling to scale up/down automatically; avoid over- or under-provisioning |
| Test systems at production scale | Duplicate the production environment on-demand, test, then shut it down — no wasted cost |
| Automate to ease experimentation | Automate resource provisioning and deployment using code (Terraform, Python, Bash) |
| Allow for evolutionary architectures | Cloud is dynamic; design systems that can change over time without full rebuilds |
| Drive architecture using data | Make data-driven decisions about scaling, resizing, and redesigning |
| Improve through game days | Deliberately simulate failures to find weaknesses, practice recovery, and minimize downtime |
4. Reliability and High Availability
Definitions
| Term | Definition | Measurement |
|---|---|---|
| Reliability | System is working as expected | MTBF = Total Time in Service ÷ Number of Failures |
| Availability | System is up and running (resources accessible) | % uptime; measured in "nines" |
| Failure Rate | Number of Failures ÷ Total Time | — |
Availability — The "Nines" Scale
| Nines | Availability % | Max Downtime / Year | Max Downtime / Day |
|---|---|---|---|
| 1-nine | 90% | ~36 days | ~2.5 hours |
| 2-nines | 99% | ~3.65 days | ~14 minutes |
| 3-nines | 99.9% | ~8.7 hours | ~1.4 minutes |
| 4-nines | 99.99% | ~52 minutes | ~8.6 seconds |
| 5-nines | 99.999% | ~5 minutes | ~0.86 seconds |
Amazon S3 offers 11 nines (99.999999999%) of durability.
High Availability — 3 Prime Factors
| Factor | Definition |
|---|---|
| Fault Tolerance | Redundant components take over if one fails (e.g., Multi-AZ deployment) |
| Scalability | Ability to increase or decrease resources without redesigning (Auto Scaling) |
| Recoverability | Ability to restore service after a failure, disaster, or catastrophic event |
On-Premises vs. AWS High Availability
| On-Premises | AWS | |
|---|---|---|
| Cost | High — requires dedicated redundant hardware | Lower — pay for what you use |
| Suitable for | Mission-critical only | Any workload |
| Redundancy | Limited to owned hardware | Multiple AZs per Region, multiple Regions worldwide |
5. Traditional → AWS Service Mapping
A corporate data center can be mapped to AWS equivalents:
| Traditional Component | AWS Equivalent |
|---|---|
| Physical Server | Amazon EC2 |
| Web Server | Amazon EC2 |
| Application Server | Amazon EC2 / AWS Lambda (serverless) |
| Load Balancer | Elastic Load Balancer (ELB) |
| Primary / Secondary Database | Amazon RDS (with Multi-AZ) |
| Storage Area Network (SAN) | Amazon EBS (Elastic Block Store) |
| Network Attached Storage (NAS) | Amazon EFS (Elastic File System) |
| Tape Backup / Backup Storage | Amazon S3 |
| Microsoft Active Directory | AWS Directory Service |
Note on Lambda: "Serverless" doesn't mean no server — it means you don't manage the server. AWS manages the underlying compute. Lambda runs on something like EC2, but it's abstracted away.
6. Lab 16: Amazon Aurora / RDS Challenge
Objective
Launch an Amazon Aurora (MySQL-compatible) or RDS MySQL database, connect to it from an EC2 instance, and run SQL queries.
Steps Overview
- Create a DB Subnet Group — Go to RDS > Subnet Groups > Create. Use Lab VPC, select private subnets.
- Create a DB Security Group — Go to VPC > Security Groups > Create.
- Name:
DB-Security-Group - VPC:
Lab VPC - Inbound Rule: Type = MySQL/Aurora, Source =
Web-Security-Group(this is critical)
- Name:
- Launch RDS Database — RDS > Create Database > Aurora (MySQL-compatible) or MySQL
- Instance class:
db.t3.medium - VPC:
Lab VPC - Subnet group:
DB-Subnet-Group - Security group:
DB-Security-Group(not Web Security Group) - Uncheck: Enhanced Performance Insights, Enhanced Monitoring, Auto minor version upgrade
- Set initial database name (e.g.,
awsrestart)
- Instance class:
- Connect to EC2 via SSH — Download
.pemkey, copy public IP, SSH in - Install MySQL Client on EC2:
sudo yum install mysql -y - Connect to RDS using writer endpoint:
mysql -u admin --password='yourpassword' -h <writer-endpoint> - Run SQL (Steps 11–17): Create tables, insert data, run SELECT queries
USE awsrestart; SELECT * FROM restart;
Common Issues & Fixes
| Issue | Fix |
|---|---|
| Cannot connect to DB | Check DB Security Group inbound rule — source must be Web Security Group |
| Permission denied on SSH | Verify you are using the correct .pem key file |
--password not working | Use double dash: --password='yourpassword' |
| Lab time expired | Click "Start Lab" again; you must redo from the beginning |
| Cannot find endpoint | RDS > Your Cluster > Endpoints tab > copy Writer Endpoint |
⏰ Time tip: This lab takes longer than 1 hour. Track your time and submit before the timer runs out. Repeat session scheduled for next day at 2:00 PM.
CLF-C02 Exam Alignment
The following topics from this lecture are directly tested on the AWS Certified Cloud Practitioner (CLF-C02) exam:
| Topic | CLF-C02 Domain | Notes |
|---|---|---|
| AWS Cloud Adoption Framework (CAF) — 6 perspectives | Domain 2: Security & Compliance / Domain 4: Billing & Support | Know the two categories (Business vs. Technical) and all 6 perspective names |
| AWS Well-Architected Framework — 6 pillars | Domain 3: Cloud Technology & Services | Know all 6 pillar names and their core purpose |
| WAF Design Principles (stop guessing capacity, game days, etc.) | Domain 3 | Understand what each principle enables |
| Reliability vs. Availability — definitions | Domain 3 | Know the difference; reliability = works as expected, availability = is running |
| High Availability factors: fault tolerance, scalability, recoverability | Domain 3 | Common exam vocabulary — know all 3 |
| Fault tolerance — Multi-AZ | Domain 3 | Multi-AZ as a mechanism for fault tolerance |
| Auto Scaling — stop guessing capacity | Domain 3 | AWS solution for elastic capacity |
| Traditional → AWS service mapping (EC2, ELB, RDS, S3, EBS, EFS) | Domain 3 | Core services and their use cases |
| AWS IAM — identity and access management | Domain 2: Security & Compliance | Mentioned under Security pillar |
| Encryption at rest and in transit (EBS, EFS, S3) | Domain 2 | Mentioned under Security pillar |
| Shared Responsibility Model (implicit) | Domain 2 | Context for security pillar |
| Amazon RDS / Aurora | Domain 3 | Covered in lab; RDS = managed relational database |
| Amazon S3 durability (11 nines) | Domain 3 | Specific exam fact worth remembering |
Instructor Emphasis
- Most important for KC/exam: Reliability and High Availability concepts
- Sustainability: Just have a general idea — only 1 KC question
- Security pillar: Foundational but only 1 KC question in this module
Notes compiled from lecture transcript — Cohort 3: Project CloudIgnite, June 5, 2026