# 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*.

<!--
Guidance: How to use this template
- Fill section 2 (workload) with the team before the review session. A
  review without agreed business requirements turns into a list of
  generic best practices.
- Rate each question on evidence, not on intention. "We plan to" is a
  current state of "not in place".
- Use three ratings only: High risk, Medium risk, None. High means the
  gap can plausibly cause a serious business impact within a year.
- Every High risk needs an action in section 9 with an owner and a date,
  or an explicit acceptance in section 10.
-->

## Document control

<!-- Guidance: Identify the workload, the review session and who took part. Reviews are repeated; keep each one as a dated version. -->

| 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

<!-- Guidance: Record each review cycle and the major changes in risk ratings. -->

| 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

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Review scope and method](#1-review-scope-and-method)
2. [Workload description](#2-workload-description)
3. [Operational excellence](#3-operational-excellence)
4. [Security](#4-security)
5. [Reliability](#5-reliability)
6. [Performance efficiency](#6-performance-efficiency)
7. [Cost optimisation](#7-cost-optimisation)
8. [Sustainability](#8-sustainability)
9. [Prioritised improvement plan](#9-prioritised-improvement-plan)
10. [Risk acceptance and review sign-off](#10-risk-acceptance-and-review-sign-off)
11. [Appendices](#11-appendices)

## 1. Review scope and method

<!-- Guidance: State what was reviewed, how, and what was excluded. Readers must be able to judge how much weight to give the findings. -->

### 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

<!-- Guidance: What the workload does, for whom, how critical it is and the numbers that define "good enough". The review judges against these, not against a generic ideal. -->

### 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.

```mermaid
flowchart LR
  clients([Checkout services]) --> lb["Load balancer (2 AZ)"]
  lb --> api["Payments API (containers, autoscaled)"]
  api --> db[("Relational DB, primary + standby")]
  api --> cache[("Cache cluster")]
  api --> q[["Queue: capture jobs"]]
  q --> worker["Capture workers"]
  worker --> psp["Payment service providers"]
  api --> psp
  api --> logs["Logs and metrics"]
  db -.->|"snapshots"| backup[("Backup vault, same region")]
```

| 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

<!-- Guidance: Can the team run, observe and change the workload safely, and does it learn from events? Look for automation, observability, runbooks and post-incident learning. -->

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

<!-- Guidance: Identity, detection, infrastructure protection, data protection and incident response. Ask for evidence: policies, logs, scan results. -->

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

<!-- Guidance: Can the workload withstand and recover from failures of components, zones, regions and dependencies, and meet its targets under load? -->

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

<!-- Guidance: Are resources selected, sized and monitored to meet performance needs as demand and technology change? -->

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

<!-- Guidance: Does the workload deliver its value at the lowest reasonable cost, and does the team know and own its spend? -->

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

<!-- Guidance: Does the workload minimise the energy and resources it consumes? Many actions overlap with cost; record them here too when the main reason is environmental. -->

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

<!-- Guidance: Consolidate actions, merge duplicates across pillars, and order by risk reduction per effort. Give every High risk an owner and a date. -->

### 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.

```mermaid
gantt
  title Improvement plan
  dateFormat YYYY-MM-DD
  section High risk
  Cross-region backup and restore test :a1, 2026-11-02, 7d
  SLO burn-rate alerts                 :a2, 2026-11-02, 4d
  Workload identity                    :a3, after a2, 7d
  Authorise latency fixes              :a4, after a1, 14d
  DR decision and design               :a5, after a3, 21d
  section Medium risk
  Cost and sustainability actions      :b1, 2026-12-01, 21d
```

## 10. Risk acceptance and review sign-off

<!-- Guidance: Any High risk not scheduled for remediation must be accepted by someone with authority over the business impact, with an expiry date. -->

### 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

<!-- Guidance: Evidence list, glossary and references so a later reviewer can check the basis of each rating. -->

### 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.