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 |
Contents
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)×30×24×60≈21.6 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:
Priority=effortrisk weight×pillars affected | 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.