The Well-Architected Framework

Why a framework

Everything in this course, from IAM to backups, is one piece of a good design. It is easy to get some pieces right and forget others: a fast, cheap system with no backups, or a secure one that nobody can operate. The AWS Well-Architected Framework gathers years of AWS experience into questions you ask about any workload (a workload is a set of resources and code that delivers one business function, such as "the results website"). It does not give one correct architecture; it helps you see trade-offs and risks.

The six pillars

The pillars pull against each other. A warm standby in a second region improves reliability but costs more. Caching improves performance but adds something to operate. A good review makes these trade-offs on purpose, based on what the business needs, instead of by accident.

The Well-Architected Tool and reviews

The AWS Well-Architected Tool is a free service in the AWS console. You define a workload, answer the questions for each pillar, and the tool lists high-risk and medium-risk issues with links to guidance, plus an improvement plan. You can save milestones to track progress over time. Lenses add questions for specific kinds of workload, such as the Serverless Lens. Many teams run a review with an AWS solutions architect or partner before a big launch and then every year.

Other clouds

Microsoft publishes the Azure Well-Architected Framework with five pillars: Reliability, Security, Cost Optimization, Operational Excellence and Performance Efficiency. Google Cloud publishes its own framework, earlier called the Google Cloud Architecture Framework and more recently the Google Cloud Well-Architected Framework; check the current name and pillars in the Google Cloud documentation. The ideas are almost the same across all three.

Design patterns that keep coming back

• Decouple with queues: the web tier puts a message on a queue (Amazon SQS) and workers process it later. Spikes wait in the queue instead of crashing workers, and failed jobs are retried. (Reliability, Performance)
• Cache: keep hot data in ElastiCache or in the app, so the database does less work. (Performance, Cost)
• Use a CDN: Amazon CloudFront serves images, videos and static pages from edge locations near users, such as in Indian cities, which is faster and takes load off your servers. (Performance, Cost)
• Multi-AZ everywhere: no single server, zone or database copy whose loss stops the system. (Reliability)
• Infrastructure as code: every environment is built and changed by reviewed code. (Operational Excellence, Reliability)
• Least privilege: every person and service gets only the permissions it needs. (Security)

A reference three-tier design for an Indian ed-tech app

Picture an ed-tech app with live classes, recorded videos, mock tests and certificates, serving students across India. A design that answers the six pillars well could look like this, in the Mumbai region (ap-south-1):

1. Edge: Route 53 for DNS, CloudFront for the web app, images and recorded videos (stored in S3), with AWS WAF in front to block common attacks.
2. Web and app tier: an Application Load Balancer in public subnets across three AZs, sending traffic to stateless app servers (an Auto Scaling group or containers) in private subnets. Target tracking scaling plus a scheduled action before Sunday mock tests.
3. Data tier: Amazon RDS or Aurora PostgreSQL with Multi-AZ, a read replica for reports and leaderboards, and ElastiCache for sessions and hot question papers. Uploads go straight to S3.
4. Background work: certificate PDFs, emails and video processing go through SQS queues to worker servers, so a slow job never blocks a student's click.
5. Security: IAM roles for every service, secrets in Secrets Manager, encryption with KMS, CloudTrail logs in a separate account.
6. Operations: everything in Terraform or CloudFormation, CloudWatch dashboards and alarms, and runbooks for common incidents.
7. Recovery and cost: AWS Backup with copies to the Hyderabad region (ap-south-2) in a locked vault; Savings Plans for the steady baseline, auto scaling for peaks, and S3 lifecycle rules that move old recordings to cheaper storage.