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

Most CTOs I talk to have hired the wrong kind of AWS architect at least once. The pattern is consistent: a strong-sounding intro, a clean slide deck, three weeks of "alignment," and then the team is still stuck on the same production problem.

This is the criteria list I'd give a CTO friend if they had to shortlist an architect in a week. Five questions you can ask in a 30-minute call that filter out 80% of the noise.

The trap most teams fall into

The trap is hiring for credentials instead of judgment. "AWS Certified Professional × 6" tells you someone passed exams. It does not tell you what they did when DynamoDB throttled a checkout flow at 11 PM on Black Friday.

Certs are necessary. They are not sufficient. The five criteria below are about judgment under production pressure, the thing certs can't test.

1. Production scars, not just certs

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. Names trade-offs out loud

Ask: "What's the trade-off you're accepting by recommending DynamoDB over RDS here?"Or replace DynamoDB / RDS with whatever the current pitch is.

Strong architects answer the question. They name what they're giving up. Examples:

• "DynamoDB locks you into single-table design: your reporting team will hate it."
• "Aurora Serverless v2 saves cost but cold starts add 5-15s on first request after pause."
• "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. Treats rollback as architecture, not a release checkbox

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:

• 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. Talks about cost in dollars/month, not "scalable"

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

Good architects answer with numbers. Not exact numbers, but ranges with assumptions named.

• "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. Honest about 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 to avoid

• 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, not for 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 don't)

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

Good fit: production AWS systems already running, real users, real bills, real bottlenecks. AWS Bedrock / 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, not a reviewer). Pure CI/CD work without architecture context. Long-term staff-engineering replacement for a missing FTE. Pricing-shopping engagements where the lowest hourly rate wins.

If the criteria above resonate, the next step is a 30-minute call where I'll ask exactly the kind of questions in this article (about your stack) and tell you honestly whether the fit is real.