Well-Architected is not a checklist: gathering requirements before you design on AWS

Well-Architected is not a checklist

Recently, in a working session, the team showed up with the AWS Well-Architected Framework turned into a spreadsheet. "Yes" and "no" columns for every best practice. The idea was simple and dangerous: once every box was checked, they'd have "the perfect architecture."

I've seen this scene many times. And it's the best entry point to talk about what, in my experience leading Landing Zones and architectures in banking and logistics, is the most important skill of a cloud architect: gathering requirements.

The skill that isn't on the certifications

Technical skills come with time and experience. What separates a good architect from a great one are the soft skills: truly listening, solving problems, and communicating.

My first piece of advice sounds counterintuitive: forget everything you think you know when you walk into the first meeting. I've seen too many architects jump straight to the solution because they've "seen it before." Every organization is unique, and assuming you know their needs is the fastest way to miss the requirements that matter most.

Start with the 30,000-foot view

Instead of diving into technical specs, I start with broad business questions:

• What keeps you up at night?
• Where do you want the business to be in three years?
• What would make this project a success?

What you learn is surprising. A client may insist they "need" a multi-region deployment. But after these questions, their real concern surfaces: business continuity during disasters. And it turns out a single, well-designed region — with multi-AZ failover and cross-region backups — meets that need at half the cost.

Listen for real

When a client asks for "better performance," don't start talking instance types. Ask what performance means to them: response time, throughput, user experience? Often, what they describe as a performance problem is actually a bottleneck in application design, data flow, or deployment pattern.

I organize requirements in layers, like peeling an onion:

1. Business goals and constraints.
2. Operational and security requirements.
3. Technical needs.
4. Growth and scalability plans.

And pay attention to silences. Sometimes what a client doesn't say is as important as what they do. Where they hesitate, that's where to dig deeper.

The chain of "whys"

One of my favorite techniques: keep asking "why?" until you reach the root cause.

"I need more storage." → Why? → "For the log files." → Why so many logs? → "For compliance auditing." → Why that audit requirement?

Suddenly, the real problem wasn't storage: it was compliance and governance, which can lead to a completely different solution than "add disk."

An AWS architect doesn't sell AWS services. We're not salespeople. Our job is to solve business problems with AWS services. The difference is subtle but fundamental: understand the problem first and the right solution becomes clear.

The Framework is a lens, not a rulebook

Here I come back to the spreadsheet working session. The problem with the yes/no sheet is that it turns a discovery tool into a formality. Well-Architected doesn't ask "do you have encryption?" It asks "how does your encryption strategy align with your security objectives?"

Each of the six pillars is a lens that reveals hidden risks and optimization opportunities:

• Reliability: I don't just check whether backups exist. I evaluate the entire recovery strategy against the business. Once I understand the real RTO and RPO, I can design the right mix — multi-AZ, cross-region replication, pilot light — aligned with clear SLOs.
• Performance Efficiency: instead of asking "did you consider serverless?", I explore whether their workload patterns actually make Lambda more efficient than EC2.
• Cost Optimization: I map the real business requirements against the current architecture. In one session, the team wanted "everything in real time." On analysis, only ~20% of the workload needed it; the rest could be batch-processed, cutting cost significantly.

The framework's questions become discussion points in architecture sessions, not boxes to tick.

When requirements clash with best practices

"I want everything in a single Availability Zone to save money." "I don't need encryption because my data isn't sensitive." These moments aren't obstacles: they're teaching moments.

What works best for me:

• The future story: walk through scenarios together. What happens if there's a breach? What if industry regulations change? It helps the team see beyond immediate convenience.
• Real, anonymized examples: that time redundancy was dropped to save money, and ten times that was lost during the first major outage.
• Translate to business impact instead of quoting the best practice. Learning happens when it's practical.

And I accept we can't always reach perfection immediately. That's why I help build a gradual roadmap — crawl, walk, run — starting with what's most critical. It makes the transformation manageable and, above all, builds trust.

Questions I use per pillar

There's no room for the full list (in my sessions I use a 17-category questionnaire), but these are the kind that open the conversation:

• Organization: how do you measure the success of this workload? What mandates or approved regions exist?
• Security: how do you manage identity and access today? Data residency?
• Reliability: what's your RTO and RPO? Which scenarios is it critical to recover from?
• Performance: how do you tell acceptable performance from unacceptable?
• Cost: is there a threshold where cost becomes unacceptable? Who approves?
• Sustainability: right-sizing and auto-scaling often align environmental impact with savings.

Measuring success (without going back to the checklist)

Measuring matters, but as a compass, not a grade. Some metrics I use per pillar:

• Operational Excellence: MTTR, deployment frequency and success rate, automation coverage.
• Security: patching time, % of resources compliant with best practices, time to respond to events.
• Reliability: availability, SLA compliance, successful failovers.
• Performance Efficiency: latency, throughput, cache hit rates.
• Cost Optimization: cost per unit of work, reserved instance coverage, cloud ROI.
• Sustainability: carbon footprint, resource effectiveness, hardware lifecycle.

Architecture is a journey, not a destination

What I love most about treating Well-Architected as a process — and not a checklist — is that it becomes a living part of the architecture. It evolves with the workload. As the business changes or new services appear, the framework lets us reassess and optimize. It stops being a one-time exam and becomes a culture of continuous improvement.

Checking every box was never the goal. Understanding the business is.

So, how do you use Well-Architected: as a checklist or as a lens? Which business question has completely changed one of your designs? Share it in the comments — and if this piece helped, pass it along to whoever is shaping their next architecture.