Architecture Review Checklist for Cloud Applications (2026)

An architecture review checklist for cloud applications is the list of questions a design has to survive before it becomes expensive to change. TL;DR: bring a current diagram and written non-functional requirements, walk security, reliability, performance, cost, operations and data, demand evidence for every answer, then leave with ranked findings that each have an owner, a date and a decision.

Every cloud has a framework for this. None of them stop the classic failure mode: the review that happens the week before launch, runs on a diagram nobody updated since 2023, and ends with "LGTM, ship it" plus a vague "we'll harden it in v2".

This checklist is cloud-agnostic on purpose. If you're all-in on AWS, our AWS Well-Architected review checklist goes deeper on that specific framework. This one is for the review board that sees AWS on Monday, Azure on Wednesday and a hybrid mess on Friday.

What an architecture review checklist for cloud applications should cover

Good news: the three big providers basically agree on what "well-architected" means. They just slice it differently.

Sources: the Azure Well-Architected pillars page lists five pillars, and the Google Cloud Well-Architected Framework lists six, plus cross-pillar perspectives for AI and ML and for financial services.

Pillars are necessary but not enough. A real cloud architecture review checklist also needs the stuff frameworks assume you already did:

• Context: what the workload does, who uses it, and what "good" means in numbers.
• Data: what's stored, who owns it, where it lives, and how long it stays.
• Alternatives: what else was considered and why it lost.
• Sync: how the diagram stays true after launch.

→ Turn this checklist into a reusable review packet with the free Architecture Review Checklist Builder

When to run a cloud architecture design review

Timing is half the value. AWS's review process guidance says reviews belong at key milestones, "early on in the design phase to avoid one-way doors that are difficult to change, and then before the go-live date," and again after significant architecture changes. It also says the review should be "a conversation and not an audit." That advice isn't AWS-specific. It's just correct.

Use reversibility to decide how hard to look:

If the first review happens after the database is chosen and the network is carved up, those findings are one-way doors you already walked through. Book it while the design is still a diagram.

→ See exactly what changed between design versions with Architecture Diff

The pre-review packet: what to bring

Reviews are won before the meeting. Send this packet a couple of days ahead so reviewers show up with questions, not first impressions.

• One workload, clearly scoped. What's in, what's out, which accounts, subscriptions or projects, which regions.
• A diagram that matches the design you're actually proposing. Entry points, trust boundaries, data stores, external dependencies and the critical request path. Not the launch slide from last year.
• Written non-functional requirements. Availability target, RTO and RPO, latency budget, expected load and growth, compliance scope, budget envelope. Our guide to non-functional requirements in design reviews covers how to write them so they're testable.
• Design alternatives. At least one option you rejected, and why.
• The right people. Builders, the on-call folks who'll get paged, a security reviewer, and whoever owns the budget.
• A parking lot. A place for questions nobody can answer yet. Guessing to look good is how bad designs pass review.

If you need a structure for the written part, the solution architecture document template is a solid base for the packet.

→ Generate a reviewable first diagram from your requirements with Architect AI

The cloud architecture review checklist, section by section

These are cloud application design review questions written to extract evidence. They map to the pillars above but aren't any provider's official question set, so use the provider tools for canonical questions and this list to keep answers honest.

1. Context and requirements

• The business outcome and main user journeys are written down.
• Availability, RTO, RPO and latency targets are numbers, agreed with the business.
• Expected peak load and 12-month growth are estimated, with the assumption stated.
• Compliance and data-residency scope is known (or explicitly "none").

2. Security and trust boundaries

The OWASP Threat Modeling Cheat Sheet frames threat modeling as four questions: "What are we working on?", "What can go wrong?", "What are we going to do about it?" and "Did we do a good enough job?" The diagram answers the first one. The checklist covers the rest.

• Every internet-facing entry point is on the diagram, and nothing else is reachable.
• Trust boundaries are drawn, and every flow crossing one is authenticated and encrypted.
• Human access goes through federated identity with roles, not long-lived credentials.
• Workload identities are least-privilege and scoped per service.
• Secrets live in a managed secret store, never in code or images.
• A STRIDE pass (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) was done on the main data flows.

The free STRIDE threat checklist is the quickest way to run that last item without a blank page.

3. Reliability and failure modes

Azure's reliability design review checklist is a good model here: it walks simplicity, critical flows, failure mode analysis, targets, redundancy, scaling, self-healing, testing, disaster recovery and monitoring.

• Critical flows are identified and rated, so you know which ones deserve redundancy.
• Each component on the critical path has a failure mode written down: what breaks, what the user sees, how it recovers.
• No single-zone component sits on the critical path without a stated, accepted reason.
• Dependencies have timeouts, retries with backoff, and a degraded mode.
• Backups exist and a restore has actually been tested, with a date.
• Failover is documented and was exercised, not just drawn. The failover paths guide has a practical drill format.

4. Performance and scalability

• The compute model (functions, containers, VMs) is justified by the workload's shape, not habit.
• The data store matches the access pattern, and the hot path has no long synchronous chains.
• The first bottleneck at peak load is named. "It autoscales" is not an answer if the database doesn't.
• Caching and CDN are used where read-heavy traffic justifies them.
• There's a load test plan for the expected peak.

5. Cost

• Costs that scale with traffic, stored data and data transfer are each understood separately.
• A cost estimate exists for at least two load scenarios, not one magic monthly number.
• Spend can be attributed to this workload through tags, labels or dedicated accounts.
• Budgets and anomaly alerts are configured, with a named human reading them.

Prices change constantly, so any estimate in the packet should say when it was produced and be re-checked against the provider's official pricing calculator before sign-off.

6. Operations and observability

• Every service has an owning team and an on-call path.
• Alerts map to user-facing symptoms and SLOs, not just CPU.
• Deployments are automated, small and reversible, and rollback was tested.
• Runbooks exist for the top failure modes.

7. Data

• Every data store has an owner, a classification and a retention rule.
• Personal or regulated data flows are marked on the diagram.
• Schema changes have a migration and rollback approach.

8. Keeping the design true

• Infrastructure is defined as code, and the diagram is regenerated or checked against it.
• There's a trigger for re-review (new public endpoint, new data store, new region).

→ Run the security section against your actual topology with Threat Analyzer

How to score findings and get to sign-off

A review that ends with 37 equally urgent findings changes nothing. Triage every finding with two questions: is it reversible later, and is anything exposed right now?

Record findings somewhere structured so they don't die in meeting notes. A plain YAML register in the repo next to the IaC works fine:

review:
  workload: checkout-service
  date: 2026-10-27
  decision: approved-with-conditions # approved | approved-with-conditions | rejected
findings:
  - id: SEC-01
    section: security
    risk: high
    door: one-way
    summary: Admin API reachable from the public load balancer
    action: Move admin API behind private ingress with SSO
    owner: platform-team
    due: 2026-11-10
  - id: REL-02
    section: reliability
    risk: medium
    door: two-way
    summary: Payment client retries without backoff or jitter
    action: Add exponential backoff with jitter and a retry budget
    owner: payments-team
    due: 2026-11-24

Sign-off should be one of three outcomes: approved, approved with conditions (the blocking findings listed), or rejected. "Approved, but please look at the networking thing" is not a decision. The post-review actions guide covers how to keep the follow-ups from quietly expiring.

→ Pressure-test scale risks before the review with Scalability Analyzer

Architecture review board anti-patterns to kill

You've seen these. Maybe you've run them. Just stop.

• Review as gatekeeping theatre. If teams dread the board, they'll present the version of the design that passes, not the real one.
• Diagram archaeology. Spending the first 20 minutes figuring out whether the diagram is current. Require a dated, current diagram in the packet.
• Pillar tourism. Asking every question in every section for every change. Scope the review to what changed.
• Yes/no answers. "Do you have backups?" "Yes." Cool, when was the last restore? Ask for evidence.
• Findings with no owner. If it doesn't have a name and a date, it's a wish.
• One-and-done. The design passes, then drifts for 18 months. Re-review on triggers, not on vibes.

The fix for the last two: keep the diagram, the findings register and the deployed infrastructure close enough that differences are visible.

→ Catch where deployed infrastructure drifted from the reviewed design with Drift Detector

Key takeaways

• An architecture review checklist for cloud applications should cover context, security, reliability, performance, cost, operations, data and design-to-reality sync.
• AWS, Azure and Google Cloud publish overlapping pillar frameworks. Use them for depth, and a cloud-agnostic checklist for consistency across teams.
• Review early, before one-way doors, then before go-live and after significant changes.
• Every checklist item should demand evidence: a diagram, a test date, a metric.
• Score findings by reversibility and live exposure, give each one an owner and a date, and end with a real decision.

→ Price the design before sign-off with Cost Estimator

FAQ

What should an architecture review checklist for cloud applications include?

It should cover the workload's context and non-functional requirements, security and trust boundaries, reliability and failure modes, performance and scalability, cost, operations and observability, data handling, and how the design will be kept in sync with what is deployed. Each item should ask for evidence, such as a diagram, a test result or a metric, rather than a yes or no answer.

How is a cloud architecture review different from an AWS Well-Architected review?

An AWS Well-Architected review uses AWS's six pillars and the Well-Architected Tool's official questions for a workload on AWS. A cloud-agnostic architecture review uses the same kind of pillars, which Azure and Google Cloud also publish in their own frameworks, but adds project-specific gates such as requirements, data ownership, design alternatives and sign-off, so it works for any cloud or for multi-cloud designs.

When should you run an architecture review?

Run it early in design, before decisions that are hard to reverse such as the primary data store, network topology, tenancy model or region strategy, then again before go-live and after significant architecture changes. AWS's own review guidance describes these milestones and calls hard-to-reverse decisions one-way doors.

Who should attend an architecture review board meeting?

The people who designed the system, the people who will operate and be paged for it, a security reviewer, and someone who owns the budget or business outcome. A review run only by architects grades the design on paper rather than the system the team will actually run.

How do you prioritise findings from an architecture review?

Rank them by reversibility and current exposure. High-risk findings on hard-to-reverse decisions block the milestone, active exposure gets fixed this sprint, reversible issues get scheduled with an owner and date, and unanswered questions become research actions with an owner instead of guesses.

→ Calculate defensible RTO and RPO targets with the free RTO/RPO Calculator

Make your next review the easy one

The best architecture reviews feel almost boring: the diagram is current, the requirements are numbers, the threat model already exists, and the meeting is spent on the two decisions that actually matter. That's the whole game.

Architecto is built for that workflow. Start from a prompt with Architect AI, run threat, scale and cost analysis on the same diagram, and use Architecture Diff to show reviewers exactly what changed since last time.

→ Start free and bring a review-ready architecture to your next board