Hire AWS Cloud Engineers: Rates, Vetting and Engagement Models

Four jobs hiding behind one title

The job title hides enormous variance. On a real project, an AWS cloud engineer is doing some mix of four different jobs: writing infrastructure as code (Terraform, CDK or CloudFormation), designing the network and identity layer (VPCs, subnets, security groups, IAM roles and policies), running the delivery pipeline (CodePipeline, GitHub Actions, ECS or EKS deploys), and owning the on-call story (CloudWatch alarms, log retention, incident response). Some people are strong in two of those four. Almost nobody is strong in all four, and the ones who are cost accordingly.

Here is the failure we get called in to clean up. A funded startup hires a contractor who has three AWS certifications and a confident LinkedIn. He builds the environment by clicking through the console because it is faster, promises to "codify it later", and ships a working staging environment in two weeks. Everyone is happy. Six months later he is gone, and the team discovers that production runs on an EC2 instance nobody can rebuild, the security group allows 0.0.0.0/0 on port 22 because that was easier during setup, the RDS instance has no automated snapshot policy, and the entire IAM strategy is one admin user whose access keys are in a shared 1Password note and hardcoded in two Lambda functions. Then the bill arrives: $14k a month for a workload that should cost $2k, because there are three NAT gateways nobody needed, unattached EBS volumes from deleted instances, and a dev environment that has been running at full size since March.

That is the actual failure mode. It is not that the engineer could not use AWS. AWS makes it trivially easy to build something that works today and is unownable tomorrow. The difference between a good AWS engineer and an expensive one is almost never raw service knowledge. It is whether they instinctively refuse to create anything by hand, whether they think about the second person who has to touch this, and whether they treat the bill as an engineering metric rather than a finance problem.

The second common failure is scope confusion. Teams hire an "AWS cloud engineer" when what they actually needed was a backend engineer who is comfortable with AWS, or a full DevOps owner, or a one-time cost audit. You end up with someone excellent at Terraform modules sitting in sprint planning for a Node API they were never meant to write.

Which engagement model fits

In-house hire. Right when infrastructure is a living thing: multiple environments changing weekly, real compliance obligations, a genuine on-call rotation, or an EKS platform other engineers build on. The value of in-house is context accumulation. Someone who knows why the VPC is peered that way and why that Lambda has a 900 second timeout is worth a lot at 2am. The problem is that most teams do not have enough cloud work to fill a week, every week. A senior AWS engineer with four hours of real work per week will invent projects, and those projects usually involve migrating something that did not need migrating.

Freelancer. Good for bounded, well-specified work: a cost audit, a Terraform migration off ClickOps, a one-off EKS setup, a SOC 2 evidence push. Bad for anything that needs to survive the engagement. The structural risk is that a freelancer optimizes for a working handoff at the end date, not for a system your team can operate in year two. Also, freelancers are the highest-variance population here, and AWS is a field where a confident wrong answer looks exactly like a confident right answer for about five months.

Agency. Good when you want an outcome rather than a person: build the platform, hand it over documented, stay on for support. You get a team, so the Terraform person and the Kubernetes person and the security person can be different humans without you hiring three people. The trade-off is coordination cost and the risk that you are one client among many. Ask specifically who is on your account and what happens when they get pulled.

Staff augmentation. Our most common structure for this role at Digital Heroes, and the best fit for most teams searching this term. You get one or two engineers embedded in your standups, your repo, your Slack, working to your roadmap, but you are not carrying the hiring cost, the ramp risk or the bench when the work thins out. It fits teams who have enough AWS work for a person right now but are not certain they will in nine months, and teams who need to move in two weeks rather than three months.

Rates and what it really costs

These ranges reflect what we see in our own delivery work and in the market we compete in. Treat them as directional, because region and seniority move them more than anything else.

• Offshore and nearshore (India, Eastern Europe, LATAM): roughly $30 to $50 per hour for a mid-level engineer who can write Terraform and run a pipeline. Roughly $50 to $75 for a genuinely senior one who can design the account structure and own on-call.
• Onshore US and Western Europe: roughly $90 to $160 per hour contract, with specialists in EKS at scale, FinOps or regulated environments going higher.
• In-house US base salary: roughly $120k to $150k for mid-level, $150k to $190k for senior, higher in the Bay Area and New York and for platform engineering titles.

The salary number is the one that misleads people. In our own budgeting, benefits, payroll taxes, insurance, equipment and software push the real cost meaningfully above base, commonly in the range of a quarter to a third on top, and that is before you count anything else. Then add recruiting, which is either a contingency fee of a meaningful percentage of first-year salary or several weeks of your own engineering leadership's time doing screens. Then add ramp: an AWS engineer joining an existing environment is not productive on day one, because the first month is archaeology. Figure four to eight weeks before they are shipping changes to production with confidence. So a $160k senior is realistically a $210k to $230k first-year decision once you count everything, and you are committing to that before you know whether the workload sustains.

One number worth watching that is not a labor cost: the AWS bill itself. On most engagements where we do a cost pass, the savings from rightsizing, killing idle NAT gateways, moving steady-state compute to Savings Plans and cleaning up orphaned EBS and unused Elastic IPs pay for a meaningful slice of the engineering spend. If your monthly bill is above $10k and nobody has audited it in a year, the audit is usually the highest-ROI first project you can hand someone.

How to vet an AWS cloud engineer

Certifications tell you almost nothing. AWS Solutions Architect Professional is a real exam and a weak signal, because it tests recall of service capabilities, not judgment under production pressure. Here is what actually separates people.

The IAM question. Ask: "Walk me through how you would give a Lambda function read access to one S3 bucket." A weak answer attaches AmazonS3ReadOnlyAccess. A good answer writes a scoped inline or customer-managed policy on the function's execution role, restricted to that bucket ARN and its objects, and mentions that the trust policy matters as much as the permission policy. A very good answer asks whether the bucket is encrypted with a customer-managed KMS key, because then you also need kms:Decrypt and the key policy has to allow the role. That last detail is the one that separates people who have debugged real access denied errors from people who have read documentation.

The Terraform state question. Ask: "How do you handle Terraform state across environments, and what happens when two engineers apply at once?" You want remote state in S3 with DynamoDB state locking or S3 native locking, separate state per environment, and a clear opinion on workspaces versus directory-per-environment. Ask what they do when state drifts from reality, and listen for whether they reach for terraform import and targeted plans or whether they suggest deleting and recreating. Ask if they have ever had to surgically edit state. Anyone who has run Terraform seriously has a war story here. If they do not, they have run it on toys.

The networking question. Ask them to draw a VPC for a web app with a database. You are watching for public and private subnets across at least two availability zones, an internet gateway for public and a NAT gateway for private egress, security groups referencing other security groups rather than CIDR ranges, and the database in private subnets with no public accessibility. Then ask what the NAT gateway costs. If they have no idea, they have never owned a bill. Bonus signal: mentioning VPC endpoints for S3 and DynamoDB to avoid paying NAT data processing charges on traffic that never needed to leave the network.

The cost question. Ask: "The bill went up 40 percent last month. What do you do first?" Good answers go to Cost Explorer, group by service and then by tag or linked account, and look for the delta rather than the total. They mention that the answer is often data transfer or NAT processing rather than compute, because those are the line items people forget. They mention tagging discipline as the prerequisite that makes this answerable at all.

The failure question. "Tell me about a production incident in AWS that you caused." The specifics matter less than whether the story is real, whether they own it, and whether the fix was systemic. Someone who says a bad security group change cut off the app and the fix was to require plan review in CI is telling you how they think.

The take-home. Do not ask for a greenfield architecture diagram. Anyone can produce one. Instead give them a small, deliberately flawed Terraform repo, maybe 200 lines, with an over-permissive security group, hardcoded credentials, an unencrypted RDS instance, no state backend and a resource that will force replacement on the next apply. Ask them to review it and submit a plan for what they would change and in what order. Budget two hours and pay for it. What you learn is prioritization: do they lead with the credential leak and the open port, or do they lead with naming conventions? A strong candidate also tells you what they would not change yet, and why. If you would rather review a portfolio, ask to see a real Terraform module they wrote and walk through their variable design, and ask why they chose CDK over Terraform or vice versa on their last project. The reasoning is the artifact.

Red flags

• Console-first instincts. If they describe solving problems by "going into the console and changing", without immediately flagging that the change must go back into code, you are buying future archaeology. Better question: "What is in your environment right now that is not in code, and how did it get there?" Everyone has something. The good ones know exactly what and are embarrassed by it.
• Kubernetes as a default answer. Someone who reaches for EKS for a three-service app with 200 daily users is buying complexity you will pay for forever. Better question: "When would you use ECS Fargate over EKS, and when would you use neither?" A good engineer will happily put a small workload on Fargate or even a Lambda and tell you EKS is not worth its operational tax until you have real multi-team scale.
• No opinion on the bill. If you ask about cost and get "that is usually a finance conversation", pass. Better question: "What is the most expensive mistake you have seen in an AWS account?" Real engineers have a favorite: the forgotten GPU instance, the CloudWatch Logs group with infinite retention, the cross-AZ chatter in a chatty microservice mesh.
• Certifications carrying the resume. Five badges and no story about a 3am page. Better question: "Walk me through the last time an alarm woke you up. What fired, why, and what did you change afterward?" Cert-heavy candidates get vague fast here.
• Secrets handwaving. If access keys and .env files come up casually and Secrets Manager, Parameter Store or IAM roles for service accounts do not, that is a real gap. Better question: "How does an application on ECS get its database password, and how does it get rotated?" You want instance or task roles and a managed secret store, not a key pair in an environment variable.

When to hire this role at all, and how we staff it

Be honest about which problem you have. If your product is a monolith on a few servers and your infrastructure changes twice a year, you do not need an AWS cloud engineer. You need a good backend engineer who is not scared of Terraform, or one focused engagement to codify what exists and hand you a runbook. If your bill is the pain, that is a cost audit, which is a two to four week project, not a hire. If your problem is that deploys are scary and slow, that is a CI/CD and delivery problem, and a DevOps generalist serves you better than a cloud specialist. If you are pursuing SOC 2 or HIPAA, you want someone who has done AWS in a regulated environment specifically, which is a different and pricier person than a general cloud engineer.

You genuinely need this role when infrastructure has become a product other engineers consume: multiple teams deploying independently, a platform layer with its own roadmap, real availability commitments to customers, and a pager that has to be someone's job rather than everyone's guilt.

At Digital Heroes we usually staff this as an embedded engineer or a small pod working inside your repo and your standups, starting with a two week discovery: read the account, map what exists, produce a prioritized findings list covering security exposure, cost, and what is not in code. That discovery pays for itself often enough that we lead with it. From there most clients run one engineer continuously for the build phase and step down to a lighter support arrangement once the environment is stable and documented, which is exactly the shape of the work and exactly what a full-time hire cannot flex to. Everything we build is Terraform or CDK in your repository, under your AWS accounts, with your team on every pull request, so if you later hire in-house the handover is a git clone and a walkthrough, not a rescue.