How to choose an AWS production architect: 5 criteria CTOs actually use

Hiring the wrong kind of AWS architect follows a familiar pattern: a strong intro, a clean slide deck, three weeks of "alignment", and a team still stuck on the same production problem. This guide is for a CTO or founder who has to shortlist an AWS production architect in a week. You get five questions to ask in a 30-minute call that filter out 80% of the noise, what strong and weak answers sound like, and the red flags to walk away from.

Hire for judgment, because certifications do not test it

The trap is hiring for credentials instead of judgment. A wall of AWS certifications tells you someone passed exams. It does not tell you what they did when Amazon DynamoDB throttled a checkout flow at 11 PM on Black Friday.

Certifications are necessary, but they are not sufficient. The five criteria below test judgment under production pressure, which a certification exam cannot test.

1. They can walk you through a real incident

Ask: "Tell me about an incident you got paged for. Specific service. Specific failure mode. What did you do in the first 15 minutes?"

A real production architect answers in concrete terms: "Lambda was retrying because the downstream Aurora connection pool was exhausted. We swapped to RDS Proxy and added an SQS in between as a buffer." They name the service, the failure, the fix, and what it cost to get there.

A weaker answer sounds like: "I designed a robust serverless architecture that ensured high availability." If they can't name a specific service and a specific bad moment, they probably haven't carried the pager.

2. They name the trade-off they are accepting

Ask: "What's the trade-off you're accepting by recommending DynamoDB over RDS here?"Or swap DynamoDB and Amazon RDS for whatever the current pitch is.

Strong architects answer the question and name what they are giving up. Examples:

• "DynamoDB makes you design around access patterns up front, so ad hoc reporting gets hard: your reporting team will hate it."
• "Aurora Serverless v2 with auto-pause saves cost, but the first request after a pause waits about 15 seconds, longer after a day paused."
• "Step Functions is more durable than Lambda chains, but harder to debug locally."

Weaker architects say "DynamoDB is more scalable" and leave it there. If everything they recommend is unambiguously better than every alternative, they haven't thought about the trade-off.

3. They design rollback around state

Ask: "How would you roll back this change if it broke production at 3 AM?"

The answer matters more than the design. If they shrug and say "we'd redeploy the previous version," they're not thinking about state. State is what breaks rollback.

Good rollback answers cover:

• AWS Lambda alias flip: current vs previous version, single API call
• Database migration: additive only, backfill before flip, decommission later
• Queue state: what happens to in-flight messages
• Feature flags: kill switch independent of deploy
• Cache state: invalidation strategy on rollback

If they think rollback is "just CI," they've never had a rollback that corrupted production data.

4. They estimate cost in dollars per month

Ask: "What does this architecture cost at 100K monthly users? At 1M?"

Good architects answer with numbers: ranges with the assumptions named, rather than exact figures.

• "At 100K MAU, ~$3-5K/month: mostly Lambda + DynamoDB + S3"
• "At 1M MAU, ~$30-50K/month: Lambda flat per-request, DynamoDB cost grows with writes"
• "The cliff is at ~5M MAU when you'll need to switch from on-demand to provisioned capacity"

Weak architects say "this scales" and stop. That's not an answer. AWS scales technically. Whether it scales financially is the architect's job.

5. They say what is out of scope

Ask: "What's not included in this engagement?"

The honest architect has an immediate, specific list. "I won't manage the team's deploys. I won't write production code beyond reference implementations. I won't replace your CTO on hiring decisions."

The architect who can't say no (who'll "do whatever you need") is either inflating scope to pad the engagement, or about to over-promise and under-deliver. Both are bad.

Red flags that mean you should walk away

• Slide-first responses. If their first message after a scoping call is a 30-slide deck instead of a 1-page architecture sketch, they're optimizing for closing the deal over doing the work.
• No public proof. No blog, no community involvement, no case studies, no GitHub. They might still be good. They might also have nothing to show.
• "Industry best practices" with no caveat. Best practices are starting points. An architect who treats them as conclusions hasn't operated at the scale where defaults break.
• Refuses to talk to your engineers.Real architecture decisions need engineer input. If the architect only wants exec meetings, they're not doing the actual work.
• One framework for every problem. "I always use Terraform" or "I always go serverless" (without context) usually means they've only seen one shape of problem.

Where I fit and where I do not

I'll save you the pitch and just name the fit.

Good fit: production AWS systems already running, real users, real bills, real bottlenecks. Amazon Bedrock or retrieval-augmented generation (RAG) in production with reliability or cost issues. Migrations off monoliths with rollback risk. Cost reviews where you want sanity-checked recommendations before committing to a consultancy contract.

Bad fit: greenfield projects with no production yet (you need a builder before you need a reviewer). Pure CI/CD work without architecture context. Long-term staff-engineering replacement for a missing full-time engineer. Pricing-shopping engagements where the lowest hourly rate wins.

If these criteria match what you need, the next step is a 30-minute call where I ask the questions from this article about your stack and tell you honestly whether the fit is real.