The Well-Architected pillars, and landing zones
What it is
Well-Architected frameworks are structured review checklists published by the cloud providers. AWS has six pillars, Azure five, Google an equivalent set:
Operational excellence can you run and change it safely?
Security is it defensible, and can you prove it?
Reliability does it meet its availability target?
Performance efficiency is it using the right resources?
Cost optimisation are you paying for what you use?
Sustainability (AWS) what is the carbon cost?
A landing zone is the account and organisation structure the workloads sit in: a multi-account layout with guardrails, centralised logging and identity, so that the blast radius of a mistake is an account rather than a company.
What this is confused with: the pillars as equally binding. They are all real and they do not bind equally. In practice two of them have a recurring forcing function and the rest do not, and knowing which one binds in your organisation is the useful insight rather than being able to recite six.
Also confused: a landing zone and a naming convention. Tags in one account are a labelling scheme. An account is a hard boundary for IAM, service quotas, billing and blast radius, and no amount of tagging reproduces that.
The problem it solves
The pillars solve a specific and narrow problem: they are a prompt that makes you consider the dimension you were going to skip.
An architecture review without a framework asks whatever the
reviewers happen to care about, which is usually the thing
that burned them last.
With the pillars, someone asks "what is the recovery story"
even in a room full of people who are excited about the
performance work.
That is the whole value. It is real, and it is smaller than
the marketing suggests.
And the honest observation about which ones bind:
A pillar binds when it has a NAMED OWNER and a RECURRING
FORCING FUNCTION.
SECURITY binds. There is an audit, a compliance
questionnaire, and a person whose job it is.
COST binds. A bill arrives monthly and someone
senior reads it.
RELIABILITY binds ONLY to the extent an SLO exists with a
policy attached. Without that, it is an
opinion.
PERFORMANCE binds when a user complains, which is
reactive by construction.
OPERATIONAL
EXCELLENCE binds almost nowhere, because nobody receives
a bill for toil.
SUSTAINABILITY binds where a corporate commitment with
reporting exists, and nowhere else.
So: if you want reliability to bind, the answer is not a
better review, it is an SLO with an error budget policy.
The landing-zone problem is different and more concrete.
One AWS account, everything in it.
- a misconfigured IAM policy in dev can reach prod data
- a service quota exhausted by a load test in staging
throttles production, because quotas are PER ACCOUNT
- a compromised CI credential has the blast radius of the
whole company
- cost attribution depends entirely on tagging discipline,
which is a human process and therefore incomplete
- "who can delete the production database" is answered by
reading IAM policies rather than by a boundary
Service quota exhaustion is the failure people do not anticipate, because it presents as a production outage caused by a staging activity with no code path between them.
Mechanics
Using the pillars honestly
The valuable part of a Well-Architected review is not the score, it is the trade-offs the pillars force into the open.
The pairs that actually conflict, and the conversation each
one produces:
COST vs RELIABILITY
Multi-AZ doubles the database bill. Multi-region more than
doubles everything. The question the pillars force: what is
the availability target, and what is an hour of downtime
worth? Without those two numbers the conversation is
aesthetic.
SECURITY vs OPERATIONAL EXCELLENCE
Least privilege means an engineer debugging a production
incident cannot read the thing they need. Break-glass access
with paging and audit is the resolution, and it has to be
built before the incident.
PERFORMANCE vs COST
Provisioned capacity for p99 means idle capacity at p50.
The question: is the latency requirement a product decision
with evidence, or a preference?
OPERATIONAL EXCELLENCE vs DELIVERY SPEED
Every guardrail is friction. The honest version is to
measure the friction: if a guardrail adds 20 minutes to
every deploy and catches one issue a quarter, price it.
The critique worth being able to state:
1. The review is frequently a SALES MOTION. A provider-run
Well-Architected review recommends provider services, and
the framework has no vocabulary for "this should not be in
the cloud" or "this should be a smaller managed service
from someone else".
2. It is a CHECKLIST, and checklists find the things on the
list. The failure modes that matter are usually specific
to your system and are not on anyone's list.
3. It produces FINDINGS WITHOUT PRIORITIES. A review that
yields 47 findings, unranked, gets one addressed.
The productive use: run it as a structured prompt, rank the
findings by expected cost, and take the top three. Discard the
score.
The landing zone: accounts as the boundary
The structure that has converged across organisations:
MANAGEMENT / ORG ROOT
no workloads. Organisation policies, account creation,
consolidated billing. Locked down hard.
SECURITY
log-archive immutable, write-only from everywhere,
no delete permission granted to anyone
outside break-glass
audit / security read-only access into every account for
the security team's tooling
SHARED SERVICES
networking transit gateway / hub VPC, DNS
ci-cd build, artifact registry
identity if self-hosted
WORKLOADS, one account per (workload, environment):
payments-prod, payments-staging, payments-dev
search-prod, search-staging, ...
SANDBOX
per-engineer or per-team, with a hard spend limit and
automatic cleanup. This is what stops people doing
experiments in dev.
What an account boundary gives you that a tag cannot:
IAM a principal in dev cannot assume a role in
prod unless you explicitly allow it. The
default is deny, across a boundary.
SERVICE QUOTAS per account. A load test cannot exhaust
production's Lambda concurrency or its EC2
limits.
BILLING cost attribution is structural rather than
dependent on tagging discipline.
BLAST RADIUS a compromised credential is bounded. A
misconfigured automation deletes one account's
resources.
DELETION you can delete an entire environment by
closing an account, which is the only reliable
way to clean up.
COMPLIANCE "production data never leaves these three
accounts" is a checkable statement.
Guardrails, which are what makes the structure enforceable:
SERVICE CONTROL POLICIES (AWS) / Azure Policy / GCP Org
Policy: a deny that no account admin can override.
The universally useful ones:
deny disabling CloudTrail / audit logging
deny deleting or modifying the log-archive bucket
deny use of the account root user for anything
deny regions outside your approved list (this is also a
residency control and a cost control: it stops a resource
being created in a region nobody monitors)
deny leaving the organisation
deny disabling GuardDuty / Defender / Security Command
Center
The property that matters: these are DENY policies evaluated
above the account's own IAM, so a compromised account
administrator cannot turn off the audit trail. That is the
difference between a guardrail and a convention.
How many accounts
The tension is real:
TOO FEW blast radius, quota contention, cost attribution
by tagging, and IAM policies doing the work an
account boundary should do
TOO MANY cross-account networking complexity, a VPC per
account and the IP space to plan, "which account
is this in", and a per-account overhead of
baseline services
The heuristic that works: an account boundary exists where you
want a DIFFERENT ACCESS POLICY or a DIFFERENT BLAST RADIUS.
prod vs non-prod always. Different access policy.
per workload when workloads have different
owners or different compliance
scopes.
per team when teams are autonomous enough
that shared quotas would cause
contention.
per region rarely. Regions are already a
boundary within an account.
A 60-engineer company typically lands somewhere around 15 to
30 accounts. A 5-engineer company with 4 (management,
security, prod, dev) is well served and adding more is
overhead.
Automate account creation from day one, because a landing zone assembled by hand drifts within months and the drift is invisible: two accounts created six months apart differ in ways nobody documented.
A worked example: one account, then twenty-two
A 70-engineer company, one AWS account, four years of growth, and two incidents in one quarter that shared a cause.
Incident 1: a staging load test took down production.
A load test in staging spun up EC2 instances to generate
traffic. It hit the account's vCPU service quota.
Production's autoscaler then could not scale up during a
traffic peak, because the quota was exhausted, and it had no
signal explaining why: the API returned a limit error that the
autoscaler logged and retried.
Impact: 40 minutes of degraded service.
Code path between staging and production: none.
Shared resource: an account-level quota nobody had thought of
as a shared resource.
Incident 2: a CI credential leaked in a public repository.
A contractor pushed a repository containing an access key with
broad permissions, because CI ran in the same account as
everything and had been granted what it needed over four years
of incremental additions.
Detected by a secret scanner in 90 minutes. Rotated in 20.
The exposure window included read access to the production
database's snapshots.
No evidence of use. The incident report's finding was that the
blast radius of ANY credential in that account was the entire
company.
Both incidents are the same finding: the account was the blast radius and it contained everything.
The landing zone, built over one quarter:
22 accounts:
1 management (billing, org policies, account vending)
2 security (log-archive, audit)
3 shared services (network, ci-cd, artifact registry)
15 workload accounts: 5 workloads x (prod, staging, dev)
1 sandbox (per-engineer roles, $200/month hard limit,
resources auto-deleted after 14 days)
SCPs applied at the organisation level:
deny CloudTrail disable/delete
deny log-archive bucket modification
deny root user actions
deny regions outside ca-central-1, us-east-1, eu-west-1
deny leaving the organisation
Account vending automated with Control Tower plus a Terraform
module, so every new account is identical: baseline IAM roles,
logging, GuardDuty, cost allocation, VPC with the assigned
CIDR.
The migration order, which mattered:
1. Create the structure and move NOTHING. Two weeks.
2. Move dev workloads first. Cheap to get wrong.
3. Move staging. This is where the cross-account networking
and the CI permissions got debugged.
4. Move production last, workload by workload, with the old
resources left in place for two weeks each.
Total: one quarter, roughly 1.5 engineers.
The thing that took longest was not the infrastructure, it
was the IAM: four years of accumulated permissions in one
account had no owner and no documentation, and determining
what CI actually needed took three weeks of running it with
CloudTrail analysis in a permissive mode.
"Determining what CI actually needed took three weeks" is the honest cost of a multi-account migration, and it is entirely a consequence of having had no boundary for four years.
Measured after:
before after
accounts 1 22
production quota headroom shared dedicated per
account
blast radius of a leaked CI
credential everything the ci-cd account
(build, artifacts,
and an assume-role
into deploy targets
scoped per env)
cost attribution tagging structural, by
(73% account (100%)
coverage)
time to delete an environment unknown, close the account
manual
audit finding: "prod data
isolation" unprovable three named accounts
monthly cost $214k $221k (+3%: NAT
gateways and
transit gateway
per account)
The 3 percent cost increase is the honest price of the boundary, and it was accepted because a single incident of either kind cost more.
The Well-Architected review, run six months later, and what it was worth:
A provider-led review produced 47 findings across six pillars.
Triaged by the platform team into expected annual cost:
3 findings worth >$50k/yr or a material risk reduction
9 findings worth $5k-50k
35 findings worth less than the engineering time to fix
The three that mattered:
1. RDS instances still on gp2 storage: moving to gp3 saved
~$61k/yr with no performance loss (this is a
right-sizing finding, and the framework's value here was
simply that someone looked)
2. No automated key rotation on three KMS keys used for
customer data, which was a real audit exposure
3. Cross-AZ traffic between two chatty services costing
~$28k/yr, fixable with topology-aware routing
Everything else was noted and not scheduled.
The team's recorded assessment: the review was worth running
once and is not worth running annually, because the three
findings that mattered came from someone with fresh eyes
looking at the bill and the IAM configuration, and that
exercise can be run internally at a fraction of the cost.
"Worth running once, not worth running annually" is a defensible position and worth being able to state, because the alternative view (it is a compliance ritual) and the vendor view (it is a continuous practice) are both easier to hold and less accurate.
And the reliability pillar's finding, which was the interesting one:
The review flagged that four of five workloads had no defined
RTO or RPO.
The team's response was NOT to write RTOs into a document. It
was to observe that the reliability pillar was not binding
because there was no forcing function, and to create one: an
SLO per workload with an error budget policy signed by the
product owner (see the error budget policy page).
Six months later, three of the five had a measured RTO,
because the error budget policy gave someone a reason to care.
The pillar identified the gap. The forcing function closed it.
The framework could not have supplied the second part.
Production evidence
The AWS Well-Architected Framework defines six pillars and ships a tool for structured reviews; Microsoft's Azure Well-Architected Framework defines five, and Google's Cloud Architecture Framework covers equivalent ground. Their convergence on the same dimensions is evidence the dimensions are the right ones; the frameworks' own materials describe them as a review prompt rather than a scoring system.
AWS Organizations with Service Control Policies, Azure Management Groups with Azure Policy, and GCP folders with Organization Policy all implement the same idea: a deny evaluated above the account's own access control, so a compromised account administrator cannot remove it. That evaluation order is the documented property that makes a guardrail different from a convention.
Service quotas being per-account is documented across AWS services and is the mechanism behind the staging-affects-production failure class; the standard mitigation in provider guidance is account separation rather than quota increases.
AWS Control Tower, Azure Landing Zones and GCP's landing-zone blueprints exist as products because the multi-account structure is common enough to be productised, and all three automate account vending specifically to prevent the drift that hand-built accounts accumulate.
The log-archive account pattern, with write-only access from every account and delete permission held by nobody outside break-glass, appears in all three providers' landing-zone reference architectures for the same reason: audit logs that a compromised administrator can delete are not audit logs.
gp2 to gp3 migration for EBS is a widely documented cost reduction with equal or better baseline performance, and it appears so often in review findings that it is effectively a default-configuration tax on accounts created before gp3 existed.
The debate
Are Well-Architected reviews worth running? Once, for a structured set of fresh eyes, and the value is in the two or three findings that survive triage by expected cost. Annually, usually not, because the findings that matter come from looking at the bill and the IAM configuration, which you can do internally. The critique to state: a provider-led review recommends provider services, and the framework has no vocabulary for "this should not be in the cloud".
Do all six pillars bind equally? No, and pretending otherwise is why reviews produce unranked findings. A pillar binds when it has a named owner and a recurring forcing function: security has an audit, cost has a monthly bill, and reliability binds only when an SLO with an error budget policy exists. The useful move when a pillar is not binding is to create the forcing function rather than to write a better document.
How many accounts? As many as there are distinct access policies or blast radii, and no more. Prod versus non-prod is always a boundary; per-workload is a boundary when owners or compliance scopes differ. The cost of too many is cross-account networking, IP planning and per-account baseline overhead, which in one case was about 3 percent of the bill.
Can tags substitute for accounts? For cost attribution, partially and unreliably, because tagging is a human process with incomplete coverage. For IAM, quotas and blast radius, not at all. The staging load test that exhausted production's quota had no code path to production and was stopped by nothing a tag could express.
Should guardrails be preventive or detective? Both, and the preventive ones must be the short list. A deny policy that blocks legitimate work gets an exception process, then a broad exception, then it enforces nothing, which is the same failure as an over-broad architecture test. Deny the handful of things that are never legitimate (disabling audit logging, root usage, unapproved regions) and detect the rest.
Is the sustainability pillar real? The measurements are real and it binds only where a reporting commitment exists. Its practical overlap with cost optimisation is nearly total, which is worth saying: right-sizing, spot usage, and moving to more efficient instance families improve both, so the pillar rarely produces an action that cost optimisation did not already produce.
Follow-up Q&A
"What are the Well-Architected pillars actually for?"
They are a structured prompt that makes a review consider the dimension it was going to skip, so someone asks about recovery in a room excited about performance. That is real and smaller than the marketing suggests. Their more useful function is forcing the genuine trade-offs into the open: cost against reliability, which requires an availability target and a price for an hour of downtime before the conversation is anything but aesthetic; security against operational excellence, which is what break-glass access exists to resolve; and performance against cost, which requires knowing whether the latency target is a product decision with evidence.
"Do the pillars bind equally?"
No. A pillar binds when it has a named owner and a recurring forcing function. Security has an audit and a compliance questionnaire. Cost has a monthly bill someone senior reads. Reliability binds only where an SLO with an error budget policy exists, and otherwise it is an opinion. Operational excellence binds almost nowhere, because nobody receives a bill for toil. So when a review finds that four of five workloads have no RTO, the productive response is not to write RTOs into a document, it is to create the forcing function, which in one case was an SLO per workload with a signed error budget policy.
"Why is an account boundary different from a tag?"
Because it is a hard boundary for IAM, service quotas, billing and deletion. A principal in dev cannot assume a role in prod unless you explicitly allow it, and the default across the boundary is deny. Service quotas are per account, which is the mechanism behind a failure people do not anticipate: a staging load test exhausting the account's vCPU quota so production's autoscaler could not scale during a peak, with no code path between them. And you can delete an entire environment by closing an account, which is the only reliable cleanup.
"What makes a guardrail different from a convention?"
Evaluation order. A service control policy, Azure Policy or GCP Organization Policy is a deny evaluated above the account's own access control, so a compromised account administrator cannot remove it. That is why the short list matters: deny disabling audit logging, deny modifying the log archive, deny root user actions, deny unapproved regions, deny leaving the organisation. Everything beyond that should be detective, because a preventive policy that blocks legitimate work acquires an exception process, then a broad exception, and then enforces nothing.
"How many accounts should an organisation have?"
As many as there are distinct access policies or blast radii. Production versus non-production is always a boundary. Per workload is a boundary when owners or compliance scopes differ. Per team when teams are autonomous enough that shared quotas would cause contention. A 70-engineer company landed at 22; a five-engineer company is well served by four and adding more is overhead. The cost is real, cross-account networking, IP space planning and per-account baseline services, and in one migration it was about 3 percent of the bill, accepted because a single incident of either kind it prevented cost more.
"What is the hardest part of a multi-account migration?"
Not the infrastructure. In one case it was determining what CI actually needed: four years of permissions accumulated in a single account with no owner and no documentation, which took three weeks of running in a permissive mode with CloudTrail analysis to establish. That cost is entirely a consequence of having had no boundary for four years, which is also the argument for creating the structure before you need it, when the permission set is still small enough to enumerate.
Common misconceptions
"A Well-Architected review tells you what to fix." It produces findings without priorities. Triage them by expected cost and take the top few; in one review three of 47 findings were worth acting on.
"All the pillars matter equally." They matter equally and they do not bind equally. A pillar without a named owner and a recurring forcing function is an opinion.
"We can use tags instead of accounts." Tags cannot express an IAM boundary, cannot isolate a service quota, and depend on a human process for cost attribution.
"More accounts is always safer." Cross-account networking, IP planning and per-account baseline overhead are real. The boundary belongs where the access policy or the blast radius genuinely differs.
"A guardrail is a policy we agreed." A guardrail is a deny evaluated above the account's own IAM. An agreement is a convention, and a compromised administrator ignores it.
"Sustainability is a separate concern." Its actions overlap almost entirely with cost optimisation, so it rarely produces a recommendation that right-sizing did not already produce.
Interview delivery note
Say this verbatim: "The pillars are all real and they do not bind equally. A pillar binds when it has a named owner and a recurring forcing function, which is why security and cost bind and reliability only does when there is an SLO with an error budget policy attached. So when a review finds no RTOs, the fix is to create the forcing function, not to write a better document." It reframes a framework question as an organisational one, which is the staff-level version of the answer.
The senior-versus-staff separator is naming the service-quota failure. A senior engineer separates accounts for security and cost attribution. A staff engineer adds that service quotas are per account, so a staging load test can exhaust production's capacity with no code path between them, and that this presents as a production outage caused by a staging activity, which nobody diagnoses quickly because there is no dependency to find. It is the account-boundary benefit that is not on the usual list.
The second signal is triaging a review by expected cost and saying what you discarded. Reporting that 47 findings became 3 worth acting on, worth roughly $89,000 a year combined, and that the review was worth running once and not annually, shows you can extract value from a framework without being captured by it.
Further reading
- The AWS Well-Architected Framework and the Azure Well-Architected Framework, for the pillar definitions and the trade-off discussions in each.
- AWS Organizations documentation on Service Control Policies, particularly the evaluation order that places them above account IAM.
- AWS Control Tower, Azure Landing Zones and Google's landing-zone blueprints, for the reference multi-account structures.
- The error budget policy page, which is the forcing function the reliability pillar needs to bind.
- The cloud cost levers page, for triaging findings by expected saving.