Have Cloud Architects Become Personal Shoppers for the Big Three?

I’ve sat through plenty of “architecture reviews” where the main debate is which AWS, Azure, or GCP service logo to put on the diagram.

Someone suggests a managed database. Someone else counters with a different managed database. A third person has a strong opinion about a message queue. Forty minutes later, we’ve had a lively discussion about vendor features and nobody has mentioned the actual problem we’re trying to solve.

This isn’t architecture. It’s shopping.

The menu is not the meal

Cloud providers are tools, not outcomes. The job of an architect isn’t to pick from a menu — it’s to understand the problem, weigh the trade-offs, and design something that lasts.

But somewhere along the way, “cloud architect” started to mean “person who knows a lot of service names.” The certification programmes reinforce this. They test whether you know the difference between seventeen types of storage class, not whether you can design a system that’s still maintainable in three years. Even the AWS Well-Architected Framework — which is genuinely useful — can become a checkbox exercise if you treat it as a menu rather than a set of principles.

The result is architecture reviews that start with the solution and work backwards to the problem. That’s exactly the wrong way round.

Vendor knowledge matters — but it’s table stakes

Don’t get me wrong. You absolutely need to know your way around the cloud providers. If you’re designing for AWS and you don’t know the difference between SQS and SNS, or the cost implications of NAT gateways, you’re going to have a bad time.

But that knowledge is necessary, not sufficient. It’s the entry fee, not the value.

The real value comes from the stuff that doesn’t appear on a certification exam:

• Understanding the problem domain well enough to know what “good” looks like for this specific organisation, not in the abstract.
• Knowing when not to use a managed service. Sometimes a Postgres instance on a VM is the right call. Sometimes a simple cron job beats a serverless orchestration pipeline. The best architecture is often the most boring one.
• Designing for the team you have, not the team you wish you had. A beautifully designed event-driven microservices architecture is worthless if nobody on the team can debug it at 3am.
• Making trade-offs explicit. Every architectural decision is a trade-off. The architect’s job is to make those trade-offs visible and help the organisation make informed choices — not to hide complexity behind a vendor logo.

The certification trap

The cloud providers have done a brilliant job of creating a world where “architect” means “person who has passed our exams.” I say this as someone who holds certifications across all three hyperscalers.

The certifications are useful. They force you to learn services you might not otherwise encounter. They give clients a quick signal that you know your way around the platform. But they also create a subtle bias: when all you have is a hammer, everything looks like a service from the vendor whose exam you just passed.

I’ve seen architects recommend absurdly complex solutions using cutting-edge managed services when a straightforward approach would have been cheaper, faster to build, and easier to maintain. Not because the complex solution was better, but because it was more interesting and used more of the services they’d just learned about.

What good architecture actually looks like

The best architectural decisions I’ve made have usually been the boring ones:

• Choosing a well-understood relational database over a trendy NoSQL option because the data was clearly relational and the team knew SQL.
• Keeping a monolith instead of splitting into microservices because the organisation had four developers and didn’t need the operational overhead.
• Using a simple pull-based deployment instead of a sophisticated GitOps pipeline because the team deployed twice a week and didn’t need continuous delivery.
• Recommending IaaS over PaaS because the managed service had constraints that would have required ugly workarounds within six months.

None of these decisions would make a good conference talk. All of them saved their organisations significant time, money, and complexity.

Step back and ask why

The next time you’re in an architecture review and the conversation is about which managed service to use, try asking a different question: “What problem are we actually solving here, and what’s the simplest thing that could work?”

You might be surprised how often the answer doesn’t involve the latest service announcement from re:Invent.

Cloud providers are tools. Excellent tools, with genuinely useful capabilities. But the job of an architect is to understand the problem first and reach for the tools second. Not the other way round.