Hire AWS Engineers
The most useful quality in an AWS engineer is restraint. AWS will do anything you ask, and the common failure is building something sophisticated that the remaining team cannot operate once the contractor leaves.
Discuss your projectScreen for restraint, not breadth
A candidate who reaches for Kubernetes, a service mesh and six managed services for a single web application and a database is not demonstrating seniority. They are demonstrating that they have not had to hand something over to a team of three with no platform engineer and then watch what happens at the next outage.
So the question we would ask first is: given a standard web application and a small team, what would you build? A good answer is boring — containers on a managed service, a managed database, a pipeline, monitoring on a short list of signals, and infrastructure defined in code. A good candidate will also ask who operates it afterwards before answering, which is the strongest signal available.
The second thing to screen for is IAM. It is the least interesting part of AWS and it determines how bad a compromise would be. A candidate who attaches broad managed policies because scoping them is tedious is handing you a blast radius, and a candidate who talks about least privilege unprompted has probably cleaned up after someone who did not.
What to interview for
Practical signals rather than service trivia. Certifications demonstrate breadth of recall, not judgement.
- Compute choice with reasoning. ECS on Fargate, Lambda, EC2 or a managed platform — and why, against the team that will run it. A candidate with one answer for every situation has one tool.
- IAM least privilege, unprompted. Whether they scope roles to specific actions and resources or attach broad policies for convenience.
- Infrastructure as code as a default, not an afterthought. Terraform or CDK, with changes reviewed in a pull request rather than typed into the console.
- Where the database goes. A candidate who puts RDS in a public subnet should not be hired. Ask how the application reaches a private database.
- Secrets. Secrets Manager or Parameter Store, injected at runtime, separated per environment — not in environment files or a repository.
- Backups and restores. Whether they have ever performed a restore rather than merely configured backups. An untested backup is a belief, and good engineers know the difference.
- Cost awareness. Ask what they would check first on an unexpectedly large bill. Oversized instances, non-production environments running overnight, NAT Gateway charges, egress and unexpired log retention should come up.
- Monitoring restraint. Whether they would alert on a short list of actionable signals or configure everything. A channel of ignored alerts is equivalent to no monitoring.
- What happens after handover. The best candidates raise runbooks and whether the client's team can operate it without being asked.
What they work on
Initial setup
Networking, compute, database, pipeline, secrets, monitoring and backups for a new application — typically a defined project of a few weeks rather than an ongoing need.
Taking over existing infrastructure
Starting by documenting what exists, which is frequently the first time anyone has — including the resources nobody remembers creating.
Cost reduction
Usually finds something worthwhile. The common wins are listed above and most are quick to act on.
Migration onto AWS
Infrastructure in code first, application tested against a copy of the data, then a cutover with a rehearsed rollback.
Security hardening
Network boundaries, IAM tightening, patching and dependency scanning in the pipeline — often triggered by an upcoming audit or an incident.
Reliability work
Multi-AZ where the availability requirement justifies it, tested restores, and alerting on the signals that actually matter.
Common questions
Related in Staff Augmentation
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch