Cloud Architecture Review Template (Six Pillars)

Well-architected style review across six pillars: questions, current state, high/medium/none risk, improvement plan, sign-off

アーキテクチャ・システム設計フルWell-Architected pillar names (operational excellence, security, reliability, performance efficiency, cost optimisation, sustainability)cloud review math更新 2026/10/20

エディタで開く.mdをダウンロード

使い方: Use for periodic or pre-launch reviews of a cloud workload. Agree the workload's business targets in section 2 first, rate each question on evidence, and give every High risk an owned action or a signed acceptance. Main pitfall: rating intentions instead of what is in place, which hides the real risks.

プレビュー

Cloud Architecture Review: [Workload name]

Complete review record for one cloud workload, organised by the six pillars commonly used in well-architected reviews: operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. For each pillar it records review questions, current state, risk rating and improvement actions, then rolls them up into a prioritised plan and a sign-off. Provider-neutral; the questions are original to this collection. Replace every [bracketed] value and every row marked Example.

Document control

Field	Value
Document ID	[CAR-PAYMENTS-2026-01]
Workload	[Payments API]
Cloud provider(s) and regions	[Provider, eu-west-1 and eu-central-1]
Review type	[Initial / Periodic / Pre-launch / After major incident]
Review date	YYYY-MM-DD
Version	[0.1]
Status	[Draft / In review / Approved]
Reviewer(s)	[@lead-reviewer], [@reviewer]
Workload owner	[@workload-owner]
Classification	[Internal / Confidential]
Next review	YYYY-MM-DD

Approvals

Role	Name	Decision	Date
Workload owner	[@name]	[Accepted plan / Changes requested]	YYYY-MM-DD
Lead reviewer / cloud architect	[@name]	[Decision]	YYYY-MM-DD
Engineering manager	[@name]	[Decision]	YYYY-MM-DD
Security representative	[@name]	[Decision]	YYYY-MM-DD

Revision history

Version	Date	Author	Change summary
0.1	YYYY-MM-DD	[@name]	Pre-review questionnaire filled by the team
0.2	YYYY-MM-DD	[@name]	Example: Ratings after review session; 4 High, 9 Medium risks
1.0	YYYY-MM-DD	[@name]	Example: Improvement plan approved

Review scope and method
Workload description
Operational excellence
Security
Reliability
Performance efficiency
Cost optimisation
Sustainability
Prioritised improvement plan
Risk acceptance and review sign-off
Appendices

1. Review scope and method

1.1 Scope

In scope	Out of scope
Example: Payments API, its databases, queues and CI/CD pipeline in production	Shared networking hub (reviewed separately by platform team)
Example: Staging environment, only where it affects release safety	Corporate identity provider
[Item]	[Item]

1.2 Method

Pre-review questionnaire completed by the team on YYYY-MM-DD.
Review session of [3 hours] on YYYY-MM-DD with [participants].
Evidence inspected: [architecture diagrams, IaC repository, dashboards, runbooks, last incident reports, cost reports for the last 3 months].
Each question receives a current-state description and one rating.

1.3 Rating scale

Rating	Meaning	Expected response
High risk	Gap likely to cause significant customer, financial, security or compliance impact within 12 months	Action in this quarter or formal acceptance
Medium risk	Gap that increases impact or effort but is unlikely to cause a severe event alone	Action in the next two quarters
None	Practice in place with evidence, or not applicable with reason	No action

2. Workload description

2.1 Business context

Item	Value
Purpose	Example: Authorises and captures card and wallet payments for all web and app checkouts
Users	Example: 4 internal services, about 2 million end customers per month indirectly
Business criticality	Example: Tier 1: checkout stops if unavailable
Revenue or impact at risk	Example: About 18 000 EUR per minute of outage at peak
Regulatory context	Example: Payment card industry scope (tokenised), data protection
Change frequency	Example: 15 to 20 production deploys per week

2.2 Non-functional targets

Target	Value	Current measured
Availability SLO	Example: 99.95% monthly	99.91% (last 3 months)
Latency SLO	p99 at or below 400 ms for authorise	520 ms
RTO / RPO	30 min / 1 min	Not tested
Peak load	900 requests/s (seasonal sale)	650 requests/s observed
Monthly budget	[EUR 42 000]	[EUR 47 500]
[Target]	[Value]	[Measured]

The availability target allows a monthly error budget of:

B = (1 - 0.9995) \times 30 \times 24 \times 60 \approx 21.6\ \text{minutes}

2.3 Architecture overview

The diagram shows the production architecture as reviewed. Components with known gaps are referenced from the pillar tables by name.

Component	Service type	Notes
Payments API	Managed container service, 6 to 30 tasks	Stateless
Relational DB	Managed database, multi-AZ	2 TB, single region
Queue	Managed queue	Dead-letter queue configured
Backup vault	Managed backup	Same region only
[Component]	[Service]	[Notes]

3. Operational excellence

How well the team operates, changes and improves the workload.

ID	Question	Current state	Rating	Improvement action
OPS-01	How are infrastructure and configuration changes made?	Example: 90% in IaC; queue and alarms created by hand	Medium	Import remaining resources into IaC
OPS-02	How do you know the workload is healthy?	SLO dashboard exists; no alert on latency SLO burn	High	Add multi-window burn-rate alerts
OPS-03	How are releases made safe?	Rolling deploy, automated tests; no automatic rollback	Medium	Canary with automatic rollback on error rate
OPS-04	Are runbooks current and tested?	Runbooks for 4 of 9 top alerts	Medium	Write and game-day the remaining 5
OPS-05	How does the team learn from incidents?	Blameless reviews with tracked actions	None
OPS-06	Who is on call and how is load balanced?	6-person rotation, 1 week shifts	None
[OPS-nn]	[Question]	[State]	[High / Medium / None]	[Action]

4. Security

How the workload protects data, systems and identities.

ID	Question	Current state	Rating	Improvement action
SEC-01	How are human and workload identities managed?	Example: SSO for humans; two services use long-lived access keys	High	Move to workload identity; remove keys
SEC-02	Is least privilege enforced?	Task role has wildcard on queue actions	Medium	Scope to named queues and actions
SEC-03	How is data protected at rest and in transit?	Encryption at rest with provider keys; TLS everywhere	None
SEC-04	How are secrets stored and rotated?	Secrets manager; database password not rotated for 14 months	Medium	Enable automatic rotation
SEC-05	How are security events detected?	Cloud audit log to SIEM; no alert on IAM changes	Medium	Add detection rules for IAM and key policy changes
SEC-06	How are vulnerabilities in images and dependencies managed?	Image scanning on push; no SLA for fixes	Medium	Define fix SLA by severity; block criticals
SEC-07	Is there a tested incident response playbook for this workload?	Generic organisation playbook only	Medium	Workload-specific playbook and tabletop
[SEC-nn]	[Question]	[State]	[Rating]	[Action]

5. Reliability

How the workload continues to work correctly and recovers from failure.

ID	Question	Current state	Rating	Improvement action
REL-01	How does the workload handle a zone failure?	Example: Multi-AZ load balancer, API and database	None
REL-02	How does it handle a region failure?	Single region; no recovery plan	High	Decide on pilot-light DR in second region (see 9)
REL-03	Are backups restorable within RTO and RPO?	Snapshots daily, point-in-time on; restore never tested; vault in same region	High	Cross-region backup copy; quarterly restore test
REL-04	How are dependency failures contained?	Timeouts set; no circuit breaker for providers	Medium	Circuit breaker and provider failover
REL-05	Are service quotas and limits monitored?	Not monitored; hit container quota in last sale	Medium	Quota dashboards and pre-sale increase checklist
REL-06	Has the workload been load tested at peak?	Tested to 600 requests/s last year	Medium	Test at 1.5x expected peak before season
[REL-nn]	[Question]	[State]	[Rating]	[Action]

6. Performance efficiency

How efficiently the workload uses resources to meet its performance needs.

ID	Question	Current state	Rating	Improvement action
PERF-01	How were compute types and sizes selected?	Example: Chosen at launch three years ago; not revisited	Medium	Benchmark current-generation and ARM-based instances
PERF-02	How is performance monitored against SLO?	p99 latency 520 ms against 400 ms target	High	Profile authorise path; add read replica for lookups
PERF-03	Is caching used where it helps?	Cache for merchant config; hit ratio 72%	Medium	Tune TTL and key design
PERF-04	Does scaling react fast enough?	Scale-out takes 4 minutes; spikes at sale start	Medium	Scheduled pre-scaling and faster health checks
PERF-05	Are database queries reviewed?	Slow query log enabled; top 3 queries unindexed	Medium	Add indexes; review monthly
[PERF-nn]	[Question]	[State]	[Rating]	[Action]

7. Cost optimisation

How the team understands, controls and reduces cost without hurting other pillars.

ID	Question	Current state	Rating	Improvement action
COST-01	Is spend attributed to this workload?	Example: 85% tagged; shared NAT cost not allocated	Medium	Enforce tags with policy; allocate shared costs
COST-02	Is there a budget and alert?	Budget set; alerts to a mailbox nobody reads	Medium	Route alerts to team channel
COST-03	Are resources right-sized?	Database at 18% CPU average on a large class	Medium	Downsize one class after load test
COST-04	Are commitment discounts used for steady load?	None	Medium	Commit to baseline of 6 tasks and database
COST-05	Are non-production environments switched off when idle?	Staging runs 24x7	Medium	Schedule shutdown nights and weekends
COST-06	Is data lifecycle managed?	Logs kept forever in hot storage	Medium	Tier after 30 days, delete after 13 months
[COST-nn]	[Question]	[State]	[Rating]	[Action]

Estimated monthly saving if all cost actions are completed:

Action	Basis	Estimated saving per month
Example: Commitment discount on baseline	30% on EUR 14 000	EUR 4 200
Example: Staging schedule	65% of hours off on EUR 5 000	EUR 3 250
Example: Database downsizing	One class step	EUR 1 800
[Action]	[Basis]	[EUR]
Total		[EUR 9 250]

8. Sustainability

How the workload reduces its environmental footprint.

ID	Question	Current state	Rating	Improvement action
SUS-01	Is the region choice informed by carbon intensity where latency allows?	Example: Not considered	Medium	Include provider carbon data in region decisions for batch jobs
SUS-02	Is utilisation high enough?	Average CPU 22% across tasks	Medium	Raise autoscaling target from 40% to 60%
SUS-03	Are efficient instance families used?	x86 only	Medium	Trial ARM-based instances (also PERF-01)
SUS-04	Is data stored only as long as needed?	See COST-06	Medium	Shared action with COST-06
SUS-05	Are batch jobs scheduled flexibly?	Capture retries run hourly regardless of load	None
SUS-06	Is the footprint measured?	Provider carbon report not reviewed	Medium	Review quarterly with cost report
[SUS-nn]	[Question]	[State]	[Rating]	[Action]

9. Prioritised improvement plan

9.1 Risk summary

Pillar	High	Medium	None
Operational excellence	1	3	2
Security	1	5	1
Reliability	2	3	1
Performance efficiency	1	4	0
Cost optimisation	0	6	0
Sustainability	0	5	1
Total	5	26	5

9.2 Improvement backlog

Priority score used to order the backlog, where risk weight is 3 for High and 1 for Medium, and effort is in team-weeks:

\text{Priority} = \frac{\text{risk weight} \times \text{pillars affected}}{\text{effort}}

Rank	ID	Action	Addresses	Risk	Effort	Owner	Target date	Status
1	IMP-01	Cross-region backup copy and quarterly restore test	REL-03	High	1 week	[@name]	YYYY-MM-DD	Planned
2	IMP-02	SLO burn-rate alerts	OPS-02, PERF-02	High	0.5 week	[@name]	YYYY-MM-DD	Planned
3	IMP-03	Replace long-lived keys with workload identity	SEC-01	High	1 week	[@name]	YYYY-MM-DD	Planned
4	IMP-04	Profile and fix authorise latency	PERF-02	High	2 weeks	[@name]	YYYY-MM-DD	Planned
5	IMP-05	Region DR decision and pilot-light design	REL-02	High	3 weeks	[@name]	YYYY-MM-DD	Planned
6	IMP-06	Commitment discounts and staging schedule	COST-04, COST-05, SUS-02	Medium	1 week	[@name]	YYYY-MM-DD	Planned
[n]	[IMP-nn]	[Action]	[IDs]	[Rating]	[Effort]	[@name]	YYYY-MM-DD	[Status]

9.3 Timeline

The timeline shows when High risks are expected to close.

10. Risk acceptance and review sign-off

10.1 Accepted risks

ID	Risk	Rating	Reason for acceptance	Compensating measures	Accepted by	Expires
ACC-01	Example: Single-region deployment until DR design is approved (REL-02)	High	DR cost decision pending budget cycle	Cross-region backups (IMP-01); documented manual rebuild procedure	[@workload-owner]	YYYY-MM-DD
[ACC-nn]	[Risk]	[Rating]	[Reason]	[Measures]	[@name]	YYYY-MM-DD

10.2 Sign-off

The review is complete when every High risk has either an action with an owner and date in 9.2 or an acceptance in 10.1.

Statement	Confirmed by	Date
The findings reflect the workload as reviewed	[@lead-reviewer]	YYYY-MM-DD
The improvement plan is accepted and resourced	[@workload-owner]	YYYY-MM-DD
Accepted risks are within the organisation's risk appetite	[@risk-owner]	YYYY-MM-DD
Next review date agreed	[@workload-owner]	YYYY-MM-DD

11. Appendices

11.1 Evidence reviewed

Evidence	Location	Date
Example: Production architecture diagram	[Link]	YYYY-MM-DD
Example: Last two incident reviews	[Link]	YYYY-MM-DD
Example: Cost and usage report, last 3 months	[Link]	YYYY-MM-DD
[Evidence]	[Location]	YYYY-MM-DD

11.2 Glossary

Term	Meaning
Pillar	One of the six areas of quality used to structure the review
SLO	Service level objective: a measurable target for a service level indicator
Error budget	Amount of unreliability allowed by the SLO in a period
RTO / RPO	Time to restore service / maximum acceptable data loss
Pilot light	DR approach keeping a minimal copy of the workload running in another region
[Term]	[Meaning]

11.3 References

Reference	Use
[Provider well-architected framework documentation]	Provider-specific best practices for each pillar
[Organisation cloud standards]	Baseline for ratings
[Previous review document]	Comparison of ratings over time

Standard and licence note

Structure aligned with the six pillar names publicly used by cloud well-architected frameworks (operational excellence, security, reliability, performance efficiency, cost optimisation, sustainability). This template is original text written for this collection; the review questions are its own and reproduce no text from any provider's framework. Consult your provider's framework for its detailed guidance. Template licence: MIT.