The Well-Architected Framework

The six pillars, their design principles, the Well-Architected Tool, and a multi-AZ example.

What is it?

The AWS Well-Architected Framework is a set of best practices for evaluating and improving cloud architectures. It has six pillars:

  • Operational Excellence: run and monitor systems, and keep improving. Principles: perform operations as code, make frequent small reversible changes, learn from failures.
  • Security: protect data and systems. Principles: strong identity foundation, traceability, security at all layers, automate security, protect data in transit and at rest, prepare for events.
  • Reliability: recover from failure and meet demand. Principles: automatically recover, test recovery procedures, scale horizontally, stop guessing capacity, manage change through automation.
  • Performance Efficiency: use resources efficiently as needs evolve. Principles: democratise advanced technologies, go global in minutes, use serverless, experiment more, consider mechanical sympathy.
  • Cost Optimization: avoid unnecessary spend. Principles: implement cloud financial management, adopt a consumption model, measure overall efficiency, stop spending on undifferentiated heavy lifting, analyse and attribute expenditure.
  • Sustainability: minimise environmental impact. Principles: understand your impact, set sustainability goals, maximise utilisation, adopt more efficient hardware and software, use managed services, reduce downstream impact.

The AWS Well-Architected Tool (in the console) guides a review of a workload against the pillars and tracks improvement items. Pillars involve trade-offs - you balance them, you do not maximise each independently.

Explain like I'm 10

Designing a building: you want it safe (security), reliable in storms (reliability), pleasant to run day to day (operational excellence), quick to move around in (performance), affordable (cost), and kind to the planet (sustainability). A glass tower might delight on looks and performance but cost more to heat - the pillars are the checklist that makes you notice the trade-off.

Examples

Making a web app multi-AZ (reliability + performance)

Resources:
  WebASG:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MinSize: "2"
      MaxSize: "6"
      DesiredCapacity: "2"
      HealthCheckType: ELB
      HealthCheckGracePeriod: 120
      VPCZoneIdentifier:
        - !Ref PrivateSubnetA   # AZ a
        - !Ref PrivateSubnetB   # AZ b
      LaunchTemplate:
        LaunchTemplateId: !Ref WebLaunchTemplate
        Version: !GetAtt WebLaunchTemplate.LatestVersionNumber
      TargetGroupARNs:
        - !Ref WebTargetGroup
  Database:
    Type: AWS::RDS::DBInstance
    Properties:
      Engine: postgres
      DBInstanceClass: db.t4g.medium
      AllocatedStorage: "50"
      MultiAZ: true
      StorageEncrypted: true
      MasterUsername: appadmin
      ManageMasterUserPassword: true

Instances in two AZs behind a load balancer plus a Multi-AZ encrypted database means losing a data center does not take the app down. Required companion resources (VPC, subnets, launch template) are omitted for brevity.

Review checklist by pillar

Pillar                  Quick review question
----------------------  -----------------------------------------------------
Operational Excellence  Is everything deployed from code and observable?
Security                Least privilege, encryption, logging, MFA everywhere?
Reliability             What happens if an AZ fails? Have we tested restore?
Performance Efficiency  Are we using the right instance/storage/DB type?
Cost Optimization       Are resources right-sized and tagged? Commitments used?
Sustainability          Are we maximising utilisation and removing idle resources?

How it works

A Well-Architected Review asks a set of questions per pillar about a specific workload, identifies high and medium risk items, and produces an improvement plan. It is a conversation and an ongoing practice rather than a one-time pass/fail audit. The AWS Well-Architected Tool stores the answers, tracks milestones, and can generate a report. 'Lenses' extend the framework for specific industries and technologies, such as serverless or SaaS.

            +--------- Operational Excellence ---------+
            |  Security | Reliability | Performance    |
            |  Cost Optimization | Sustainability      |
            +------------------------------------------+
   Review -> find risks -> improve -> measure -> repeat

Why does it exist?

Teams repeat the same architectural mistakes: single points of failure, wide permissions, forgotten costs. The framework distils lessons from many customer reviews so you can catch known problems before they become incidents.

When to use it

Review before launch, after major changes, and on a schedule for critical workloads. Use it as a design checklist and as shared language between engineers, managers and auditors.

When not to use it

It will not make decisions for you or guarantee compliance. Do not apply every best practice at maximum to a small prototype - weigh cost and effort against business risk.

Common mistakes

  • Forgetting that there are six pillars - Sustainability was added after the original five.

  • Optimising one pillar (e.g. cost) while silently sacrificing another (reliability).

  • Treating the review as paperwork instead of acting on the findings.

  • Reviewing once and never again.

  • Confusing the Well-Architected Framework with the Cloud Adoption Framework.

Practice exercises

  1. Easy:

    Name all six pillars and give one design principle for each.

  2. Medium:

    Take a simple architecture (single EC2 + RDS) and list risks by pillar.

  3. Medium:

    Show how adding multi-AZ affects reliability, cost and operational complexity.

  4. Hard:

    Choose between two designs (serverless vs EC2 fleet) using all six pillars and justify a recommendation.

Interview questions

What are the six pillars?

Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization and Sustainability.

What does the Reliability pillar emphasise?

Recovering automatically from failures, testing recovery, scaling horizontally, and managing change.

What is the Well-Architected Tool?

A console service that helps you review workloads against the pillars and track improvements.

Exam-style: A company deploys across multiple AZs. Which pillar does this primarily support?

Reliability.

Exam-style: Which pillar covers using managed services and maximising utilisation to reduce environmental impact?

Sustainability.