AWS Well-Architected Framework and Cost Basics

AWS Cloud & DevOps Engineering · Lesson 11 · AWS Cloud Foundations

Lesson Overview

Module 1 gave TechLearningPro identity, network filters, replaceable compute, storage that survives instance death, and databases that hold progress truth. None of those choices are finished until someone asks whether they are secure, reliable, performant, operationally sane, cost-aware, and sustainable. The AWS Well-Architected Framework is that structured questioning. Cost Explorer, budgets, and tags turn the answers into money you can see before finance sees it.

This lesson ties the module together. It does not award certifications and does not invent exam guarantees. It teaches you to run a lightweight Well-Architected-style review on the progress API stack you have been designing, to place AWS Budgets before labs become lifestyle, and to read Cost Explorer concepts so idle NAT Gateways, forgotten RDS instances, and unlifecycle’d S3 prefixes stop being mysteries. Later, FinOps, Cost Explorer and Cost Optimization goes deeper; here you build the habit.

Learning Objectives

By the end of this lesson you will be able to:

1. Name the Well-Architected pillars and what questions each asks of the progress platform.
2. Map lessons 2–10 decisions onto pillars (IAM, SG, ASG, S3, RDS, cache).
3. Run a lightweight review and prioritize improvements by risk, not by shiny services.
4. Explain cost allocation tags and why untaggled resources fight FinOps.
5. Use Budgets (or equivalent) as a prerequisite for billable learning.
6. Describe Cost Explorer concepts: time range, group by service, filter by tag.
7. Separate unit price curiosity from architecture waste (idle, oversize, wrong storage class).
8. Avoid fake precision: no invented tariffs; look up the current price card when needed.
9. Connect reliability spend to Monday’s SLO instead of cutting blindly.
10. Exit Module 1 ready for load balancing and the application platform module.

Prerequisites

• Lessons 1–10 concepts available as a mental inventory of your sandbox design.
• Access to billing/cost views in a sandbox or to screenshots from an account owner if IAM blocks billing.
• Willingness to delete resources that fail the review’s cost questions.

Detailed Core Concepts

What Well-Architected is

The Framework is a set of design principles and questions organized into pillars. AWS also provides the Well-Architected Tool to record answers—optional for this lesson. The point is disciplined review, not a badge. Pillars commonly taught:

1. Operational Excellence — run, monitor, improve; IaC and runbooks over heroics.
2. Security — identity, detection, infrastructure protection, data protection, incident response.
3. Reliability — foundations, change management, failure management; Multi-AZ, backups, Auto Scaling.
4. Performance Efficiency — right resource types, monitoring, trade-offs.
5. Cost Optimization — awareness, measurement, right sizing, elastic spend.
6. Sustainability — utilization, reduce waste, efficient regions and architectures.

Exact pillar wording and question catalogs evolve—use the current Framework whitepaper as source of truth. This lesson uses stable intent.

Mapping TechLearningPro Module 1 to pillars

A review that only discusses EC2 instance size and ignores IAM and backups is incomplete.

Cost basics without fake prices

Tags: Project, Owner, Environment, CostCenter—agree a dictionary. Activate cost allocation tags in billing. Untagged resources are a backlog.

Budgets: alert on actual or forecasted spend. Every lab in this course assumed one. Module exit means you keep budgets for shared sandboxes.

Cost Explorer concepts: choose a time range; group by service; filter by tag Project=tlp-*; find the top services. Typical Module 1 culprits: NAT Gateway hours, idle load balancers, RDS, ElastiCache, forgotten interface endpoints, unattached EBS, snapshots.

Pricing dimensions awareness: compute hours, storage GB-month, requests, data transfer, managed service capacities. Look up current cards when estimating; do not memorize folklore numbers from blogs.

Commitments: Savings Plans and Reserved Instances reduce rates for steady state. Foundations: do not buy long commitments in personal sandboxes to practice. Learn the concept; purchase only with org process.

Review method

1. Draw the progress API architecture you claim.
2. For each pillar, answer three questions: What could go wrong Monday? What evidence do we have? What is the next improvement?
3. Rank improvements: security holes and data-loss risks first; then reliability gaps; then waste.
4. Assign owners and dates.
5. Delete or stop lab waste the same day.

Architecture and Design Diagrams

mermaidCopy
flowchart TB
  subgraph pillars [Well-Architected lenses]
    OE[Operational Excellence]
    SEC[Security]
    REL[Reliability]
    PERF[Performance]
    COST[Cost]
    SUS[Sustainability]
  end
  Stack["Progress API stack\nIAM VPC SG ASG S3 DB Cache"] --> pillars
  pillars --> Backlog["Prioritized backlog"]
  COST --> Budgets["Budgets + Cost Explorer"]
  Backlog --> Module2["Module 2 edge and platform"]

textCopy
Inventory → Tag → Budget → Review pillars → Prioritize → Fix/delete → Re-measure

Technical Explanation

Operational Excellence for foundations

Can you recreate the environment from templates? Is there a runbook for ASG launch failures? Are changes reviewed? Even without full IaC yet (Module 3), write the intended state. Prefer Session Manager audit logs over undocumented SSH.

Security

IAM least privilege, CloudTrail presence awareness, private subnets, SG matrices, encryption on S3/EBS/RDS, no public DB, secrets not in user data. Security findings beat cost savings that open buckets.

Reliability

Multi-AZ ASG floors, Multi-AZ RDS for production claims, backup restore dates, health checks that match failure domains, dependency timeouts. Reliability spend is often the On-Demand floor and Multi-AZ—name it as the price of Monday.

Performance Efficiency

Right-sized instances, DynamoDB access patterns instead of scans, S3 for static assets instead of EFS, caches with invalidation. Performance work without metrics is guessing.

Cost Optimization

Turn off idle; lifecycle storage; prefer endpoints over NAT where suitable; delete labs; right-size after metrics; use Spot only above reliability floors. Cost Explorer finds what architecture review should have prevented.

Sustainability

Less idle, fewer duplicate stores, efficient Regions when latency allows, Graviton when compatible—utilization is the common thread with cost.

Practical Implementation or Design Walkthrough

Problem

Run a Well-Architected-style review on your Module 1 design (real sandbox or paper design). Produce a scored backlog, a Cost Explorer-style inventory (or describe how you would filter by tag), confirm budgets, and delete waste.

Steps

1. Inventory resources with your tags; list untagged.
2. Open Cost Explorer (or billing) for last 7 days; group by service; note top three.
3. Answer pillar questions in a one-page table.
4. Prioritize five improvements with owners.
5. Execute at least two: e.g., enable a missing budget alert; delete idle NAT/RDS/endpoints; tighten a 0.0.0.0/0 SSH rule still lingering.
6. Record before/after resource list.

Deliverable template

Pillar | Risk | Evidence | Action | Priority

Enterprise Real-World Scenarios

TechLearningPro: the silent NAT

Cost Explorer showed NAT Gateway dominating a sandbox account used for lessons 6–10. Instances used NAT for S3 and SSM instead of endpoints. Review action: add gateway/interface endpoints for required services, update routes, delete NAT if unused, measure again. Security improved by reducing internet path dependency for AWS APIs; cost fell; sustainability improved via less hairpinning.

Well-Architected theater

A team completed the Tool with green answers without Multi-AZ or restore tests. An AZ blip failed the board. Postmortem: reviews need evidence links—ASG screenshot, restore ticket date, SG matrix—not checkbox optimism. This course requires evidence.

Tag mutiny

Finance cannot attribute spend. Engineering claims “tags slow us down.” Leadership freezes new untagged accounts via policy. Foundations habit of tagging every lab resource prevents the freeze drama later.

Best Practices

• Review architectures on a cadence, not only after outages.
• Prioritize security and data loss over cosmetic optimization.
• Budgets before billable experiments.
• Activate and require cost allocation tags.
• Use Cost Explorer grouped by service and tag weekly in shared sandboxes.
• Tie reliability spend to explicit Monday outcomes.
• Delete orphan snapshots, EIPs, idle DBs.
• Prefer measurement over folklore prices.
• Record restore test dates as reliability evidence.
• Keep Module 5/FinOps backlog honest—do not pretend foundations finished ops.
• Align sustainability with utilization, not greenwashing slides.
• Fix 0.0.0.0/0 admin paths immediately when found.
• Document owners on every action item.
• Re-measure cost after changes.
• Refuse certification claims as proof of production readiness.

Common Mistakes and Anti-Patterns

Checkbox Well-Architected without evidence. False confidence.

Cutting Multi-AZ to save money without changing the reliability promise. Quiet SLO breach.

No budgets in sandbox. Surprise bills.

Untagged shared environments. Unallocatable cost.

Inventing unit prices in design docs. They rot; link the price card instead.

Optimizing EC2 while NAT and idle RDS dominate. Wrong layer.

Buying Savings Plans on a toy account. Process violation and waste risk.

Ignoring sustainability as “not our pillar.” Idle waste is both cost and carbon proxy.

Treating Framework as an exam dump. This course is engineering judgment.

Leaving lab endpoints forever after a review that mentioned them. Hypocrisy as architecture.

Troubleshooting and Design Review

Cost Explorer empty for tags. Tags not activated for cost allocation; wait for billing pipeline; wrong tag key.

Budget did not fire. Threshold, actual vs forecast, email not verified, wrong linked account.

Review too large. Scope to one workload—the progress API—per session.

Disagreement on priority. Use data-loss and public exposure as hard tops.

Design review exit criteria for Module 1: private data stores, replaceable compute, encrypted storage, budget present, top cost drivers known, top five backlog items owned.

Interview Questions and Answers

Q1. Name the Well-Architected pillars and one Module 1 example each.

Ops: runbooks for ASG failure. Security: SG least privilege. Reliability: Multi-AZ ASG/DB. Performance: avoid DynamoDB scans. Cost: delete idle NAT. Sustainability: reduce idle resources.

Q2. How do tags enable Cost Explorer usefulness?

Filter and group spend by workload/owner after activating cost allocation tags; without them, Explorer shows only coarse service totals.

Q3. Why not cut the On-Demand ASG floor first?

It may be the reliability budget for Monday. Cut idle and waste first; cut floor only if the SLO changes.

Q4. What is a budget alert’s role in learning accounts?

Early signal for forgotten managed services and endpoints; cultural gate before creating billable resources.

Q5. How is Cost Explorer different from the price calculator?

Explorer analyzes actual historical spend in your account. Calculators estimate future designs. Both matter; neither replaces architecture judgment.

Q6. Give a security finding that beats a cost saving.

Closing public RDS or public S3 beats keeping a cheap misconfiguration.

Q7. What evidence makes a reliability answer credible?

Restore test date, failover exercise notes, ASG replacement test, Multi-AZ configuration screenshots.

Q8. How does sustainability overlap cost?

Idle and over-provisioned resources waste money and energy; utilization improvements serve both.

Q9. What belongs in FinOps later vs now?

Now: tags, budgets, Explorer literacy, delete waste. Later: commitment strategy, chargeback, advanced anomaly detection, org-wide policy.

Q10. Does completing this lesson certify you as an AWS Solutions Architect?

No. This course makes no certification claims. It builds engineering practice.

Q11. How would you prioritize five backlog items?

Public exposure and backup gaps first; then single-AZ critical stores; then idle spend; then right-sizing with metrics; then nice-to-have tooling.

Q12. How do Module 2 load balancers change the review?

They add reliability and cost line items; health checks improve reliability evidence; ALB hours appear in Explorer—include them in tags and budgets.

Hands-On Exercises

Exercise: Review + cost pass

Run the pillar table on your Module 1 design, capture Cost Explorer top services (or explain access limits), verify budgets, execute two remediations, document cleanup.

Challenge

Write an ADR that refuses to reduce RDS Multi-AZ for a month to hit a savings target, proposing alternative savings from NAT/endpoints/lifecycle instead, with Explorer evidence.

Worked review: TechLearningPro progress API (example answers)

Operational Excellence. Today the environment can be rebuilt only partially: VPC and security groups are documented in a matrix, but the launch template version is pinned in a wiki that drifts. Improvement: store template version and AMI ID in a small infrastructure repository even before full Module 3 IaC. Runbook exists for Session Manager access; missing is a runbook for ASG LaunchFailed due to subnet IP exhaustion. Owner: platform team. Due: two weeks.

Security. IAM roles for instances are least privilege for S3 prefixes; humans still have broad power in the sandbox. Production path requires Identity Center permission sets from lesson 2. Security groups reference tiers correctly; one lab SG still allows SSH from a wide CIDR—delete this week. Encryption is on for S3 and EBS; RDS encryption verified. CloudTrail is enabled at account level—confirm. Secrets are not in user data. Public accessibility on databases is false.

Reliability. ASG min 2 across two AZs with ALB planned in Module 2. RDS Multi-AZ not yet enabled on the pilot—risk accepted only for named pilot cohort with written expiry. Restore test never run—schedule sandbox restore this week. Cache is disposable. Health check path is local /health not deep dependent on RDS, avoiding replace storms during DB patching.

Performance Efficiency. Board aggregation query needs an index review; risk of sequential scans on enrollments. S3 serves assets; EFS not used. Instance size is burstable—watch credits on Monday. DynamoDB not yet used; feature flags still in relational tables acceptably for now.

Cost Optimization. Cost Explorer last seven days: NAT Gateway and RDS dominate. Action: VPC endpoints for S3/SSM; stop pilot RDS outside business hours if SLO allows, or snapshot and delete between pilots. Budgets alert at a threshold agreed with the account owner. Tags: 90% coverage; remediate untagged EIPs.

Sustainability. Idle NAT and always-on pilot RDS are the utilization opportunities. No multi-Region copies without consumers.

Cost Explorer walkthrough narrative

Open Cost Explorer. Set the range to the last fourteen days to cover a full lab week plus weekend idle. Group by service. Note the top three bars. Then filter by tag Project = tlp-lesson08 and see whether compute labs still bill—if yes, ASG or instances survived. Clear the filter; group by usage type for the NAT service family and confirm hourly presence. Export CSV for the deliverable. If your IAM cannot read billing, paste the missing permission names into the deliverable and stop inventing charts. Honesty is graded.

Create or open a budget for the sandbox monthly actual spend with email to the shared team list. Add a second forecasted alert at a lower threshold if available. Trigger a test notification if the product supports it. Screenshot the budget configuration with account IDs redacted if sharing outside the org.

Prioritization rubric you can reuse

Severity 1: public data stores, world-open admin ports, missing encryption on learner data, no backups on claimed production. Severity 2: single-AZ critical path, untested restore, ASG min 1 for Monday board. Severity 3: idle managed networking, oversized labs, missing tags, absent budgets. Severity 4: right-sizing with incomplete metrics, commitment purchases, cosmetic Tool completion. Execute Severity 1 the same day. Never trade Severity 1 for Severity 3 savings.

Connecting every Module 1 lesson in one paragraph each

Lesson 1’s Regions and AZs become reliability and cost locality choices. Lesson 2’s Organizations and Identity Center become security and chargeback boundaries. Lesson 3’s IAM becomes every service’s authorization plane. Lesson 4’s CLI access becomes how you evidence cleanup. Lesson 5–7’s networking becomes blast radius and endpoint strategy. Lesson 8’s ASG becomes reliability elasticity. Lesson 9’s storage classes and lifecycle become cost and sustainability levers. Lesson 10’s Multi-AZ databases and disposable caches become reliability with clear systems of record. Lesson 11 asks whether you can defend all of that in one review without mythical prices or mythical certifications.

Anti-pattern: savings that break Monday

Turning off Multi-AZ RDS the night before a launch, lowering ASG min to one, lengthening cache TTL until certificates look wrong, or blocking Flow Logs that you needed for a security investigation are all “savings” that create larger incidents. The Framework’s value is forcing the trade-off into writing. If leadership wants the savings, they also accept the new reliability statement—or they do not get the savings.

Lab cleanup as exam of character

List every resource with your Project tag across EC2, ASG, ELB, RDS, ElastiCache, DynamoDB, S3, EFS, VPC endpoints, NAT, EIP, snapshots. Delete in dependency order. Confirm Cost Explorer tomorrow still shows residual snapshots if any and schedule their deletion. A Module 1 that ends with a clean account is itself a Well-Architected outcome.

What Module 2 will add to the review

Load balancers add health-check reliability and hourly cost. Route 53 adds DNS failover patterns and query costs that are usually small but operationally critical. CloudFront later moves transfer cost and security to the edge. Each time you add a service, extend tags, budgets, and the pillar table—do not wait for an annual architecture festival.

Interview story you should practice aloud

“I reviewed our progress API against Well-Architected. We found a public SSH rule in a leftover lab SG, no RDS restore test, and NAT dominating sandbox spend. We closed the SSH rule the same day, scheduled a restore game day, added S3 and SSM endpoints, and deleted the NAT. Cost Explorer by tag proved the NAT line dropped. I did not buy Savings Plans for a sandbox, and I did not claim a certification as proof the workload was sound.”

Evidence packet checklist

Architecture diagram; SG matrix; launch template version; ASG min/desired/max; DB Multi-AZ and backup retention; last restore date; encryption flags; budget ID; Cost Explorer top services screenshot; tagged resource inventory; backlog with owners; cleanup confirmation. If an item is missing, the review is incomplete.

Sustainability micro-decision log

Record three decisions that reduced idle capacity or duplicated storage: for example, deregistering lab AMIs, expiring S3 tmp prefixes, removing unused interface endpoints, refusing a second Region until a consumer exists. These notes train teams to see utilization as a first-class metric beside latency.

Framework Tool optional path

If you use the Well-Architected Tool, create one workload named tlp-progress-api-sandbox, answer questions with links to evidence, and generate an improvement plan. Export milestones. Do not chase a perfect score; chase owned actions. If the Tool is unavailable, the one-page pillar table in this lesson is enough for foundations credit.

Finance partnership script

Bring Explorer charts grouped by tag, a list of idle resources deleted this month, and the reliability items you refused to cut. Ask finance which cost centers tags should use. Agree that untagged production is a defect. This conversation prevents surprise invoices and prevents finance from mandating unsafe cuts.

Worked review: TechLearningPro progress API (example answers)

Operational Excellence. Today the environment can be rebuilt only partially: VPC and security groups are documented in a matrix, but the launch template version is pinned in a wiki that drifts. Improvement: store template version and AMI ID in a small infrastructure repository even before full Module 3 IaC. A runbook exists for Session Manager access; missing is a runbook for ASG LaunchFailed due to subnet IP exhaustion. Owner: platform team. Due: two weeks. Change management for security group edits should require a ticket referencing the connectivity matrix row being altered, so Monday incidents do not invent rules under panic.

Security. IAM roles for instances are least privilege for S3 prefixes; humans still have broad power in the sandbox. Production path requires Identity Center permission sets from lesson 2. Security groups reference tiers correctly; one leftover lab SG still allows SSH from a wide CIDR—delete this week. Encryption is on for S3 and EBS; RDS encryption verified. CloudTrail is enabled at account level—confirm destinations and retention. Secrets are not in user data. Public accessibility on databases is false. Bucket Block Public Access is on. These are evidence items, not vibes.

Reliability. ASG min 2 across two AZs with ALB planned in Module 2. RDS Multi-AZ is not yet enabled on the pilot—risk accepted only for a named pilot cohort with written expiry. Restore test never run—schedule sandbox restore this week. Cache is disposable. Health check path is local /health, not deeply dependent on RDS, avoiding replace storms during DB patching. Document what happens when the cache is flushed during standup.

Performance Efficiency. Board aggregation query needs an index review; risk of sequential scans on enrollments. S3 serves assets; EFS is not used for static media. Instance size is burstable—watch credits on Monday. DynamoDB is not yet used; feature flags still in relational tables acceptably for now. Avoid DynamoDB scans if feature flags move later. Prefer measuring latency under forty concurrent board readers before changing instance families.

Cost Optimization. Cost Explorer last seven days: NAT Gateway and RDS dominate. Action: VPC endpoints for S3 and SSM; stop pilot RDS outside business hours if the SLO allows, or snapshot and delete between pilots. Budgets alert at a threshold agreed with the account owner. Tags: aim for complete coverage; remediate untagged Elastic IPs. Do not invent unit prices in the review document; link the pricing page if someone needs arithmetic.

Sustainability. Idle NAT and always-on pilot RDS are the utilization opportunities. Refuse multi-Region copies without consumers and without a restore drill. Deregister lab AMIs that nobody will launch again.

Cost Explorer walkthrough narrative

Open Cost Explorer. Set the range to the last fourteen days to cover a full lab week plus weekend idle. Group by service. Note the top three bars. Then filter by tag Project = tlp-lesson08 and see whether compute labs still bill—if yes, an ASG or instances survived. Clear the filter; group by usage type for the NAT family and confirm hourly presence. Export CSV for the deliverable. If your IAM cannot read billing, write the exact missing permissions into the deliverable and stop inventing charts. Honesty is graded higher than a fake screenshot.

Create or open a budget for the sandbox monthly actual spend with email to the shared team list. Add a forecasted alert at a lower threshold if available. Trigger a test notification if the product supports it. Screenshot the budget configuration with account IDs redacted if sharing outside the org. Confirm that linked-account versus payer-account views match your Organizations design from lesson 2.

Prioritization rubric you can reuse

Severity 1: public data stores, world-open admin ports, missing encryption on learner data, no backups on claimed production. Severity 2: single-AZ critical path, untested restore, ASG min 1 for the Monday board. Severity 3: idle managed networking, oversized labs, missing tags, absent budgets. Severity 4: right-sizing with incomplete metrics, commitment purchases, cosmetic Tool completion. Execute Severity 1 the same day. Never trade Severity 1 for Severity 3 savings. If leadership demands the trade, rewrite the reliability promise in the same change ticket.

Connecting every Module 1 lesson in one sitting

Lesson 1’s Regions and AZs become reliability and cost locality choices. Lesson 2’s Organizations and Identity Center become security and chargeback boundaries. Lesson 3’s IAM becomes every service’s authorization plane. Lesson 4’s CLI access becomes how you evidence cleanup. Lessons 5–7’s networking becomes blast radius and endpoint strategy. Lesson 8’s ASG becomes reliability elasticity and Spot discipline. Lesson 9’s storage classes and lifecycle become cost and sustainability levers. Lesson 10’s Multi-AZ databases and disposable caches become reliability with clear systems of record. Lesson 11 asks whether you can defend all of that in one review without mythical prices or mythical certifications.

Anti-pattern: savings that break Monday

Turning off Multi-AZ RDS the night before a launch, lowering ASG min to one, lengthening cache TTL until certificates look wrong, or blocking Flow Logs needed for a security investigation are all “savings” that create larger incidents. The Framework’s value is forcing the trade-off into writing. If leadership wants the savings, they also accept the new reliability statement—or they do not get the savings. TechLearningPro’s brand promise to learners is a reliability artifact as much as a marketing artifact.

Lab cleanup as an exam of character

List every resource with your Project tag across EC2, ASG, ELB, RDS, ElastiCache, DynamoDB, S3, EFS, VPC endpoints, NAT, EIP, and snapshots. Delete in dependency order. Confirm Cost Explorer the next day for residual snapshot storage and schedule deletion. A Module 1 that ends with a clean account is itself a Well-Architected outcome under cost and operational excellence. Leave the budget alert enabled so Module 2 cannot silently accumulate ALB hours.

What Module 2 will add to the review

Load balancers add health-check reliability and hourly cost. Route 53 adds DNS failover patterns and query costs that are usually small but operationally critical. CloudFront later moves transfer cost and security to the edge. Each time you add a service, extend tags, budgets, and the pillar table—do not wait for an annual architecture festival. The progress API review becomes a living document owned by the platform team.

Interview story you should practice aloud

“I reviewed our progress API against Well-Architected. We found a public SSH rule in a leftover lab security group, no RDS restore test, and NAT dominating sandbox spend. We closed the SSH rule the same day, scheduled a restore game day, added S3 and SSM endpoints, and deleted the NAT. Cost Explorer filtered by tag proved the NAT line dropped. I did not buy Savings Plans for a sandbox, and I did not claim a certification as proof the workload was sound.” Practice until it is concrete and timed under two minutes.

Evidence packet checklist

Architecture diagram; security group matrix; launch template version; ASG min/desired/max; database Multi-AZ and backup retention; last restore date; encryption flags; budget identifier; Cost Explorer top services export; tagged resource inventory; backlog with owners; cleanup confirmation. If an item is missing, the review is incomplete. Attach the packet to the homework submission.

Sustainability micro-decision log

Record three decisions that reduced idle capacity or duplicated storage: deregistering lab AMIs, expiring S3 tmp/ prefixes, removing unused interface endpoints, refusing a second Region until a consumer exists, compacting duplicate progress exports. These notes train teams to see utilization as a first-class metric beside latency. Sustainability here is engineering, not a poster.

Framework Tool optional path

If you use the Well-Architected Tool, create one workload named tlp-progress-api-sandbox, answer questions with links to evidence, and generate an improvement plan. Export milestones. Do not chase a perfect score; chase owned actions with dates. If the Tool is unavailable in your account, the one-page pillar table in this lesson is enough for foundations credit. Either path must avoid checkbox fiction.

Finance partnership script

Bring Explorer charts grouped by tag, a list of idle resources deleted this month, and the reliability items you refused to cut. Ask finance which cost centers tags should use. Agree that untagged production is a defect. Agree that Multi-AZ for the progress database is a reliability line item, not a surprise. This conversation prevents surprise invoices and prevents finance from mandating unsafe cuts without product sign-off.

Deep dive: tags that survive contact with reality

A tag dictionary should define allowed Environment values (prod, staging, sandbox, lab), require Owner as an email or team ID, and require Project for any TechLearningPro workload or course lab. Optional tags like Service help Explorer group the progress API versus the media pipeline. Automation should deny creates without required tags when your organization supports it through SCPs or IaC policy. Until then, weekly untagged resource reports are the minimum operational excellence bar. Untagged NAT Gateways are how sandboxes become cautionary tales.

Deep dive: reading a bill like an engineer

When Explorer shows AmazonEC2 high, split instance hours from EBS and data transfer. When it shows EC2-Other, investigate NAT, EIP, and related networking charges rather than blaming application CPU. When it shows S3, split storage from requests from transfer. When it shows Relational Database Service, ask whether Multi-AZ, oversized classes, or forgotten instances dominate. This decomposition is how cost optimization stays architectural instead of becoming a generic “turn things off” panic.

Deep dive: reliability spend naming

Write a sentence in the review: “We spend On-Demand floor capacity of two instances and Multi-AZ RDS to keep Monday board errors inside the product promise.” That sentence protects the spend in finance reviews. Without it, the same spend looks like waste. Lesson 10 and lesson 8 created that spend; lesson 11 names it.

Challenge ADR expanded example

Title: Refuse Multi-AZ disablement for Q4 savings target.

Context: Finance asked for twenty percent reduction in RDS cost. Product still promises Monday reliability for paid cohorts.

Decision: Keep Multi-AZ. Save instead by deleting unused NAT after endpoints, applying S3 lifecycle to exports, rightsizing the pilot after metrics, and shutting non-prod after hours.

Consequences: Savings land in networking and storage waste, not in availability. If savings still short, reopen product SLO before touching Multi-AZ.

Hands-on narrative: two remediations in one afternoon

Remediation A: remove 0.0.0.0/0 SSH from a leftover SG; verify Session Manager still works; record screenshot. Remediation B: create S3 gateway endpoint and SSM interface endpoints; update routes; stop NAT; confirm instances still reach S3 and SSM; watch Explorer over subsequent days. Write both into the backlog as Done with dates. That is a complete foundations cost-and-security win without touching the reliability floor.

Common executive questions and grounded answers

“Are we Well-Architected?” means “Do we review with evidence on a cadence and burn down owned actions?” not “Did someone click green once?” “Can we cut twenty percent?” means “Which severity-3 waste remains?” not “Remove Multi-AZ.” “Do we need more Reserved Instances?” means “Is the steady state measured and owned?” not “Buy commitments because a blog said so.” “Are we certified?” is the wrong question for production readiness—this course will not answer it with a yes.

Module exit criteria checklist

• Pillar table complete with evidence links or paths
• Budget alert active
• Cost Explorer top services identified for the tagged project
• Severity 1 findings remediated or explicitly risk-accepted with expiry
• Lab resources cleaned or scheduled with owner
• No fake unit prices in the write-up
• No certification claims as architecture proof
• Backlog owners assigned for Module 2 carryover items

Extended technical explanation: budgets versus anomaly detection

AWS Budgets answers “are we over a threshold we chose?” Anomaly detection products answer “does spend look unusual versus history?” Foundations requires budgets because thresholds are meaningful even on day one of a sandbox, when history is thin. Anomaly detection becomes more useful after weeks of tagged steady state. You can note anomaly detection as a Module 4/FinOps follow-up without enabling every billing feature on day one. What you must not do is run billable labs with neither budgets nor a human watching Explorer.

Budget types include cost, usage, and reservation/Savings Plans coverage concepts in richer accounts. For this course, a simple cost budget on the sandbox account or a filtered budget where supported is enough. Attach notifications to a mailing list that people read. A budget that emails a departed contractor is operational excellence theater.

Extended technical explanation: Cost Explorer filters that matter for Module 1

Filter by linked account if you use Organizations. Filter by tag key Project with values for each lesson lab. Exclude credits and refunds when studying architecture-driven spend so free-tier noise does not hide NAT hours. Group by Region if someone launched resources in a second Region by mistake—another classic lab failure. Save a report bookmark if the console supports it so the weekly review takes minutes.

When comparing before and after endpoint adoption, use the same date range length and the same filters. People cheat themselves by comparing a quiet weekend to a busy lab weekday and declaring victory.

Extended enterprise scenario: acquisition day

TechLearningPro acquires a smaller LMS. Their AWS account has no tags, a public bastion, single-AZ RDS, and CloudFront in front of a public S3 bucket with open list. A Well-Architected review in week one produces a Severity 1 list longer than a sprint. The correct move is containment: Block Public Access where possible without breaking playback, move bastion to SSM, snapshot and plan Multi-AZ, tag everything before any commitment purchase, and set budgets. Buying Reserved Instances on day two would optimize a mess. Framework thinking prevents that mistake.

Extended enterprise scenario: the green Tool screenshot in a board deck

An architect pastes a Well-Architected Tool high score into a board deck. Two months later a restore fails because nobody ever restored. The board asks how the score was high. Answer: questions were answered without evidence requirements. Process change: every “yes” needs a link to a ticket, screenshot, or repository path. Scores without evidence are banned from board materials. This lesson’s evidence packet is the student version of that professional standard.

Extended best-practice deepener: make reviews boring

The best reviews are boring: same template, same tags, same Explorer filters, same severity rubric, same deletion ethic. Excitement belongs in product features, not in ad-hoc architecture panic. Schedule a ninety-minute review at the end of each module. Carry open actions into the next module’s first week. TechLearningPro’s platform team should treat the progress API workload as a named Well-Architected workload with an owner, not as “whatever the interns launched.”

Extended common mistake: optimizing before inventory

Teams debate Graviton ratios before listing unattached volumes. Inventory first, delete waste second, measure third, right-size fourth, commit fifth. The order is the lesson. Module 1 ends at step three for most learners; that is success.

Extended troubleshooting: Explorer shows cost but console shows no resources

Possible causes: resources in another Region; resources owned by a different account in the org; snapshots and AMIs still storing data; delayed billing data; Marketplace charges; support plan charges. Search all Regions for the Project tag. Check Trusted Advisor or Config if available for orphans. Do not launch more resources to “test” while confused—set a temporary lower budget threshold instead.

Extended interview set for architects

Explain how you would run a Well-Architected review for a three-tier learning platform in one day. Explain which Cost Explorer view you open first and why. Explain a time you refused a cost cut that endangered reliability. Explain how tags interact with Organizations SCPs. Explain why certification study is not the same as workload review evidence. Strong answers are specific, ordered, and humble about what Module 5 still owns.

Final Module 1 synthesis for TechLearningPro

The learner opens the board on Monday. Route 53 and a load balancer (soon) direct them to healthy progress API instances in private subnets. Security groups allow only the edge. Instances come from a pinned launch template and AMI. Progress state reads through a cache into a Multi-AZ relational store, with objects in encrypted S3. Operators arrive through Session Manager. Budgets watch the account. Cost Explorer names leftover NAT if someone forgot Module 1 hygiene. Well-Architected questions keep the story honest when someone wants to simplify away the floor. That is foundations: not every AWS service, but enough architecture to deserve the next module.

Operator cadence after Module 1

Weekly: Cost Explorer by tag for sandbox and staging; delete orphans; verify budget notifications still route to living humans. Monthly: pillar table refresh for the progress API; restore drill in sandbox if schema changed; confirm encryption defaults still enforce new volumes and buckets. Quarterly: deeper Well-Architected Tool session or external review; revisit commitment purchases only with measured steady state; re-read the Framework whitepaper for pillar updates. This cadence is operational excellence made calendar-shaped.

Student self-assessment before submitting lesson 11

Can you name all pillars without looking? Can you point to evidence for security groups, ASG floors, and backups? Can you show a budget? Can you show Explorer’s top service for your tags? Did you delete lab waste? Did you avoid writing fake prices? Did you avoid claiming certification credit? If any answer is no, finish before calling Module 1 complete. The next module assumes this discipline; load balancers will not save an account that still has public SSH and no budgets.

Closing note on humility and scope

AWS has more services than this module taught. Foundations success is not encyclopedic coverage. It is the ability to place identity, network, compute, storage, data, and review practices under one learner-facing reliability story—and to keep the bill attributable. When you do not know a service behavior, you open current documentation rather than inventing APIs. That habit matters more than any single checkbox in the Tool.

One more scenario: the weekend student spike

A free weekend campaign doubles learner sign-ups. Cost Explorer shows DynamoDB on-demand and data transfer rising, which is expected, and also a forgotten large RDS instance from a load test still running in a second Region. The Well-Architected cost response is to kill the orphan immediately, keep Multi-AZ on the real database, and raise the budget threshold temporarily with product approval rather than silently disabling alerts. Reliability and cost remain separate levers even when traffic is good news.

Reminder on documentation currency

Service capabilities, console labels, and price cards change. When your review cites a control, verify it against the current AWS documentation for your Region. This course’s hard rule—no invented APIs—applies to Well-Architected answers as much as to CLI samples. If a pillar question references a service you have not deployed, answer “not applicable” with a reason, rather than fabricating a green control.

Carry-forward backlog seeds for Module 2

Add ALB and target group health evidence to the reliability pillar; tag new edge resources on create; extend budgets before the first load balancer hour; revisit SG matrix rows for listener and health-check ports; and schedule an Explorer check three days after the first ALB lab to catch leftovers early.

Lesson Summary

Well-Architected questioning turns Module 1 from a pile of services into a defendable progress platform. Budgets and Cost Explorer make waste visible. Tags make waste attributable. Reliability and security set floors that cost work may not dig under. FinOps later deepens the craft; Module 2 puts an edge in front of the ASG you already know how to review.

Elastic Load Balancing and Route 53 begins the application platform module—health checks, DNS, and traffic that make Monday’s board reachable from the world without abandoning least privilege.

Further Reading

• AWS Well-Architected Framework
• AWS Well-Architected Tool
• AWS Budgets
• AWS Cost Explorer
• User-defined cost allocation tags
• AWS Pricing Calculator for estimates—verify live; do not hardcode rates into runbooks