Evaluating Solutions with the Six AWS Well-Architected Pillars

Welcome back. In the previous lesson, you extracted an ordering workload’s hard constraints—survive an Availability Zone failure, restrict database access, encrypt order data, meet a peak-load latency target, and stay within a budget—before choosing services. Now you will use the six AWS Well-Architected Framework pillars to evaluate a proposed design against those constraints. The aim is not to give an architecture a vague “good” or “bad” label; it is to identify risks, evidence gaps, and improvements you can defend in an SAA-C03 scenario or a design review.

Six pillars, one workload

A workload is the set of components that delivers a business function. Reviewing only its EC2 instances, for example, could miss a database or operating procedure that determines whether customers can actually place orders. The Well-Architected Framework provides six complementary ways to examine the whole workload.

You can turn those definitions into six review questions:

Some practices support several pillars, but the questions remain different. Right-sizing an instance may lower its bill (cost) and reduce unused capacity (sustainability); it is a performance improvement only if the resulting configuration still meets the workload’s performance target. Likewise, an alarm helps operators notice trouble, but an alarm alone does not make an application recover from failure.

A review is a continuing evaluation, not a certification that a design is permanently safe. This short AWS Events presentation shows how the Framework’s questions become findings and an improvement plan.

Evaluate a proposed ordering design

Return to the ordering workload from the previous lesson. Suppose its proposed architecture has an internet-facing Application Load Balancer and an Auto Scaling group with application instances in two Availability Zones. It uses a single-AZ RDS database in private subnets. The database is not publicly accessible, but its security group allows connections on the database port from all IPv4 addresses. Storage encryption is enabled; whether application-to-database connections require TLS is undocumented.

The team makes production changes manually, has no documented rollback or database-restore test, and has not configured alarms for failed order requests. It has neither a peak-load test nor a monthly cost estimate. Its minimum application capacity remains running during quiet periods.

The design has a promising start: distributing the application instances across two AZs addresses part of the availability requirement. A six-pillar review asks what that fact does not establish.

Operational excellence: How will the team detect that orders are failing, determine what changed, and restore service after a bad deployment? Manual changes, absent failure alarms, and no rollback procedure create operational risk. A practical improvement is to make deployments repeatable, monitor a customer-relevant signal such as failed order requests, and document and test rollback. This pillar concerns the ability to run and improve the workload, not merely whether its components are redundant.

Security: “Database is not publicly accessible” does not mean “only the application tier may connect.” Its broadly permissive security group violates the stated source restriction for any network that can reach it. Restrict inbound database connections to the application tier’s security group, then verify the actual paths. Storage encryption addresses data at rest; confirm that connections handling order data use the required encryption in transit. An undocumented control is a question to investigate, not proof that the control exists.

Reliability: The order-placement function depends on the database. A single-AZ database remains a possible failure point even though the application tier spans two AZs. If the requirement is to continue accepting orders through one AZ failure, evaluate a suitable Multi-AZ database deployment and test application behavior during failover. Multi-AZ does not imply zero interruption; the permitted interruption and data-loss tolerance must be established rather than assumed. A restore test answers a different reliability question: whether the workload can recover from an event requiring restoration.

The distinction is useful under exam pressure: an alarm identifies a failure; a resilient design and tested recovery procedure determine what happens next.

Check outcomes, spending, and resource use

The remaining pillars examine whether the proposed workload delivers its required outcome efficiently.

Performance efficiency: The requirement was a 95th-percentile API response time below 300 milliseconds at 2,000 concurrent users. Two AZs and Auto Scaling do not demonstrate that result. The review needs peak-load measurements of end-to-end latency and enough component-level evidence to locate a bottleneck—application capacity, database performance, or a dependency. Only then can you judge whether the selected resources and scaling behavior meet the target efficiently.

Cost optimization: With no monthly estimate, the design has not demonstrated that it fits the USD 1,800 cap. Estimate the complete workload under stated usage assumptions, including continuously running capacity, database deployment, storage, and data transfer. Then examine measured usage for right-sizing opportunities. A cheaper single-AZ database is not a valid saving if it breaks the hard availability requirement; cost optimization means reducing expense among acceptable designs.

Sustainability: Continuously provisioned capacity during quiet periods raises a related but distinct question: how much resource use is needed to deliver the required service? Consider scaling with demand and removing unused resources or unneeded stored data. Preserve sufficient capacity and AZ coverage for the stated failure requirement, and retain data for as long as the workload requires. “Use fewer resources” is not a reason to weaken a hard reliability or retention constraint.

These findings show why a pillar review is more useful than labeling a service “well architected.” The same proposal can be sound in one respect and unproven or deficient in another.

Convert findings into a defensible decision

An effective review separates confirmed violations from missing evidence. Here, broad database ingress conflicts with the access rule, and the single-AZ database conflicts with the stated AZ-failure requirement for order placement. By contrast, missing load-test results do not prove the latency target is missed; they mean the claim is unverified. The absent estimate leaves budget compliance unverified too.

A sensible initial improvement plan would address the confirmed hard-constraint failures first, then verify encryption in transit, peak-load performance, recovery behavior, and projected cost. Document any trade-off and the requirement that justifies it. In particular, do not approve a cost reduction that removes necessary failure tolerance.

The AWS Well-Architected Tool can record review answers and surface issues by pillar. The example dashboard below shows 15 high-risk and 11 medium-risk issues for one reviewed workload, including seven high-risk reliability issues. Those counts help direct investigation; they do not tell you which customer function is affected, whether a particular risk is acceptable, or what the architecture will do in a real failure.

For your later hands-on architectures, the useful habit is to record a short review at a design milestone, make an improvement, and revisit the review when the workload changes. For an SAA-C03 question, use the same reasoning more quickly: identify the requirement an option satisfies, the pillar risk it introduces, and whether that risk violates a hard constraint.

Key takeaways

The six pillars examine how a workload is run, protected, kept reliable, made performant, paid for, and made resource-efficient. Apply them to the end-to-end function, distinguish a demonstrated problem from an unanswered question, and prioritize hard requirements before optimization. A Well-Architected review is valuable because it turns those judgments into an improvement cycle—not because it produces a score.

Next, you will apply this requirements-first reasoning to the choice of AWS Regions and Availability Zones, where latency, compliance, service availability, and resilience place different limits on a design.