Last updated: September 4, 2026
By Tom Kenaley, President and Senior Partner, KORE1
An AWS solutions architect job description works when it names one Well-Architected pillar the seat actually owns, one certification rung, the real account topology, and whether the architect writes infrastructure code or reviews it. Most reqs name none of the four, then wonder why the funnel arrives sorted wrong. If you are still deciding which version of this role you need, our AWS solutions architect hiring guide handles that fork. This page assumes the fork is settled and hands you the words.
A req crossed my desk last February that listed all six pillars of the AWS Well-Architected Framework as responsibilities. Operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Six for six.
Nobody owns six.
The company was a mid-market logistics platform in Dallas with about forty engineers, one production AWS account that had been growing since 2019, and a board conversation coming about a SOC 2 audit. The actual job was security and account separation. That was the entire reason the seat existed, and I only learned it forty minutes into the intake call, because the posting had buried it under a framework recital that made the role sound like a whole cloud center of excellence staffed by one person.
Nine weeks live at that point. Applicants arrived in three separate flavors. The people who could have done the real work were reading a posting that described a job three sizes bigger than the one actually on offer, and they did what anyone would do with a posting like that.
Where I sit on this. KORE1 has run an IT desk since 2005 and I recruit architects across more than thirty U.S. metros through our IT staffing services practice, so a signed offer pays us and you should read the rest with that priced in. The template below is free and works fine without us. Most of what follows costs you an afternoon of thinking, not a fee.
Six Pillars Is a Review Method, Not a Requirements List
The Well-Architected Framework is how AWS structures an architecture review. It was never a job spec. Copying all six pillars into a responsibilities section is the clearest tell that a posting went through committee.
Pick one. Two if the hire is genuinely senior and the org is small enough that the seat carries a second lane.
The pillar you name is not a formality. It decides which resumes surface, because architects have specialized and the good ones are hunting for the specific problem they are already good at. A security-heavy architect reads a cost-optimization posting and moves on. Correctly.
| Pillar the seat owns | What the line in your posting should say | Who that line pulls in |
|---|---|---|
| Security | “Own the IAM permission model and the guardrails across a 14-account Organization, ahead of a SOC 2 Type II audit” | Architects with real audit exposure, often carrying the Security Specialty |
| Reliability | “Own multi-AZ and cross-Region failover design against a four-hour RTO and a fifteen-minute RPO” | People who have run a live failover, not just diagrammed one |
| Cost optimization | “Own a $2.4M annual AWS bill, Savings Plans coverage, and the rightsizing backlog” | FinOps-fluent architects. A much smaller pool than you expect |
| Performance efficiency | “Own latency targets on a read-heavy catalog service and the caching and data-store calls behind them” | Architects who have tuned something while it was on fire |
| Operational excellence | “Own deployment pipeline standards and runbook debt across six product teams” | Closer to a platform or DevOps architect. Say that out loud |
| Sustainability | Only real if a reporting obligation sits behind it | Almost nobody, as a primary. Cut it unless it is true |
One test before the req goes live. Read your responsibilities section out loud, then ask what the architect gets measured on at their first review. If the answer is “all of it,” the posting describes a function rather than a person, and the candidates who could do the narrow version of the job will keep scrolling.
“AWS Certified” Is Four Different Sentences
Every AWS architect posting says certification. Very few say which one. The four rungs are nowhere near interchangeable, and the gap between the Associate and the Professional is roughly the gap between a person who has studied a landing zone and a person who has built one.
| Credential | Exam code | What it actually signals | Where it belongs in an architect req |
|---|---|---|---|
| Cloud Practitioner | CLF-C02 | Vocabulary and billing basics | Nowhere. On an architect posting it reads as unfamiliarity with the ladder |
| Solutions Architect, Associate | SAA-C03 | Studied all four design domains, weighted toward security | “Required, or demonstrable equivalent experience” on a mid-level req |
| Solutions Architect, Professional | SAP-C02 | Multi-account, multi-Region, migration and governance scope | “Preferred” on a senior req. Required only if you will genuinely pass on strong uncertified architects |
| Specialty credentials | SCS-C02, ANS-C01, DEA-C01, MLA-C01 | Depth in one lane. Security, networking, data, machine learning | Name the single one that matches the workload. Never list three |
Exam codes current as of September 2026. Confirm against the Associate and Professional pages before publishing, because AWS revises exam versions on its own schedule and a stale code in a posting is a small credibility leak with a technical audience.
The SAA-C03 grades on four domains. Design secure architectures at 30%, resilient at 26%, high-performing at 24%, cost-optimized at 20%. Worth knowing while you write. It tells you what a certified candidate has definitely been exposed to and what they may only have read about once, which is a different thing from knowing whether they can do the job.
Now the part that costs money. “Required” is a hard filter. It removes people you want.
AWS credentials expire after three years. A twelve-year architect who let SAP-C02 lapse in 2024 while running an actual migration is, in almost every case I have watched, a better hire than someone who passed it last month and has never owned a production account. Write “or demonstrable equivalent experience” and both populations stay in the funnel. Write “required” with no escape hatch and your recruiter is obligated to reject the first group, which they will do quietly, and you will never see the resumes to know what you missed.
There is a version where “required” is correct. Consulting shops and AWS Partners carry certification counts as a partner tier obligation, and the badge is a billable asset rather than a proxy for skill. If that is you, say why in the posting. Candidates respect a stated business reason. They resent an unexplained gate.
Say How Many AWS Accounts You Actually Have
This is the highest-signal sentence available to you and hardly any posting includes it.
Account topology tells an architect what year one looks like more precisely than any responsibilities bullet can. Three companies. Three sentences. Three completely different jobs.
- “We run a single production account, roughly 200 IAM users, no service control policies. The first six months are about getting to an Organization without breaking deploys.”
- “We run 14 accounts under AWS Control Tower with SCP guardrails already in place. The work is tightening them and onboarding two new business units.”
- “We inherited 60 accounts across two Organizations in an acquisition. Consolidating them is the job, and the clock is a transition services agreement that ends in October.”
All three are honest. All three attract a different architect. The first pulls builders who like a blank page and tolerate mess. The second pulls governance people who want the platform to already exist. The third pulls migration specialists who have done a carve-out and know the technical work is the easy half, because the hard half is negotiating with two IT organizations that no longer report to the same executive and hold different opinions about what “done” means.
Nobody is going to reverse-engineer your AWS estate from a bullet that says “experience with multi-account environments.”
Say the number. Say whether Control Tower, AWS Organizations, and IAM Identity Center are live today or sitting on a roadmap. If your environment is one sprawling account with a permissions model nobody can fully explain, write that down too. That is not embarrassing. That is the job, and a specific kind of architect finds the description genuinely appealing, because untangling it is measurable work with a visible finish line and almost nothing else in an architect’s career offers that.
Hands On the Terraform, or Hands Off
Second-most-skipped line, and the one that most often detonates at offer stage.
Some AWS architect seats are diagram-and-review roles. The architect sets patterns, runs design reviews, writes decision records, and never opens a pull request. Other seats expect that same architect to write the Terraform modules, the CDK constructs, or the CloudFormation stacks everybody else consumes. Both are legitimate. Neither is more senior. They attract different people, though, and a candidate who wanted one will resent the other inside a quarter.
Give a rough split and be honest about it.
“Roughly 60% design and review, 40% hands-on infrastructure code in Terraform” is a sentence that saves you six weeks. Senior architects who have moved deliberately away from implementation will screen themselves out, which is what you want if the job is hands-on. Principal-track people who want less keyboard time screen themselves out of the other version. Either outcome beats finding the mismatch in week three of onboarding, or in a resignation conversation in month five.
Name the tool while you are at it. Terraform, CDK, CloudFormation, and Pulumi are not one skill, and an architect with five years of Terraform modules behind them needs a ramp on CDK no matter how good they are. Weeks, not days. Same reasoning we apply to naming a platform in a cloud architect job description, one layer down.
Somebody Has to Own the Bill
Cost optimization is 20% of the SAA-C03 exam and something close to 0% of the average interview loop. That gap is expensive.
If the architect owns AWS spend, put the number in the posting. “You will own a $2.4M annual AWS bill” is a recruiting asset, not a warning label. It signals real scope, executive visibility, and a mandate instead of an advisory seat. Architects who are good at this know they are rare. They price accordingly.
If the architect does not own spend, say who does. Finance, a FinOps team, or the platform lead. Any of those work. Ambiguity produces a specific failure mode where the architect gets held accountable at review time for a bill they had no authority to change, which is how you lose somebody in month eight.
Concrete vocabulary worth putting in the posting when cost is in scope. Savings Plans and Reserved Instance coverage, Spot for interruptible workloads, Graviton migration, tagging and cost allocation discipline, and Cost Optimization Hub for the rightsizing backlog. Those terms filter accurately. “Cost-conscious” filters nothing. Some version of that phrase sits in almost every posting I read, and it has never once told me anything about the seat.
What a strong answer sounds like when you probe this in the loop is worked through in our AWS solutions architect interview questions guide, including the climbing-S3-bill question that reliably separates people who have run an environment from people who have studied one.
What the Band Has to Say
Post a range. The market moved to posted ranges anyway, and in several states it stopped being optional.
| Level | Typical U.S. base band | What the posting has to contain at this level |
|---|---|---|
| Mid, 3 to 5 years on AWS | $135,000 to $165,000 | One named workload, SAA-C03 or equivalent, a named manager |
| Senior, 6 to 10 years | $165,000 to $200,000 | Account topology, the pillar the seat owns, SAP-C02 preferred |
| Principal or lead | $200,000 to $245,000 | Org-wide scope, the executive it reports to, real budget authority |
Bands reflect KORE1 placement data across more than thirty U.S. metros alongside posted-range data from ZipRecruiter and Glassdoor as of August 2026. For the wider occupation, O*NET puts computer network architects at a $134,050 median for 2025, with roughly 11,200 annual openings projected through 2034. There is no cloud specificity in that figure, which is exactly why it sits below every AWS-specific number you will find.
Coastal metros run 15% to 25% above these bands. Consulting and AWS Partner roles add variable compensation that can carry total comp past the top of the principal row. Architects employed by AWS itself are a separate market again. The full breakdown, including why four published averages for this title disagree by more than $100,000, sits in the AWS solutions architect salary guide. If you just need a defensible number for one market before the req goes to finance, the salary benchmark assistant is faster.
AWS Solutions Architect Job Description Template
Everything in square brackets is yours to fill or delete. The italic-style notes inside brackets are there to explain why a line exists, so strip them before the posting goes anywhere near a job board. Cut whole sections that do not match your hire. A tight posting outperforms a thorough one on this role.
Job Title
[AWS Solutions Architect / Senior AWS Solutions Architect / Cloud Solutions Architect, AWS] [Put AWS in the title. Architects filter on it, and a bare “Solutions Architect” title competes with three unrelated markets. The reasoning is in our solutions architect job description template, which covers the four archetypes hiding under the generic title.]
About the Role
We are adding an AWS solutions architect at [Company] to take ownership of [the specific thing: our landing zone build / migration of 40 workloads off two colocation facilities / the security and account model ahead of SOC 2]. Today the estate is [number] AWS accounts, [under Control Tower / under AWS Organizations with no landing zone / a single production account]. The seat reports to [role, named] and works day to day with [the platform team, security, four product engineering pods, and whichever group the architect will spend the most time convincing]. Location: [fully remote within the United States / hybrid out of [city] at [number] days on site / based in [city]].
What You Will Own
- [The pillar. “Own the security posture and IAM permission model across the AWS estate,” or “Own reliability design against a four-hour RTO.” One pillar. Two if the role is genuinely senior.]
- Architecture design and decision records for [named systems or product lines], including the tradeoff documentation that outlives your own tenure
- [Account topology work: landing zone build, Organization structure, SCP guardrails, IAM Identity Center rollout. State what exists and what changes.]
- [Infrastructure code, if applicable: “Write and maintain the Terraform modules other teams consume.” Give the split, roughly X% design and Y% hands-on.]
- [Cost, if applicable: “Own the $X annual AWS bill, Savings Plans coverage, and the rightsizing backlog.” If somebody else owns it, name them instead.]
- Design reviews across [number] engineering teams, and the standards that make the next review shorter than the last one
- [If regulated: architecture evidence for [HIPAA / PCI DSS / FedRAMP / SOC 2 Type II], including control mapping and whatever your auditor actually asks for]
What We Need to See
- [X]+ years designing and running production workloads on AWS. Not adjacent cloud experience relabeled, and not a lab environment
- [The service depth this job needs. Name six to eight real services rather than writing “AWS services.” VPC design and Transit Gateway, IAM and SCPs, RDS or Aurora, EKS or ECS, S3 lifecycle and storage classes, CloudFront, Lambda, plus whatever else your estate actually runs.]
- Infrastructure as code in [Terraform / CDK / CloudFormation], with modules or constructs other engineers have used
- [Account structure experience matching yours: “Has built or operated a multi-account AWS Organization,” or “Has consolidated accounts through an acquisition.”]
- Evidence of a real tradeoff. [Ask for one architecture decision they made under a budget or deadline constraint, and what it cost them. Highest-signal question in the loop, and it belongs in the posting so candidates arrive ready.]
- The ability to explain a design to [the CFO / a compliance auditor / a product manager] without a whiteboard and without condescension
Certifications
[AWS Certified Solutions Architect, Associate (SAA-C03) required, or demonstrable equivalent production experience.] [AWS Certified Solutions Architect, Professional (SAP-C02) preferred.] [If a specialty genuinely maps to the workload, name exactly one: Security (SCS-C02), Advanced Networking (ANS-C01), Data Engineer (DEA-C01), Machine Learning Engineer (MLA-C01).] [If your partner tier requires certification counts, say so here. A stated reason lands very differently than an unexplained gate.]
Nice to Have
- Second-cloud exposure. [Azure or GCP, if your estate is genuinely mixed. Leave it out when it is aspirational, because it dilutes the AWS filter you just built.]
- [Your industry.] Healthcare, financial services, public sector, and regulated manufacturing each carry architecture constraints that take a year to learn cold
- FinOps practice experience, or a track record of taking real money out of a real bill
- Migration experience at [the scale you care about], including the parts that were not technical
Compensation, Location, and Logistics
[$165,000 to $200,000] base, plus [bonus target], [equity], [benefits]. [Remote, hybrid with X days in [city], or on site.] [On-call expectations, honestly stated, including how often it actually fires.] [Travel percentage if the role is client-facing or multi-site.] [Post the range. In several states you are required to, and everywhere else it shortens the funnel by removing people who were never going to accept the number.]
What Comes Up While the Req Is Still in Draft
Is requiring the certification filtering out people we want?
Usually, yes. AWS credentials expire after three years, so a hard requirement removes experienced architects whose certification lapsed while they were doing the exact work you are hiring for.
The fix is four words. “Or demonstrable equivalent experience” keeps both populations in the funnel and costs nothing, because your screen still catches anyone who cannot describe a real design under a real constraint. Keep the hard requirement only where a business reason sits behind it, like a partner tier that counts badges, and put the reason in the posting.
Our posting keeps pulling DevOps engineers. What is doing that?
Almost always the responsibilities section. Pipelines, monitoring, Kubernetes operations, and infrastructure code read as a DevOps role no matter what the title says, because that is the job those bullets describe.
Count how many of your bullets are about building and running versus designing and deciding. If most sit in the first group, you may actually want a DevOps engineer plus an architect one day a week. Cheaper search. Faster, too. If you genuinely need the architect, move design and decision to the top and cut operations down to a single line.
We have one AWS account and no Organization. Is that embarrassing to put in a req?
No, and hiding it costs more than saying it. Untangling one sprawling account into a governed multi-account structure is a defined project with a visible finish line, which a specific kind of architect finds appealing.
What repels candidates is not the mess. It is finding the mess in week two after reading a posting that implied a mature platform, because now the job differs from the one they accepted and the trust deficit starts on day one. Describe the estate accurately and let people opt in.
Should the title say AWS, or just Solutions Architect?
Say AWS if the role is AWS. Job boards weight titles far more heavily than body text, and architects filter their searches the same way, so the qualifier does more work than any bullet underneath it.
The exception is a genuinely multi-cloud seat where AWS is one platform of three. Then “Cloud Solutions Architect” is honest and “AWS Solutions Architect” produces a funnel of specialists who feel misled by week two. The generic title carries its own failure mode, which we broke down in the generic solutions architect JD guide, because four different jobs share it.
How much of our architecture can we describe without giving something away?
More than legal will initially tell you. Account counts, service names, and the shape of the problem are not sensitive. Specific vulnerabilities, audit findings, and customer names are.
“We run 14 accounts under Control Tower and are onboarding two business units” tells a candidate everything useful and an attacker nothing they could not guess about any company your size. If security is genuinely nervous, describe the destination rather than the current state, then cover present condition in the first screen.
Contract or direct hire for a landing zone build?
Both, in sequence. A landing zone build is a project with an end date, while governing the estate afterward is a permanent seat, and reqs that conflate the two tend to start the second search six months late.
Bring in a contract architect for the build, run the direct hire search in parallel, and time the permanent start so the two overlap by a month. That handover beats any document the contractor could leave behind. It is the difference between inheriting a landing zone you understand and inheriting one you are quietly afraid to touch.
The Short Version
Name one Well-Architected pillar the seat owns. Name the certification rung and add the equivalent-experience escape hatch. Say how many AWS accounts you have today and what changes. State whether the architect writes infrastructure code, and roughly what share of the week. Say who owns the bill. Post the range.
Six sentences.
None of them are hard to type. All six are hard to answer, which is why so few postings contain them, and why the ones that do tend to fill in half the time of the ones that lead with a twenty-line service list. Work out the answers with whoever actually owns the estate, before finance approves the req rather than during week nine of a stalled search. After the posting, the interview loop is the next place a good funnel quietly drains.
Our solutions architect, cloud architect, and cloud engineer desks see roughly a hundred AWS reqs a year between them, and the ones that close fast are almost never the ones with the longest requirements list. They are the ones that answered those six questions before anybody wrote a bullet. Our placements hold at 92% retention through the first twelve months, which is the figure I would make any staffing partner quote you before signing anything.
Send us the req you are about to post and we will tell you which of the six it is missing. No fee for that part.
