Cloud Architecture Review Checklist for Business-Critical Systems

A cloud architecture review should connect technical design to business requirements, expose tradeoffs, and produce an owned improvement backlog. It is not a compliance theatre exercise or a generic list applied equally to every workload.

Prepare the Workload Context

Document the users, business purpose, critical journeys, architecture, data, dependencies, deployment, operating team, service targets, regulatory constraints, and current incidents.

Prioritise review areas according to business criticality. A public brochure site and payment platform need different evidence.

Reliability

• Are availability and recovery targets defined from business impact?
• Are failure domains and dependencies mapped?
• Is state protected and recoverable?
• Are timeout, retry, idempotency, queue, and backpressure designed?
• Have backup restore and disaster recovery been exercised?
• Can the team detect partial failure and degraded service?

Security

• Are identities, roles, privileged access, and service accounts controlled?
• Is data classified and protected in transit and at rest?
• Are network paths and public exposure intentional?
• Are secrets managed and rotated?
• Are dependencies, images, and infrastructure scanned?
• Are audit logs protected and incident actions tested?

Cost Optimisation

• Does every material resource have an owner and purpose?
• Are environments, scaling, storage lifecycle, and retention appropriate?
• Are commitments based on stable demand?
• Can cost be connected to a product or business unit?
• Are anomalies routed to accountable teams?

Operational Excellence

• Is infrastructure reproducible and reviewed?
• Are deployment, rollback, configuration, and change history controlled?
• Do logs, metrics, traces, and business signals support diagnosis?
• Are runbooks exercised?
• Are alerts actionable and owned?
• Are incidents converted into completed improvements?

Performance Efficiency

• Are latency, throughput, concurrency, and capacity targets defined?
• Has representative peak load been tested?
• Can components scale independently?
• Are database, cache, network, and external limits understood?
• Does scaling preserve cost and reliability boundaries?

Data and Integration

• Is the system of record defined?
• Are schemas versioned and integrations idempotent?
• Are reconciliation and data-quality rules operating?
• Are privacy, retention, deletion, and residency requirements implemented?
• Can a transaction be traced across systems?

Review Evidence, Not Intent

Ask for configuration, tests, dashboards, incident records, restore results, access reviews, cost reports, and runbook exercises. “We have backups” is weaker than a dated restore test with measured recovery.

Classify findings by business risk, likelihood, effort, and dependency. Name an owner, target, and validation method. Record accepted risk and approver.

Make Review Continuous

Review during design, before launch, after major change or incident, and periodically for critical workloads. Track findings to closure and re-run the relevant evidence.

Framework scores can guide discussion but should not become the goal. A workload improves when material risks are reduced and outcomes become more reliable.

DualByte's cloud infrastructure service can facilitate an evidence-based review and turn findings into a prioritised implementation roadmap.

Sources

• Microsoft Azure Well-Architected Framework
• Microsoft: Complete a Well-Architected Review