A cloud design is ready for approval when each check below has evidence behind it and a named person has signed an outcome. This guide is for IT heads, CTOs, engineering managers and application owners at mid-size companies in India and the GCC who have a design or a launch to approve on AWS, Azure or both. It gives 21 checks in five parts, and for each check you get where to look on AWS and on Azure, the evidence to collect, a suggested owner and the risk of skipping it. Use this cloud architecture review checklist after you have written the cloud architecture requirements down, because each later check refers back to them. Treat a check without evidence as not done.
Last reviewed 2026-11-01 by Manish Sharma.
Cloud Architecture Review Checklist: The Short Answer
Run the 21 checks on one design, in five parts: requirements and context, decisions and trade-offs, structure and data, security by design, then operability, cost and change. Then record one of four outcomes with an owner and a date. This is a design review, meaning a structured check of a design before sign-off. It reviews a design, not a running system, so it is neither an availability checklist nor a security audit.
How to Use the 21 Checks
Review one design at a time, with the application owner and an engineer who knows the platform. For each row, note what you saw, attach the evidence (a diagram, an export, a saved assessment) and write down who confirmed it. A check passes only when it has evidence.
The owners and risks are suggestions, so adapt them to your team. The four outcomes are Signisys’ suggested practice, not a vendor rule. We supply no template file, because a table in a shared document does the job.
Collect the evidence packet before the review meeting, so the meeting can focus on decisions.
Cloud Architecture Review Checklist, Part 1: Requirements and Context
Four checks fix what the design must do and for whom. Without them, a reviewer can’t tell whether a sound-looking design is the right one.
| Check | Where to look on AWS | Where to look on Azure | Evidence to collect | Suggested owner | Risk if skipped |
|---|---|---|---|---|---|
| 1. Business goal, owner and criticality are named before design starts | Design document, including AWS account and resource tags | Design document, including Azure subscription and resource tags | One page, signed by the business owner when the design is final | Business owner | Otherwise, effort goes to the wrong workload. |
| 2. Load and growth assumptions have a source | Past metrics, such as those in Amazon CloudWatch, and forecast notes | Past metrics, such as those in Azure Monitor, and forecast notes | Each assumption listed, with a note of who supplied it | Application owner | As a result, capacity rests on a guess. |
| 3. Data classification, residency and compliance scope are confirmed | Data inventory, including the chosen AWS Regions | Data inventory, including the chosen Azure regions | Classification sheet, agreed with legal before sign-off | Compliance lead | If not, data may sit in the wrong place. |
| 4. Availability and recovery targets are agreed before build | Written targets, plus AWS Backup settings if used | Written targets, plus Azure Backup settings if used | Signed targets, linked to the availability review | Application owner | Otherwise, recovery has no goal to test against. |
For residency in a move, see the cloud migration checklist. The method for check 4 is in checks 1 and 2 of the high availability checklist.
Write the cloud architecture requirements before the diagram. A diagram drawn first describes itself, not the need.
Cloud Architecture Review Checklist, Part 2: Decisions and Trade-offs
Four checks put the main choices on record. A decision record is a short note of one design choice: the option chosen, the options dropped, the reason and the date. The cloud architecture requirements from Part 1 are what each record answers to.
| Check | Where to look on AWS | Where to look on Azure | Evidence to collect | Suggested owner | Risk if skipped |
|---|---|---|---|---|---|
| 5. Decision records exist for the main choices, including dropped options | Decision log, kept in the design repository | Decision log, kept in the design repository | One record per choice, including the dropped options | Lead architect | Otherwise, the next team can’t see why. |
| 6. Each component traces to a requirement | Component list, mapped to Part 1 | Component list, mapped to Part 1 | Table that links each component to a requirement | Lead architect | As a result, parts that serve no need stay. |
| 7. The provider’s framework review is run and recorded | AWS Well-Architected Tool, when run in the AWS Management Console | Azure Well-Architected Review assessment, when run for the workload | Saved result, including the high-risk items | Lead architect | Since nothing is saved, known risks go unrecorded. |
| 8. Each product has a named patching and support owner, whether managed or self-run | Service list that marks each product as managed or self-run | Service list that marks each product as managed or self-run | One named owner per product, since patching needs a name | Operations lead | Otherwise, a self-run product has no one patching it. |
Provider Frameworks and Pillar Counts
The AWS Well-Architected Framework comes with the AWS Well-Architected Tool, available in the AWS Management Console, which provides a mechanism for regularly evaluating workloads, identifying high-risk issues and recording improvements. Microsoft’s Azure Well-Architected Framework lists review tools, including the Azure Well-Architected Review assessment, for the same job. As of November 2026, Azure lists five pillars, AWS six, and the Google Cloud Well-Architected Framework six.
Cloud Architecture Review Checklist, Part 3: Structure and Data
Four checks confirm that the design has a drawing, clear boundaries and an owner. A trust boundary is a line where the level of trust changes, such as the edge between your network and a third-party service.
| Check | Where to look on AWS | Where to look on Azure | Evidence to collect | Suggested owner | Risk if skipped |
|---|---|---|---|---|---|
| 9. A current diagram shows components, data flows and trust boundaries | Diagram kept in the design repository | Diagram kept in the design repository | Diagram with a last-updated date, so reviewers know it is current | Lead architect | Otherwise, reviewers judge a drawing that is out of date. |
| 10. Component boundaries and where state lives are clear | Component list, including session and data store settings | Component list, including session and data store settings | Each component marked stateless or stateful | Lead architect | As a result, one part can become the limit. |
| 11. Each data store has an owner, a growth estimate and a rebuild path | Database and storage inventory, with owners | Database and storage inventory, with owners | Owner, growth note and rebuild steps for each store | Data owner | If not, a lost store has no known way back. |
| 12. Each third-party integration is documented, including how it fails | Integration list, including each service’s limits | Integration list, including each service’s limits | Authentication, limits and failure handling, plus a review date | Integration owner | Otherwise, when an outside service fails there is no plan. |
For stateless servers, see Step 2 of the availability guide.
A diagram that no one has updated since design is not evidence. Check its date before accepting it.
Cloud Architecture Review Checklist, Part 4: Security by Design
Four checks set security in the design itself. Least privilege means giving each person or workload only the access it needs. Blast radius means how far one failed or compromised part can reach.
| Check | Where to look on AWS | Where to look on Azure | Evidence to collect | Suggested owner | Risk if skipped |
|---|---|---|---|---|---|
| 13. Human and workload identities use least privilege, with no shared long-lived credentials | AWS IAM roles and policies, including any long-lived keys | Microsoft Entra ID roles and managed identities, including any shared accounts | Access list that shows who holds which role | Security lead | Otherwise, one leaked credential opens too much. |
| 14. Secrets sit in a managed store, with encryption and a named key owner | AWS Secrets Manager, with AWS Key Management Service for keys | Azure Key Vault, which holds secrets and keys | Store settings, plus the key owner’s name | Security lead | As a result, no one is answerable for a key. |
| 15. Network exposure is limited and segmented | Security groups, plus the VPC design | Network security groups, plus the virtual network design | List of public endpoints, with a reason for each | Network lead | If not, internal parts may be open to the internet. |
| 16. Blast radius is limited by account and environment | AWS Organizations accounts, such as separate production and test | Azure subscriptions and management groups, such as separate production and test | Account or subscription map, split by environment | Lead architect | If not, one fault can reach production and test alike. |
Key Takeaway Security by design means writing each of these four answers down before launch, not finding them afterwards.
Cloud Architecture Review Checklist, Part 5: Operability, Cost and Change
Five checks show that the team can run, fund and change the design. Part 5 has two tables.
Build and Operate
Infrastructure as code means defining environments in files that a tool applies, so changes are repeatable.
| Check | Where to look on AWS | Where to look on Azure | Evidence to collect | Suggested owner | Risk if skipped |
|---|---|---|---|---|---|
| 17. Infrastructure is defined as code, and environments are separate | AWS CloudFormation templates | Bicep or ARM templates | Repository and environment list, so each environment is traceable | Platform lead | Otherwise, changes made by hand can’t be repeated. |
| 18. Operating ownership and the skills to run the design exist | Rota, including on-call cover | Rota, including on-call cover | Named operators, plus a skills gap list | Operations lead | As a result, the design outgrows the team. |
Cost and Change
| Check | Where to look on AWS | Where to look on Azure | Evidence to collect | Suggested owner | Risk if skipped |
|---|---|---|---|---|---|
| 19. A cost model covers normal load as well as peak load, with a cost owner | AWS Cost Explorer history, since it shows past load | Microsoft Cost Management history, since it shows past load | Model with its assumptions and a named owner | Cost owner | If not, a peak brings a surprise. |
| 20. An exit and change plan lists when to re-review | Change plan, kept in the repository | Change plan, kept in the repository | Plan that names what triggers a re-review | Lead architect | If not, drift goes unnoticed. |
| 21. The availability review has been run before approval | Result of the availability review, when it has been run | Result of the availability review, when it has been run | The completed high availability checklist | Application owner | Otherwise, failures surface in production. |
For check 19, the cloud cost optimization checklist scans a running environment. Its check 3 also covers budgets and anomaly alerts. An exit plan describes how you would leave a service or move off a product.
Re-review when a major change lands. The right rhythm depends on how fast the design changes, so no single interval suits every team.
Key Takeaway A check without evidence counts as not done, so the review ends only when every row has proof and an owner.
The Review Decision
Record one of four outcomes, not just “approved”. These outcomes are our suggested practice.
- Approved: no material risk remains.
- Approved with conditions: each gap has an owner, an action and a due date.
- Rework required: the team must close a material gap first.
- Rejected: the design does not meet the requirements.
Each accepted risk gets an owner and a review date. Rank findings by how hard they are to reverse and how exposed the design is; this ranking is a suggestion, not a rule. The record holds the scope, the checks, the evidence, the exceptions and the date to review again. The same record pattern appears in the finding record of the high availability checklist.
Gather it for all 21 checks.
Do it before the meeting.
Note any conditions with it.
Decide what starts the next review.
Signisys provides cloud services and platform engineering, including support for designing scalable and resilient cloud architecture. The reliability and resilience work page explains the wider approach.
What This Checklist Does Not Cover
This list reviews a design, so it leaves out the availability review (high availability checklist), the method to improve availability (availability guide), a migration (cloud migration checklist) and cost scans (cloud cost optimization checklist). It also leaves out what architecture is, the practices, a security audit or penetration test, and a template file. An independent review helps when no one owns the design, when decisions have no record, or before a large build. To weigh application styles before a review, read how to choose between three application styles.
Cloud Architecture Review Checklist FAQ
When should a design be reviewed?
What should be first on a cloud architecture review checklist?
Who should own each check?
What is the difference between this checklist and a high availability checklist?
When is a design ready for approval?
Does the checklist work for both AWS and Azure?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.