Most pages about the AWS Well-Architected Framework pillars can name all six. The harder problem is deciding which pillar should lead when one workload has uptime pressure, security requirements, latency targets, budget constraints, and a team that still needs to ship.
The AWS Well-Architected Framework pillars are six workload decision lenses, not six glossary terms. Security and Operational Excellence set the floor. Reliability, Performance Efficiency, Cost Optimization, and Sustainability shift more by workload context. That is the model I use when I help teams prepare for a Well-Architected Review, and it lines up with the AWS pillar overview and trade-off guidance.
What Are the AWS Well-Architected Framework Pillars?
The current framework has six pillars, not five: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. That distinction matters in a real review because Sustainability is no longer a side note. It changes how you think about utilization, idle capacity, data retention, and the efficiency of every workload component.
What matters more than the names is the question behind each pillar. AWS built the framework to evaluate a workload, so the useful reading is not "what are the six labels?" but "what decision is each pillar forcing me to make?"
The short version: all six pillars at a glance
| Pillar | AWS focus | Design principles | Best-practice groups | Question it should drive |
|---|---|---|---|---|
| Operational Excellence | Build and run workloads while improving business outcomes | 8 | 4 | Can this team change and operate the workload safely? |
| Security | Protect data, systems, and assets | 7 | 7 | Which control model reduces risk without blocking delivery? |
| Reliability | Keep the workload performing correctly and consistently | 5 | 4 | Which failures must this workload survive or recover from? |
| Performance Efficiency | Use cloud resources efficiently as demand changes | 5 | 5 | Does the technical shape match the latency and throughput target? |
| Cost Optimization | Deliver business value at the lowest sensible cost | 5 | 5 | Who owns spend, and does it track to business value? |
| Sustainability | Reduce energy use and total resource demand | 6 | 6 | How do we reduce resource intensity without harming the workload? |
The counts come from the current AWS pages for Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. The question column is my synthesis.
Framework vs Tool vs Review
The framework is the guidance model. The AWS Well-Architected Tool is the service that applies that model to one workload. The AWS Well-Architected Review is the conversation and improvement workflow built on top of both.
AWS also notes that the Well-Architected Tool has no additional charge. If you want the time and partner-side economics, use this AWS Well-Architected Review cost guide. If you want the operational flow, read how the review process actually works.
How to Use the Pillars as a Workload Decision Model
Knowing the six names still leaves the harder question unanswered: which pillar should lead for this workload, right now? AWS gives the key clue in its trade-off guidance. Trade-offs depend on business context, but Security and Operational Excellence are generally not traded off against the other pillars.
That tells you the six pillars are not six equal checkboxes. Some define baseline operating discipline. Others move depending on what the workload exists to protect.
The two baseline guardrails
I treat Security and Operational Excellence as the floor, not the polish. Security covers identity, traceability, data protection, and incident response. Operational Excellence covers safe change, observability, and learning loops.
If a team cannot operate the workload safely or cannot explain how access and risk are controlled, it is too early to argue about clever cost or performance wins.
Where trade-offs are acceptable
The rest of the model is more flexible. AWS gives a simple example in its trade-off guidance: a dev or test environment may accept lower reliability to reduce cost and resource usage, while a mission-critical production workload may spend more to improve resilience.
You see the same pattern elsewhere. A latency-sensitive customer application may spend more for better Performance Efficiency. A batch analytics job may lean harder into Cost Optimization and Sustainability. The goal is explicit trade-offs, not pillar perfection.
Which pillars lead by workload type
AWS does not publish a universal prioritization matrix, so this ordering is editorial synthesis, not an AWS scoring system:
| Workload type | Lead pillars | Why |
|---|---|---|
| Customer-facing production workload | Security, Operational Excellence, Reliability | Customer trust and outage cost dominate. |
| Growth-stage SaaS under uneven traffic | Operational Excellence, Reliability, Performance Efficiency, Cost Optimization | Fast change and bursty demand show up together. |
| Internal platform or dev/test environment | Security, Operational Excellence, Cost Optimization, Sustainability | Baseline control still matters, but some reliability trade-offs are acceptable. |
| AI or ML workload | Core six pillars plus a lens | Domain-specific risks go beyond the base framework. |
The diagram below uses a production SaaS workload as the example. It is not a reference architecture; it is a decision canvas that shows where each pillar changes the design: edge security, operational ownership, failover, capacity, caching, right-sizing, spend ownership, recovery, and waste reduction.
Excalidraw diagram loading.
Operational Excellence: Can We Change and Run This Workload Safely?
AWS gives Operational Excellence eight design principles and four practice areas. I usually describe it as the safe-change pillar.
What this pillar decides
Operational Excellence shapes decisions about team ownership, observability depth, deployment safety, rollback patterns, and whether operations are defined as code or left to memory. For the deeper runbook, use my AWS operational best practices guide.
Strong vs weak operational signals
Strong signals are small reversible releases, useful dashboards, owned runbooks, and regular review loops after failed changes.
Weak signals are late-night manual changes, rollback that only works in theory, thin monitoring, and tribal knowledge sitting inside two engineers' heads.
Security: Are We Reducing Risk Without Slowing Delivery?
The Security pillar has seven design principles and seven best-practice groups. Security is a control-architecture problem, not an IAM-only problem.
What this pillar decides
This pillar decides how identity is centralized, where least privilege is enforced, how events are logged and investigated, which controls live in delivery pipelines, and how data is protected. For the full follow-up, use the AWS security review checklist or the AWS security misconfigurations post.
Strong vs weak security signals
Strong signals include centralized identities, short-lived access, event traceability, layered controls, and a response path that has actually been exercised.
Weak signals are broad standing access, manual exceptions nobody revisits, thin logging, and incident ownership invented under pressure.
Reliability: Can the Workload Fail Without Failing the Business?
AWS gives Reliability five design principles across Foundations, Workload Architecture, Change Management, and Failure Management. Reliability is broader than backups and Multi-AZ.
What this pillar decides
This pillar decides which failure modes are unacceptable, whether recovery is tested or assumed, how quotas and saturation are managed, and whether change risk is treated systematically.
AWS refreshed all pillars in the Tool on April 9, 2025 and announced 78 new best practices, including 14 updated Reliability best practices.
Strong vs weak reliability signals
Strong signals include tested recovery paths, known dependency limits, and explicit scaling assumptions.
Weak signals sound like this: "it should fail over," "we have backups somewhere," or "we will scale if traffic spikes."
Performance Efficiency: Are We Choosing the Right Technical Shape?
The Performance Efficiency pillar has five design principles and five best-practice groups around architecture selection, compute, data, networking, and culture.
This pillar asks whether the workload's technical shape matches the demand it actually serves. That is why I usually send teams to Operational Excellence vs Performance Efficiency when they start mixing the two.
What this pillar decides
Performance Efficiency decides the compute model, the data-store fit, the caching approach, the network path, and whether global distribution or edge delivery is justified.
Strong vs weak performance signals
Strong signals include service choices that match access patterns, intentional caching, benchmarking before large spend, and teams willing to experiment.
Weak signals are oversized resources by habit, "temporary" bottlenecks that become permanent, and architecture picked for familiarity instead of workload fit.
Cost Optimization: Are We Spending in Line With Business Value?
AWS starts the Cost Optimization pillar with Cloud Financial Management. That is a useful reminder that this pillar is not "make it cheaper."
Cost Optimization is about business value at the lowest sensible price point.
What this pillar decides
This pillar decides whether unit economics are visible, whether non-production usage is controlled, whether managed services remove more cost than they add, and whether optimization is continuous instead of reactive. If this is your main pressure, go deeper with AWS cost optimization best practices.
Strong vs weak cost signals
Strong signals include clear workload owners, attributable spend, deliberate non-prod controls, and regular review of trade-offs.
Weak signals are one giant bill, no obvious owner, permanent overprovisioning, and optimization work that only starts when finance escalates.
Sustainability: Are We Reducing Waste Along With Spend?
Sustainability is a full AWS Well-Architected pillar, not an appendix. AWS gives it six design principles and six best-practice groups.
In workload terms, it is about reducing resource intensity per useful outcome.
What this pillar decides
This pillar decides whether utilization is visible, whether resources align to demand, whether more efficient hardware or managed services should replace old patterns, and whether product choices increase downstream resource use.
That is why Sustainability often reinforces good Cost Optimization and Performance Efficiency decisions.
Strong vs weak sustainability signals
Strong signals include visible utilization, regular right-sizing, and teams that can explain resource intensity per user, transaction, or job.
Weak signals are idle resources accepted as normal, permanent overprovisioning, and no language at all for resource intensity.
How the Pillars Show Up in a Well-Architected Review
This is where the framework stops being educational and starts becoming operational. AWS applies the base framework lens to every workload in the Tool, then lets you add business context through profiles, milestones, priorities, and additional lenses.
A review is really about defining one workload, naming the trade-offs that exist today, and turning those choices into a prioritized improvement queue.
From pillar understanding to review preparation
The move from reading to review starts with scope. One workload needs a clear owner, business goal, environment, and region set. If you want the exact question set, use the complete checklist for each pillar. If you need the facilitation flow, use the review process guide.
AWS exposes fields like PillarPriorities, RiskCounts, and PrioritizedRiskCounts for a reason. Pillars become prioritization language, not just educational content.
When lenses change the conversation
The six pillars are the baseline. As of April 28, 2026, AWS lists 16 official lenses in the Lens Catalog, including SaaS, Serverless Applications, Data Analytics, Machine Learning, and Generative AI.
Start with the six pillars, then layer in domain-specific guidance when the workload has risks the base framework does not fully express.
When to go deeper or get outside help
If your team is still at the "what are the pillars?" stage, more reading may be enough. If the workload already carries security, uptime, compliance, or cost risk, the next useful step is usually understanding what an AWS Well-Architected Review actually is, then deciding whether a structured external review makes sense.
What To Do Next With the Six Pillars
Do not try to "score AWS" in the abstract. Pick one named workload. That is how the AWS Well-Architected Framework pillars become useful.
If you only need a self-service starting point, start with the complete checklist for each pillar and the review process guide. If the real issue is funding, scope, or unresolved trade-offs, an external review usually speeds things up.
Next step
Need an External Well-Architected Review?
I review one workload against all six pillars, document the risky trade-offs, and leave you with a prioritized remediation roadmap your team can actually use.
Here is the short version I would act on next:
- Name one production or near-production workload, not an entire AWS estate.
- Decide which two pillars create the biggest current business risk for that workload.
- Use the checklist for the exact questions and the process guide for the facilitation runbook.
- Pull in an additional lens when the workload is domain-specific enough that the base six pillars are too generic.
Your immediate next step: take one workload and write one sentence for each pillar describing the current risk.
If your team keeps blurring boundaries between pillars, read Operational Excellence vs Performance Efficiency next. If the tension is mostly economic, go deeper with AWS cost optimization best practices. Both are better follow-ups than memorizing another six-bullet summary.