Start with the decision you need to make, rather than a list of cloud products. You may need to establish whether the current design can support a new workload, whether a dependency threatens a critical journey, or what must change before a migration. A useful review connects recommendations to evidence, assumptions and operating consequences. It should not automatically become a proposal to move everything to another platform.
“Is our architecture good?” leaves both scope and completion unclear. A stronger brief says: “Identify the changes needed to support order processing during the expected peak while keeping operation within our team's capacity.” This does not prescribe a solution. It defines what the review must establish and helps exclude work that cannot affect the decision.
Turn concerns into questions that can be examined
Choose three or four questions in business-priority order. Which parts of the journey fail when an external provider is unavailable? Which option adds work the team cannot currently support? Are there hidden dependencies between the application and its database? Which data requirements need specialist review before a move?
Assign each question a decision owner, not just someone able to grant account access. Product Discovery & Requirements can clarify journeys and constraints when business and technical teams describe different problems. Cloud Architecture Design & Review can then address the agreed systems, environments and architectural options.
AWS describes its Well-Architected review process as a constructive discussion about architectural decisions rather than an audit mechanism. Referencing a review framework therefore should not be presented as certification or formal approval of a system. AWS Well-Architected documentation.
Prepare evidence before granting access
The starting point need not be a copy of customer data. Request a current diagram, component and owner inventory, permitted workload summaries, and relevant change or incident records with sensitive information removed. Date each item. An old diagram may explain design intent without demonstrating how the service currently runs.
| Evidence | Question it helps answer | Limitation to record |
|---|---|---|
| One request's end-to-end path | Where does the journey go, and what depends on what? | Undocumented routes remain unknown |
| Workload and timing measurements | When does the problem occur, and for which operations? | A quiet period does not represent a seasonal peak |
| Environment and ownership inventory | Who can change each part? | Account ownership does not authorize every action |
| Previous recovery observations | What was restored and what failed? | A backup file alone is not restoration evidence |
Use named, read-only access where it is sufficient. Specify its duration, where review outputs may be stored, and how access will be revoked. A global administrator account should not be a routine prerequisite. If an important conclusion requires a state-changing experiment, give that experiment its own target, environment and authorization rather than hiding it inside an assessment.
Hypothetical example: rebuild or separate the processing step?
Consider a business-to-business ordering platform that receives an order, generates a file and passes it to a provider. Users report slow submission near the end of the day. This is an educational scenario, not LAB client work or a market benchmark.
The team supplies three weeks of permitted records. Existing measurements separate application time from provider response time, but do not show how long work waits before file generation starts. Instead of immediately recommending larger servers, the reviewer records that gap.
Two options are compared: improve the current processing path, or move file generation into background processing. The second option may change what users wait for, but also needs understandable order states, duplicate handling, stuck-job alerts and someone responsible for investigating them. Those dependencies belong in the decision, not in a list of surprises discovered after procurement.
The owner requests a bounded experiment using approved test data. If the delay is mostly outside the platform, clearer user feedback or integration changes may matter more than rebuilding the application. If missing measurements still prevent a defensible conclusion, gathering that evidence is a valid next decision. A review should not manufacture certainty merely to finish with a dramatic recommendation.
Accept an actionable report, not a page count
For each material recommendation, request the observed problem, evidence, confidence, alternatives, decision owner and next step. The report should distinguish measured findings from hypotheses requiring a test. Neither the number of pages nor the number of identified risks establishes usefulness.
An acceptance check should establish that:
- Important recommendations trace to a particular environment, component and journey.
- Operating complexity appears alongside performance and cost implications, without invented implementation prices.
- Priorities have reasons and dependencies rather than identical urgency labels.
- Unexamined areas are visible, especially external services and unavailable data.
- Proposed changes have a verification method and a recovery or containment option for the owner to review.
Where the evidence is missing, a small Observability & Reliability Engineering scope may be the appropriate first step. A measured code or configuration problem may instead lead to separately authorized Performance & Security Hardening. The review itself should not grant open-ended permission to make changes.
Scope traps worth avoiding
Selecting a platform before understanding constraints turns the review into a justification exercise. Comparing a small test environment with production without disclosing differences creates false confidence. Assigning every recommendation to “the technical team” also leaves a practical gap: someone needs authority, time and accountability to act.
Confirm an appropriately qualified reviewer for the actual system before commissioning specialist work. A more sophisticated architecture does not create around-the-clock operational cover, and the review should not imply uptime or incident-response commitments that have never been agreed.
Frequently asked questions
Must every cloud account be included?
No. Start with the decision and journey, then include accounts that materially affect them. Record exclusions so a focused review is not mistaken for an organization-wide assessment.
Can diagrams replace direct access?
They may support a proposed-design review. They are weaker evidence of live configuration. State what could not be verified and request missing evidence rather than presenting assumptions as observations.
Does the review include implementation?
Only when separately specified. Options analysis, solution design and implementation are distinct deliverables and can be commissioned in stages.
What should we provide first?
Send the decision, a redacted diagram, system and owner names, and a concise problem summary without secrets. That supports an initial scoping discussion, not a final implementation quotation or performance guarantee.
Reference
AWS Well-Architected documentation, reviewed 26 October 2026. The example and procurement checks are original decision guidance, not AWS certification requirements.
