Hire AWS developers

AWS is a very large catalogue of services, and hiring for it means finding someone who can choose the few you need and refuse the rest.

What AWS actually is

Amazon Web Services is the largest cloud platform, offering hundreds of services covering compute, storage, networking, databases, messaging, analytics and machine learning. Almost anything can be built on it, usually several different ways, and the differences between those ways are often commercially significant rather than merely technical.

That breadth is the reason AWS experience is hard to evaluate. Nobody knows all of it and nobody needs to. What matters is depth in the dozen or so services your workload actually touches, plus the judgement to know when a simpler option is sufficient. A candidate who has used forty services shallowly is usually a worse hire than one who has operated five properly, because the second has been on call for their decisions.

The commercial dimension is unavoidable and often underweighted. On AWS, architecture decisions are cost decisions. Data transfer between zones, the choice between provisioned and on-demand capacity, log retention, idle resources and the difference between a managed service and one you run yourself all show up on the bill. Engineers who cannot read a cost report are making financial decisions without seeing the consequences.

The part that separates seniors from mid-levels

Identity and access management is the foundation, and it is where the most serious mistakes happen. The permission model is genuinely complex, with policies attached at several levels that combine in ways that are not always obvious. The failure mode is universal: something does not work, a broad permission is granted to unblock it, and that permission stays forever. A candidate who can explain how they would debug a permission problem without widening access is telling you something important about how they work.

Networking is the second area and the one that separates application developers who use AWS from engineers who understand it. Virtual private clouds, subnets, routing, security groups and the various gateway types determine what can reach what. A great many availability and security incidents are network misconfigurations, and a great many surprising bills are data moving across a boundary that charges for it.

The third is what the platform does when something fails, because it will. Availability zones exist so that a failure in one does not take the system out, and that only works if the architecture actually spans them and the failure path has been tested. Engineers who have been through a real incident design differently: they set timeouts, assume retries, make operations idempotent and know what their system does when a dependency is slow rather than absent.

Where AWS is used

The label “AWS developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Application hosting

Containers and serverless functions behind load balancers, the most common workload and the one most teams start with.

Data platforms

Storage, warehousing and processing pipelines, where the service choices have very large cost implications.

Regulated workloads

Financial, healthcare and government systems using the platform's compliance programmes and isolation controls.

Migration from on-premises

Moving existing systems into the cloud, which is as much an organisational project as a technical one.

Cost remediation

Reducing spend on an estate that grew without governance, a very common and well-defined engagement.

Event-driven systems

Queues, streams and functions reacting to events, where the platform's managed services do most of the work.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Support status of the tools in this stack

AWS does not version the platform as a whole, so currency is judged by which services and patterns someone has used recently rather than by a release number.

AWS itself is not versioned as a single product, so the useful equivalent is the support status of the tools a AWS engineer works with daily. The table is read from public release data rather than written by hand, so it states what is supported now. It is worth having in front of you during an interview: asking which of these a candidate has upgraded, and what broke, gets you further than asking how many years they have used each.

Source: endoflife.date public release data, read 2026-09-25. A tool with no published end-of-life dates sets its support boundary by ecosystem practice rather than by policy.

The practical use of this is in judging an estate rather than a person. A team running several of these past their support dates is usually not behind by accident; it is behind because upgrades were never anyone's job. That is worth knowing before you hire, because it tells you whether the first six months will be building new things or paying down what was deferred.

The toolchain around it

Nobody hires for AWS alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

IAM

Identity and permissions. The most important service to understand and the most commonly misconfigured.

VPC and networking

Subnets, routing and security groups. Determines reachability, isolation and a large part of the bill.

ECS, EKS or Lambda

Compute. Which one suits depends on the workload, the team and the operational appetite.

RDS or Aurora

Managed relational databases, usually the right default over running your own.

S3

Object storage, with lifecycle policies that materially affect cost at scale.

CloudWatch and OpenTelemetry

Metrics, logs and traces. Log retention settings are a common and avoidable expense.

Terraform or CDK

Infrastructure as code. Console-only changes are a serious operational risk.

Cost Explorer and budgets

Spend visibility, which should be an engineering tool rather than a finance one.

Related skills that frequently appear on the same specification: Node.js, Python, DevOps, Kubernetes, Terraform.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

IAM and least privilege

The single most consequential area, and where real security incidents originate.

• Strong answer: Scopes roles narrowly, explains how to debug a denial without widening it, and has audited unused permissions.
• Warning sign: Grants broad administrative permissions to unblock work and leaves them in place.

Cost awareness

Architecture decisions are financial decisions on AWS.

• Strong answer: Can name what drives cost in their last system and describe a change that reduced it with a number attached.
• Warning sign: Has never seen the bill for infrastructure they designed.

Networking

Separates people who use AWS from people who understand it.

• Strong answer: Comfortable with subnets, routing, security groups and where data transfer charges apply.
• Warning sign: Puts everything in public subnets, or cannot explain why a service cannot reach another.

Choosing compute

Tests judgement rather than knowledge.

• Strong answer: Can argue for containers, serverless or instances based on the workload and the team's operational capacity.
• Warning sign: Applies one answer universally, particularly serverless for everything.

Infrastructure as code

Console-managed infrastructure is unreproducible and undocumented.

• Strong answer: Everything in code, state managed deliberately, changes reviewed like application code.
• Warning sign: Makes production changes in the console and reconciles later, or not at all.

Failure behaviour

Reveals whether they have operated systems or only built them.

• Strong answer: Designs across availability zones, sets timeouts, assumes retries, and has tested the failure path.
• Warning sign: Assumes managed services do not fail, or has never had an incident.

An AWS decision they regret

The most informative question in a cloud interview.

• Strong answer: Names a specific service choice that turned out expensive or operationally painful, and what they learned.
• Warning sign: Has no regrets, which usually means no production ownership.

Warning signs in a AWS codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

Over-broad IAM permissions

• What you see: Administrative access granted to roles that needed one action.
• What it costs: A compromised credential or a mistaken call can affect anything, turning a small incident into a large one.
• The fix: Scope to the specific actions and resources needed. Review access analyser findings and remove unused permissions on a schedule.

Infrastructure created by hand

• What you see: Resources built in the console with no code representation.
• What it costs: Nothing is reproducible, nobody knows why a setting is as it is, and disaster recovery is aspirational.
• The fix: Bring existing resources under infrastructure as code by importing them, and forbid console changes to production.

Unbounded log retention

• What you see: Logs kept indefinitely because the default was never changed.
• What it costs: A steadily growing bill for data nobody reads, which frequently becomes one of the largest line items.
• The fix: Set retention deliberately per log group, and move anything needed long term to cheaper storage.

Cross-zone chatter

• What you see: Services communicating heavily across availability zones without awareness.
• What it costs: Data transfer charges that scale with traffic and appear on the bill without an obvious cause.
• The fix: Keep chatty components zone-local where availability requirements allow, and measure transfer as a first-class metric.

Public subnets by default

• What you see: Databases and internal services with public addresses, protected only by security groups.
• What it costs: A misconfigured rule becomes an exposure rather than a mistake.
• The fix: Private subnets by default. Reach out through a gateway and in through a load balancer.

Serverless as a universal answer

• What you see: Functions used for sustained, predictable, high-volume workloads.
• What it costs: Higher cost than equivalent provisioned compute, plus cold starts and execution limits.
• The fix: Use functions for spiky, event-driven work. Compare against containers with real numbers before committing.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a AWS engineer.

Junior

Deploys and operates within an established account structure. Needs review on permissions and cost implications.

Mid-level

Owns the infrastructure for a service including its code definition, monitoring and alerts. Understands networking and can debug access problems.

Senior

Owns architecture across services, the account and permission structure, the cost model and the failure design. Can justify service choices against alternatives.

Staff

Owns multi-account governance, the security baseline, the cost governance model, and the decision about which workloads belong on managed services at all.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

New environment build

• Usual team: One senior engineer.
• What governs it: Account structure, networking and permissions set at the start are expensive to change once workloads depend on them.

Cost remediation

• Usual team: One senior engineer, time-boxed.
• What governs it: Well-defined and usually high return. Begins with the bill rather than with opinions.

On-premises migration

• Usual team: Two engineers plus application owners.
• What governs it: Scoped by application count and data volume. The organisational work usually exceeds the technical work.

Security and permission review

• Usual team: One senior engineer.
• What governs it: Scoped by account and role count. Findings are usually straightforward; the remediation needs owner buy-in.

Infrastructure as code adoption

• Usual team: One engineer.
• What governs it: Importing existing resources is slower than writing new ones. Expect surprises about what is actually deployed.

Migration work you may actually be hiring for

A large share of AWS work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

On-premises servers to AWS

• Why teams do it: Elasticity, reduced hardware ownership, and access to managed services instead of running everything yourself.
• What to watch: Moving applications unchanged captures the least benefit and often costs more than the hardware did. Decide per application whether to move as-is, re-platform onto managed services, or leave it, and be honest that some should not move at all.

Console-managed infrastructure to infrastructure as code

• Why teams do it: Reproducibility, review, and a disaster recovery story that is real rather than theoretical.
• What to watch: Import existing resources rather than recreating them. Expect the import to reveal configuration nobody knew about, and treat that discovery as the point rather than as a delay.

Self-managed databases on instances to a managed database service

• Why teams do it: Backups, patching, failover and replication handled by the platform instead of by your team at three in the morning.
• What to watch: Version compatibility, extensions and any custom configuration are the constraints. Test a restore from backup before switching, not after.

A single account to a multi-account structure

• Why teams do it: Blast radius limitation, cost attribution and permission boundaries that are actually enforceable.
• What to watch: Do it before the estate grows rather than after. Moving existing workloads between accounts is substantially harder than starting them in the right one.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a AWS engineer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Which services the estate actually uses, since that is what depth should be tested against.
• How infrastructure is currently defined: code, console, or a mixture nobody has mapped.
• What the current monthly spend is and whether reducing it is part of the brief.
• What compliance or data residency requirements apply, because they constrain architecture heavily.
• Whether the person will be on call, and what the current incident process is.
• Whether this is a build, a migration, or a remediation, since these attract quite different people.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

AWS work is counted by the US Bureau of Labor Statistics under Network and Computer Systems Administrators. That classification is broader than the technology itself, so treat the figures as the shape of the market a AWS engineer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 314,340 people in this occupation, with a median annual wage of $99,130.

The spread matters more than the midpoint. The 90th percentile is about 2.5 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a AWS engineer can sit at $62,640 and $155,050 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for AWS frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Network and Computer Systems Administrators, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $133,360; Pittsburgh sits at the bottom with $80,440. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. Washington, D.C., Baltimore, Austin, Raleigh, Tampa, Charlotte each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

Breadth without depth. Ask what they have been on call for. Service count on a CV is close to meaningless.

No cost accountability. Ask what their last system cost to run. Architecture without cost awareness produces expensive surprises.

Console-driven habits. Ask how their infrastructure is defined. Manual estates are a serious operational liability.

No incident experience. Ask about a failure they handled. Design judgement comes from outages more than from documentation.

Hiring AWS developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of AWS engineer who will be available.

• New York, NY $119,390 median
• Seattle, WA $104,440 median
• San Jose, CA $133,360 median
• Washington, D.C. $125,430 median
• San Francisco, CA $129,680 median
• Dallas-Fort Worth, TX $103,260 median
• Los Angeles, CA $106,290 median
• Boston, MA $116,770 median
• Chicago, IL $103,170 median
• Atlanta, GA $101,000 median
• Austin, TX $104,520 median
• Phoenix, AZ $93,730 median
• Philadelphia, PA $100,460 median
• Minneapolis-St. Paul, MN $102,790 median
• Denver, CO $105,090 median
• Detroit, MI $96,400 median
• Houston, TX $101,430 median
• Charlotte, NC $89,990 median
• San Diego, CA $105,170 median
• Salt Lake City, UT $99,110 median
• Miami, FL $97,180 median
• Portland, OR $102,950 median
• Baltimore, MD $122,950 median
• Tampa, FL $101,560 median
• Orlando, FL $91,800 median
• Raleigh, NC $103,380 median
• Kansas City, MO $91,980 median
• Pittsburgh, PA $80,440 median

Frequently asked questions

Do we need an AWS specialist or can our developers manage it?

Developers can deploy applications on AWS and frequently do. What usually goes wrong without a specialist is the surrounding structure: permissions, networking, account organisation and cost. Those are the things that are hard to retrofit and expensive to get wrong. A common and sensible arrangement is a specialist for a defined period to set the foundations, then developers working within them.

How do we control AWS costs?

Make spend visible to the engineers making architecture decisions, which is the step most organisations skip. After that the usual wins are unbounded log retention, idle and oversized resources, storage lifecycle policies, cross-zone data transfer and committed-use discounts on genuinely steady workloads. A focused cost review typically pays for itself quickly on any estate that grew without governance.

Should we use serverless or containers?

Functions suit spiky, event-driven work where you would otherwise pay for idle capacity. Containers suit sustained, predictable load and give you more control over runtime and dependencies. The mistake is choosing either universally. For a steady high-volume workload, functions are often more expensive and less predictable than equivalent container capacity, and the comparison should be made with real numbers.

Is AWS more expensive than running our own servers?

Sometimes, and the comparison is rarely made honestly. Cloud costs are visible and elastic; on-premises costs are lumpy and include staff, space, power, hardware refresh and the capacity you bought and did not use. AWS is usually better value for variable load and for teams that would otherwise carry operational burden, and worse for very steady, very predictable workloads at scale.

How do we avoid lock-in?

Partially, and at a cost. Using containers and open standards keeps portability higher; using deeply managed proprietary services gives more productivity and more lock-in. The honest position is that the productivity is usually worth it and the way to manage the risk is to know which services would be hard to leave and keep that list short and deliberate rather than accidental.

What certifications should we look for?

Certifications show familiarity with the catalogue and say nothing about judgement or operational experience. They are a reasonable filter at junior level and close to irrelevant at senior level. What actually predicts performance is what someone has been on call for and what they would do differently now.

How many AWS accounts should we have?

More than one. Separating production from non-production is the minimum, and separating by workload or team beyond that limits blast radius and makes cost attribution possible. Organisations that run everything in one account find that permissions become impossible to scope and nobody can tell which team is spending what.

What should we fix first on an estate nobody has governed?

In our experience, in this order: find and scope down over-broad permissions, put public resources behind private networking, set log retention, and get infrastructure into code. The first two are security, the third is usually the fastest cost win, and the fourth is what stops the estate drifting again.