Common Use-Case Scenarios

Lesson purpose

This capstone lesson ties the course together. The AWS Well-Architected Framework gives a shared vocabulary for judging whether a design is reliable, fast, secure, affordable, well operated, and sustainable. Students then apply earlier lessons in two real builds — a highly available web application (VPC, security groups, load balancer, launch template, Auto Scaling) and a static website on S3 — and finish with a survey of AWS’s AI and machine learning services. It supports CLF-C02 objectives 1.2 and 3.1, with the AI/ML services supporting objective 3.7.

Learning objectives

Name and explain the six pillars of the AWS Well-Architected Framework.
Use the pillars to evaluate trade-offs between two designs.
Describe the purpose of the AWS Well-Architected Tool.
Explain how a load balancer, Auto Scaling group, launch template, and security group combine into a highly available web application.
Explain a target tracking scaling policy.
Distinguish static from dynamic websites and host a static site on S3.
Match AWS AI/ML services to their use cases.

1. The AWS Well-Architected Framework

The Well-Architected Framework is AWS’s set of design principles for weighing the pros and cons of cloud architectures. Its six pillars work as goals:

Reliability

Avoid complete failure of the application, which may depend on compute, storage, database, and networking resources. Reliability requires two things:

Prevent resource failures (from misconfiguration, overload, or accidental or intentional shutdown).
When a failure happens — and it will — replace the failed resource with a healthy one.

Replacing instead of repairing is a key cloud idea: rebuilding a misconfigured instance is faster than diagnosing it, and one recovery method covers many kinds of failure.

Performance efficiency

Get the performance you need without overprovisioning and without sacrificing reliability: enough resources for redundancy and growing demand, but no more. Monitoring utilization and adjusting is essential, because an overloaded resource both performs poorly and may fail. Network distance matters too: users in Australia reaching a US Region see latency, and a CloudFront distribution fixes that cheaply.

Security

Protect the confidentiality, integrity, and availability of data:

Least privilege — grant delete or modify access only to principals who need it (IAM user and resource policies).
Backups and replication — EBS snapshots for instances; S3 versioning and replication for objects.
Encryption — for data at rest (EBS, S3) and in transit.
Logging — record all activity (CloudTrail, CloudWatch) to measure how well controls work and to investigate incidents.
Trusted Advisor (Lesson 3) gives specific security recommendations.

Cost optimization

Meet your needs at the lowest possible cost — not simply the lowest cost. Cutting cost in a way that makes an important application unreliable is not optimization.

Find where the money goes: Cost Explorer, Cost and Usage Reports, and cost allocation tags (Lessons 2 and 6).
Pay only for what you need: terminate test instances when not in use.
Use Reserved Instances, Savings Plans, and Spot instead of On-Demand where they fit (Lesson 7).
Count operating costs, not just hourly prices: RDS costs more per hour than MySQL on EC2, but saves the labor of backups, upgrades, and monitoring.

Operational excellence

Automate the processes that achieve and maintain the other pillars, improving a little at a time — a journey, not a finish line.

Pillar supported	Automation example
Reliability	Load balancer health checks route users away from a failed instance, and a replacement is launched
Performance efficiency	Auto Scaling dynamic policies add and remove instances with demand
Security	CodeBuild tests new code for vulnerabilities; CloudFormation deploys fresh, secure infrastructure instead of following a manual checklist
Cost optimization	S3 life-cycle rules delete unneeded objects; test instances stop after business hours and restart in the morning

Many automation opportunities appear only after a failure — for example, someone deletes the load balancer in front of a critical app. Studying how failures affect the application shows what to automate next.

Sustainability

Minimize the environmental impact of cloud workloads — using only the resources needed, choosing efficient services and Regions, and reducing waste. It is aimed at everyone in technology roles, from CTOs to developers and operations staff. (The book’s summary still mentions “five pillars”; sustainability is the sixth, added in 2021.)

Memory aid for the six pillars: “CROPS + S” — Cost optimization, Reliability, Operational excellence, Performance efficiency, Security, plus Sustainability.

AWS Well-Architected Tool

A free console tool that reviews a workload against the framework. You describe the workload, choose one or more lenses (the Well-Architected Framework lens, or specialized ones), answer guided questions, and receive an improvement plan that identifies risks across the six pillars.

Trade-offs and shared responsibility

The pillars help compare designs. Example: a static website on S3 leaves reliability, security of the servers, and scaling to AWS — a sudden flood of visitors is AWS’s job to absorb. The same site on EC2 instances running Apache makes you responsible for patching, capacity, and availability. Another example: Spot is cheaper than On-Demand (cost) but can be interrupted (reliability).

2. Scenario: a highly available web application

Architecture

EC2 Auto Scaling launches two instances in different Availability Zones in the default VPC (which already has a default subnet in each AZ).
An internet-facing Application Load Balancer (ALB) receives client connections and distributes them to the instances running the Apache web server.
The ALB routes to healthy instances in turn (round robin), and its health check also tells Auto Scaling which instances to replace.

Pillars in action: two AZs and self-healing (reliability), scaling with demand (performance efficiency, cost optimization), only HTTP allowed in (security), everything automated (operational excellence).

Step 1: allow HTTP in the security group (Exercise 12.1)

In the EC2 console, open Security Groups, select the default VPC’s default security group, and edit its inbound rules. Add a rule of type HTTP, which fills in protocol TCP and port 80, with source 0.0.0.0/0 (and ::/0 for IPv6) to allow everyone. To allow only one address, enter it with /32 (for example, 198.51.100.100/32). Save.

(Real-world improvement: give the load balancer and instances separate security groups, and let the instance group accept traffic only from the load balancer’s group.)

Step 2: create the Application Load Balancer (Exercise 12.2)

Name: sample-web-app-load-balancer; scheme internet-facing (gets a public DNS name); IPv4.
Listener: HTTP on port 80. (The console warns that there is no HTTPS listener — acceptable for a lab; production sites should use HTTPS with a certificate from AWS Certificate Manager.)
Choose the default VPC and at least two Availability Zones.
Security group: the default group.
Target group: new group sample-web-app-target-group, target type Instance, HTTP port 80, health check HTTP path /. Don’t register targets manually; Auto Scaling will.
Create it, wait for it to become active, and note its DNS name.

Step 3: create a launch template (Exercise 12.3)

The launch template tells Auto Scaling how to build each instance, including a user data script that installs Apache. The book deploys it with a prepared CloudFormation template from an S3 URL: create a stack named sample-app-launch-template, choose an instance type (default t2.micro), and wait for CREATE_COMPLETE. You could also create the launch template manually with an Amazon Linux AMI and the user data script from Lesson 7.

Step 4: create the Auto Scaling group (Exercise 12.4)

From Launch Templates, select the template and choose Create Auto Scaling group; name it sample-web-app.
Choose the default VPC and at least two subnets (AZs).
Attach it to the sample-web-app-target-group load balancer target group.
Set health check type to ELB, so instances whose application fails are replaced — not just instances that stop running.
Group size: desired 2, minimum 1, maximum 3.
Add a target tracking scaling policy: metric average CPU utilization, target 50 percent. Auto Scaling adds instances when average CPU rises above 50 percent and removes them when it falls below, staying between 1 and 3.
Create the group, wait for the instances, and browse to the load balancer’s DNS name to see the Apache test page.

EC2 sends CPU metrics to CloudWatch (kept up to 15 months) for analyzing usage over time.

Clean up: delete the Auto Scaling group (which terminates its instances), the load balancer, the target group, and the CloudFormation stack.

Discussion: terminate one instance by hand and watch the target group mark it unhealthy and Auto Scaling launch a replacement. The site stays up the whole time.

3. Scenario: static website hosting on S3

Static vs. dynamic

A static website serves files — HTML, images, PDFs — exactly as they are stored. “Static” doesn’t mean the site never changes; you can update the files any time.
A dynamic website processes each request on a server, changing content on the fly: webmail, e-commerce sites, WordPress blogs. Rule of thumb: if the site uses a database, it’s dynamic.

Steps

Create an S3 bucket (a name that is unique and easy to type).
Enable static website hosting in the bucket’s Properties, with index.html as the index document (and optionally an error document). S3 shows the website endpoint URL, such as http://bucketname.s3-website-us-east-1.amazonaws.com.
Create and upload an index.html file (for example, containing “Hello, world!”).
Allow public reads and browse to the endpoint.

S3 buckets are private by default, and after many accidental data leaks AWS added safeguards (Lesson 8). Making a site public means deliberately turning some of them off.

Update to the book’s steps: the book grants public access with object ACLs in an older console. Current buckets disable ACLs by default, so the modern approach is to turn off Block Public Access for this bucket only and add a bucket policy that allows anyone to read objects:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadForWebsite",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket-name/*"
    }
  ]
}

"Effect": "Allow" with "Principal": "*" grants access to everyone, including anonymous users.
"Action": "s3:GetObject" allows reading objects only — no one can upload, change, or delete.
"Resource" names every object (/*) in the bucket; replace example-bucket-name with the real bucket name.

Safety reminder: never put anything in a public website bucket that shouldn’t be public.

Custom domains and HTTPS

To use your own domain (for example, example.com) with the S3 website endpoint, the bucket name must match the domain name, and Route 53 can point the domain to it.
The S3 website endpoint supports HTTP only, so browsers warn that the site isn’t secure. Put CloudFront in front of it for HTTPS and faster delivery from edge locations. Current best practice is CloudFront with a private bucket and Origin Access Control (Lesson 10), which avoids making the bucket public at all.

Trade-off recap: S3 hosting is cheap and AWS handles scaling and availability; you can’t run server-side code, so dynamic features require other services.

4. AWS AI and machine learning services

Artificial intelligence (AI) broadly means machines performing tasks that normally need human intelligence; machine learning (ML) is the technique of learning patterns from data. The book uses the terms interchangeably. Cloud practitioners should know what each service is for.

Service	What it does	Example use
Amazon Comprehend	Natural-language processing (NLP): detects language, key topics, sentiment (positive, negative, neutral), and common phrases	Find patterns in customer reviews; organize documents by topic
Amazon Kendra	Intelligent enterprise search across S3, databases, OneDrive, Salesforce, ServiceNow, and more; returns documents and direct answers	Search all company policies and manuals from one box
Amazon Lex	Builds text and voice chatbots (conversational interfaces); pairs with Amazon Polly for natural-sounding speech	Call-center routing, tech support, travel booking
Amazon Polly	Text to speech	Reading content aloud, voice responses
Amazon Rekognition	Identifies people, faces, objects, places, and text in images and video; content moderation; labeling	Tag videos as indoor/outdoor or day/night; flag inappropriate images
Amazon SageMaker	Build, train, and deploy your own ML models; SageMaker Studio, Jupyter notebooks, Python SDK, R support, no-code options	Data scientists creating a custom prediction model
Amazon Textract	Extracts printed text, handwriting, forms (keeping fields with their values), and tables from scanned documents, with confidence scores and natural-language queries	Process invoices, receipts, and forms
Amazon Transcribe	Speech to text, in batch or streaming, with custom vocabularies and automatic redaction of sensitive data	Transcribe support calls or lectures
Amazon Translate	Translates text between languages, using context for ambiguous words; batch or real time	Translate a website or support chats

Key distinction: most of these services are pre-trained — call them through an API with no ML expertise needed. SageMaker is for building custom models.

Modern note: since the book was written, AWS added generative AI services. Amazon Bedrock provides access to foundation models from several companies through one API, and Amazon Q is a generative AI assistant for business users and developers. Current CLF-C02 study materials may include them.

Classroom application

Pillar sort: Give students practices — Multi-AZ RDS, S3 life-cycle rules, MFA on root, Auto Scaling, CloudFormation deployments, right-sizing instances, CloudFront — and have them assign each to one or more pillars.
Trade-off debate: Compare S3 static hosting with EC2 + Apache for a department website, and Spot vs. On-Demand for a nightly batch job, using the pillars as criteria.
Lab: Build the highly available web application (Exercises 12.1–12.4), then terminate an instance to demonstrate self-healing. Delete everything afterward.
Lab: Host a one-page static site on S3 with a bucket policy; discuss why CloudFront would be the production choice.
Service match: A hospital digitizing paper intake forms (Textract), a help desk wanting a chatbot (Lex), a podcast needing captions (Transcribe), a retailer analyzing review sentiment (Comprehend), a site serving Spanish-speaking customers (Translate), a researcher building a custom model (SageMaker).
Architecture reading: Show a simple architecture diagram and ask students to explain how each component supports reliability, security, or cost.

Common misconceptions

“Cost optimization means spending as little as possible.” It means meeting requirements at the lowest cost, without harming reliability or security.
“Reliability means nothing ever fails.” Failures are expected; reliability means recovering automatically, often by replacing failed resources.
“There are five Well-Architected pillars.” There are six; sustainability was added.
“A static website never changes.” Static means files are served as stored; they can be updated anytime.
“S3 website endpoints support HTTPS.” They don’t; use CloudFront for HTTPS.
“The EC2 health check is enough.” An instance can be running while its application is broken; the ELB health check catches that.
“You need to be a data scientist to use AWS AI services.” Most are pre-trained APIs; SageMaker is the one for building custom models.

Lesson summary

The AWS Well-Architected Framework has six pillars: reliability (avoid total failure and replace failed resources), performance efficiency (right-sized resources that meet demand), security (least privilege, backups, encryption, and logging), cost optimization (meet needs at the lowest possible cost, including operating cost), operational excellence (automate to support the other pillars), and sustainability (minimize environmental impact). The Well-Architected Tool reviews workloads against these pillars and produces an improvement plan, and the pillars guide trade-offs between designs within the shared responsibility model. A highly available web application combines a security group that allows HTTP, an internet-facing Application Load Balancer across two AZs, a launch template that installs Apache, and an Auto Scaling group that uses ELB health checks and a target tracking policy to scale between one and three instances. A static website can be hosted cheaply on S3 by enabling static website hosting and allowing public reads, with CloudFront added for HTTPS and speed. AWS AI/ML services include Comprehend, Kendra, Lex, Polly, Rekognition, SageMaker, Textract, Transcribe, and Translate, with newer generative AI services such as Amazon Bedrock and Amazon Q.