AWS Architecture Guide

Turning Concerns Into Review Questions

Goal

Show how to turn a vague architecture concern into a set of questions that can actually produce action.

The Short Version

A useful review starts when someone names a concern clearly enough that the team can investigate it. The concern might be about risk, cost, reliability, security, or operational burden. The review becomes useful when that concern turns into specific questions.

The durable idea is:

Good architecture questions make the problem concrete enough to improve.

From Vague To Specific

flowchart TB
    A["Vague concern<br/><small>This feels risky.</small>"]
    B["Identify the dimension<br/><small>Is the risk security, reliability, cost, or operations?</small>"]
    C["Ask review questions<br/><small>What fails? What is missing? What is expensive?</small>"]
    D["Prioritize action<br/><small>What changes first?</small>"]

    A --> B --> C --> D

This is the practical use of the framework. It takes feelings and turns them into a decision path.

Good Review Questions

Strong questions usually do one of these jobs:

  • expose a failure mode

  • reveal missing evidence

  • surface a hidden dependency

  • identify a costly design choice

  • clarify who owns the response

For example, instead of asking "Is the system reliable?" ask:

  • What fails when an AZ is unavailable?

  • How do we know the workload is actually recoverable?

  • How often is recovery tested?

That is much easier to act on.

Practical Meaning

A good review question should be:

  • specific

  • answerable

  • connected to a decision

  • useful for prioritizing work

If the question cannot lead to a change, it is probably too abstract.

Example: Security Concern

Suppose a team says, "We are worried about security."

That is too broad to act on. A better set of questions might be:

  • Which identities can change production?

  • Are permissions too broad?

  • Are data paths encrypted and controlled?

  • Can we prove what happened after a change?

That turns a general concern into a reviewable architecture topic.

Common Mistakes

  • Asking questions that only restate the concern.

  • Asking so many questions that the team cannot prioritize.

  • Keeping the question too abstract to produce evidence.

  • Confusing a review question with a solution.

If Someone Asks You

If someone asks, "How do I use Well-Architected in a review?" a clear answer is:

Start with a concern, identify the relevant pillar or pillars, then ask specific questions that expose failure modes, missing controls, cost drivers, or operational gaps. The review should produce a short list of actions, not a long list of opinions.

What You Should Remember

A good review question is one that leads to action.

Questions to Check Your Understanding

  1. What makes a review question better than a general concern?

  2. Why should review questions expose evidence?

  3. What happens when questions are too broad?

Further Study