Cloud Engineer Job Description Template 2026

Cloud Engineer Job Description Template 2026

Last updated: April 25, 2026

A cloud engineer designs, deploys, and operates an organization’s cloud infrastructure across AWS, Azure, or Google Cloud, with U.S. base salaries running $115,000 to $155,000 for mid-level and $160,000 to $215,000 for senior roles in 2026. Below is a ready-to-adapt job description, a salary table sourced from five independent benchmarks, and the specific JD mistakes that screen the best cloud engineers out before you ever talk to them.

Robert Ardell, co-founder at KORE1. Twenty years in the room. I’ve watched companies hire technology talent through three platform shifts, and the cloud engineer role is one of the few where the gap between a good job description and a bad one shows up in the candidate pipeline within forty-eight hours. Strong JD, clean intake, signal in the first batch. Generic JD copied off LinkedIn, fifty applicants who all look the same and none of whom actually fit, with the hiring manager three weeks later asking the recruiting team to widen the search instead of fixing the description that the search was built around in the first place. Same role on paper. Different result entirely.

This template is built around the way the cloud engineer market actually works in 2026. AWS, Azure, and Google Cloud talent pools don’t overlap as much as most hiring managers expect, and the comp variance across them is substantial enough that pulling a single national average and posting that as the comp band is one of the more reliable ways to mis-price a senior search by ten or fifteen thousand dollars in either direction. Compensation varies by platform, by metro, and by whether the role lives inside platform engineering or under a developer team. The section at the end on what most postings get wrong is the part most other templates skip.

One disclosure up front. KORE1 places cloud engineers through our cloud engineer staffing practice, and we earn a fee when you hire through us. The framework below works whether you call us or not.

What Is a Cloud Engineer?

A cloud engineer owns the design, deployment, and ongoing operation of cloud infrastructure. Storage, compute, networking, identity, observability, cost. The systems that the application layer runs on, and the automation that keeps them running without somebody clicking through a console at midnight.

The role sits in the middle of three adjacent ones, and most JDs blur the lines. A DevOps engineer is closer to the application code, owning CI/CD pipelines and developer tooling. A site reliability engineer owns production reliability and incident response, often for a specific service. A cloud architect makes the platform-level design decisions and rarely writes Terraform anymore. The cloud engineer covers the ground between those three, with the specific mix depending on team structure.

Or, more bluntly. It’s the in-between role. Underdefined on purpose at most companies.

Three things shape the role more than the title:

• Which cloud. AWS, Azure, and Google Cloud are not interchangeable. The talent pools do not fully overlap, the certifications are different, and the hiring market behaves differently.
• Whether the engineer is building net-new infrastructure or maintaining existing infrastructure. New build is closer to architecture work. Maintenance is closer to platform engineering and cost optimization.
• Whether the role is supporting a single product team or running shared infrastructure for the whole company. Those are different jobs. Most JDs do not say which.

The version of this role that closes cleanly in four to six weeks is one that decides those three things at intake. The version that runs ninety days is one that left them ambiguous and then wondered why the candidate pool felt thin.

The Three Cloud Engineer Profiles

Most hiring managers think they need a cloud engineer. What they actually need is one of three different profiles, and the JD has to commit to one to attract the right candidates.

AWS-first infrastructure engineer. The largest pool. Comfortable with EC2, VPC design, IAM, EKS or ECS, CloudWatch, and at least one infrastructure-as-code tool. Usually has an AWS Solutions Architect Associate or higher. Sourcing is straightforward in any major U.S. metro. Pay range is the most predictable. Candidate flow on a clean JD runs forty to seventy applicants in the first two weeks.

Azure-focused enterprise engineer. Smaller pool, concentrated in Microsoft-aligned shops and Fortune 500 enterprises. Strong on Active Directory, Entra ID, and the Microsoft identity stack. Usually sits inside a hybrid environment that includes on-premises Windows Server and Office 365 alongside Azure. Comp runs ten to fifteen percent higher than AWS in most metros. Mentioning Bicep or ARM in the JD signals you actually know the stack.

Google Cloud platform engineer. The smallest pool, concentrated in data-heavy companies and a handful of metros with Google’s brand pull. Strong overlap with data engineering. BigQuery, GKE, Dataflow, and Looker are common. The candidate pool is fewer than half the size of the AWS pool in most U.S. cities. The closing process tends to take longer because the pool is concentrated.

Picking one of these at intake matters more than the bullet list. A JD that mentions all three platforms equally signals to candidates that you don’t know which one you actually use, and the strongest engineers self-select out the same week the posting goes live, not because they doubt their ability to learn a second cloud, but because a JD that can’t commit to a primary platform is usually attached to a team that can’t commit to a primary platform, and that’s a different problem than what the comp band is paying for.

Pick one. Commit.

Cloud Engineer Job Description Template

This template is structured for a mid-level to senior AWS-focused role. Swap the AWS-specific language for Azure or GCP if that is your stack. Adjust the experience years and certification list to match the seniority you are actually hiring.

Core Responsibilities in Depth

The bullet list above is the cover sheet. Here is what those bullets actually mean in production, because the interview process surfaces the difference fast.

Infrastructure design is the part most candidates either oversell or undersell. The strong ones can walk you through a recent VPC redesign, the constraints that drove it, and the two decisions they would make differently in hindsight. The weaker ones describe a reference architecture from a vendor blog. The interview question is not “draw a VPC.” It is “tell me about an infrastructure decision you made that turned out to be wrong, and how you found out.” Almost every senior cloud engineer has a real answer. Junior candidates rarely do.

Terraform sounds like a checkbox skill until you start asking how the candidate structures modules. Production Terraform shops fall into two camps: a flat root with shared modules, or a Terragrunt-style hierarchy with per-environment composition. Neither is wrong. But a candidate with a strong opinion about which one you should use, and why, tends to be the one who has actually owned a Terraform repo for more than a year. The candidate who says “we just used the AWS provider examples” has not.

Kubernetes in production is its own filter. EKS is straightforward to spin up and difficult to operate well. Real production experience shows up in three specific places: how the candidate handles upgrades, how they handle a misbehaving pod that takes down a node, and how they think about the security boundary between cluster components and the rest of the AWS account. The interview question is not “explain Kubernetes architecture.” It is “the last time a production EKS cluster gave you a real problem, what was it.” If they have to think for thirty seconds, they have not run one.

Cost discipline is the responsibility almost no JD describes well, and the one that drives the most pain in real environments. AWS bills grow faster than most companies expect, often by ten to twenty percent quarter over quarter without anyone making a deliberate decision about it, until the finance team flags it during the annual planning cycle and someone in engineering has to spend a quarter chasing down per-team cost attribution that nobody set up two years ago when the tagging strategy would have taken a week to enforce. A cloud engineer who can talk specifically about a Savings Plan strategy they implemented, a tagging scheme that survived a reorg, or a single workload they right-sized to save a real dollar amount, is worth the premium they cost. The ones who say “I am familiar with cost optimization tools” are reading the JD back to you.

Incident response is the part where the JD says “on-call rotation” and skips the substance. What you actually want to know in the interview: when did the candidate last own a production incident, what happened, what did they change afterward to prevent recurrence, and how did the postmortem go inside the team, including the parts that are awkward to talk about, like whether the team actually changed something durable as a result or whether the runbook update sat in a draft pull request for three weeks before being abandoned during the next sprint. Strong engineers describe a real incident in detail. Weaker ones describe their on-call schedule. Tell.

Cloud Engineer Salary in 2026

Cloud engineer compensation in 2026 varies more by cloud platform and metro than by years of experience. The table below pulls base salary medians from five independent sources, with the methodology and limitations called out so you can adjust to your market.

The variance across sources is the content. A 30K spread between Salary.com and Glassdoor on the same role is not unusual. Pulling a single number off one source and posting it as your range is how you end up off-market by 15K in either direction. Cheap to fix. Expensive to ignore.

By cloud platform, the rough rank order in 2026:

• Azure tends to pay highest, often by ten to fifteen percent over AWS in the same metro, driven by enterprise-heavy demand and a smaller talent pool.
• Google Cloud sits between AWS and Azure on average, with a wider spread because GCP roles concentrate in fewer companies and skew either heavily senior or heavily data-platform.
• AWS pays the most predictably, with the largest pool and the most reference data.
• Multi-cloud engineers (AWS plus one of Azure or GCP) command a roughly 18–25 percent premium per industry compensation reports.

For a current breakdown by metro and seniority across the broader IT comp landscape, the KORE1 cloud engineer salary guide breaks down 2026 base and total comp across AWS, Azure, and GCP by seniority. It is also worth pairing this template with the platform-specific guides if you have already settled on a cloud. The how to hire AWS cloud engineers guide goes deeper on AWS-specific intake and sourcing patterns, and the Azure cloud engineer hiring guide covers the enterprise-Azure side of the market.

Common Mistakes Hiring Managers Make in Cloud Engineer JDs

This is the part most templates leave out. Specific patterns we see week after week in postings that then run ninety days without a hire.

Listing every cloud platform as a requirement. “AWS, Azure, or GCP experience required.” Translation to a candidate: you do not actually know which one you use, or you have all three and the role is going to be a context-switching nightmare. Strong engineers self-select out. Pick one. Make the other two preferred, if at all.

Conflating cloud engineer with DevOps engineer. The JD says “cloud engineer” in the title and then lists Jenkins pipelines, GitHub Actions, and developer tooling for fifteen bullets. That is a DevOps role with a cloud title. Either rename the role or rewrite the responsibilities. Otherwise you are pulling from the wrong candidate pool.

Asking for ten years of cloud experience. AWS launched in 2006 but did not have meaningful enterprise traction until around 2012. A candidate with ten years of real production cloud experience is rare and usually a senior staff or principal engineer. If the JD asks for ten years and the comp is mid-level, the search will not close. We see this on roughly one in five intake calls.

Listing twenty-plus tools in the requirements section. “Terraform, CloudFormation, Pulumi, Ansible, Chef, Puppet, Kubernetes, Helm, ArgoCD, Flux, Jenkins, GitHub Actions, GitLab CI, Spinnaker, Datadog, New Relic, Splunk, ELK…” No engineer has used all of those in production, and the ones who claim to have are the ones you do not want. The right list is three to five tools the role actually uses, plus “comparable experience with similar tooling” for the rest.

No mention of on-call. If the role includes a production on-call rotation, the JD has to say so. Senior cloud engineers ask about on-call in the first conversation. A JD that hides it loses candidates at offer stage when they find out, which is the most expensive place to lose them. Don’t bury it.

Vague seniority. “Senior Cloud Engineer” with three years of experience required. Or “Cloud Engineer” with eight years. The internal calibration is off, and the comp will be off with it. Pick a level. The market knows the difference between a mid-level and a senior cloud engineer, and that gap is wide enough in cloud specifically that an engineer at one level applying for a posting calibrated to the other will read the comp band and the responsibility list, decide one of the two is wrong, and either pass on the role or apply with the wrong expectations and back out at offer stage. Either result is expensive.

No mention of the team or the platform’s stage. The strongest senior candidates want to know what they are walking into. A cloud engineering org that is two years into a Kubernetes migration is a different job than one running a five-year-old VM-based platform, and the engineer who’s looking for greenfield Kubernetes work is rarely the same engineer who wants to spend the next eighteen months stabilizing a legacy estate while a separate team builds the replacement. The JD that says nothing about either gets generic candidate flow. The JD that names the platform stage and the team’s current focus pulls candidates who actually want that work, and skips the ones who would have backed out at offer stage anyway once they saw the room.

How Many Years of Experience Do You Actually Need?

The years-of-experience field is one of the most miscalibrated parts of cloud engineering JDs. A rough framework that holds up across most of the searches we run:

• Junior cloud engineer: 1–3 years total infrastructure experience, often coming from a sysadmin or DevOps background. Comfortable with one cloud at a basic level. Can write Terraform with supervision but not yet design modules from scratch.
• Mid-level cloud engineer: 3–6 years total, with at least 2 years owning production cloud infrastructure. Can run an EKS cluster, design a VPC, debug an IAM problem, and pick up new services without hand-holding.
• Senior cloud engineer: 6–10 years total, 4+ years specifically in cloud. Has owned a production migration or a substantial redesign. Can mentor mid-level engineers and lead an incident response.
• Staff or principal: 10+ years, with cloud as a meaningful part of the last 5+. Sets architectural direction across multiple teams. Often has a specialty: cost, security, networking, or platform.

Most JDs ask for a year or two more than the role actually needs, and lose candidates who are exactly right for the work. Three years of focused AWS experience is often more useful than five years of intermittent multi-cloud touch. Focus beats tenure.

Common Questions Hiring Managers Ask

What is the difference between a cloud engineer and a DevOps engineer?

A cloud engineer owns the infrastructure layer. A DevOps engineer owns the developer-facing pipeline that runs on top of it. The two roles overlap in tools but split on responsibility.

Cloud engineers spend most of their time on the platform: networking, identity, container orchestration, observability, cost, security boundaries. DevOps engineers spend most of their time on the developer experience: pipelines, deployment patterns, internal developer platforms, the boundary between code and production. In a small team, one person can do both, and often a single hire will rotate between cloud-engineer work in the morning and DevOps work in the afternoon depending on which fire is currently the loudest, which is fine for a year and gets unsustainable in year two as the platform grows and the demands on each side stop fitting in one calendar. In any team larger than fifteen engineers, the roles tend to split. A JD that combines them under one title is usually describing what the team needs in year one, not what they will need in year two.

Should the JD specify AWS, Azure, or GCP?

Yes. Pick one. Mentioning all three signals to candidates that you do not know which one you actually use, and the strongest engineers will not apply.

If you genuinely use multiple clouds in production, name the primary one and call out which secondary cloud the role will touch. “Primary AWS, with some Azure exposure for our DR environment” is a real description. “AWS, Azure, or GCP experience required” is a red flag that the role is not well-defined yet.

How long does it take to fill a cloud engineer role?

Four to eight weeks for a clean AWS search. Six to ten for Azure or GCP. Senior roles trend toward the longer end, junior roles toward the shorter.

The variable that shifts timeline more than anything else is intake clarity. A role with a defined platform, a clear seniority target, and a specific scope closes faster than a role with three platforms and a comp band that does not match the experience requirement. Most of the searches that drag past 90 days do so because the JD never committed to one of those decisions.

Do I need an AWS-certified candidate?

A certification is a useful filter, not a guarantee. Solutions Architect Associate is the most common floor for senior AWS roles. Professional-level certs signal depth.

The certification matters less than the production track record. We have placed senior cloud engineers without certifications who are stronger than candidates with three. The cert is a screening tool when the resume is thin. Once a candidate has five years of AWS in production, the cert is a tiebreaker, not a requirement.

What is a fair starting comp band for a senior cloud engineer in 2026?

$160,000 to $215,000 base in most U.S. metros, with the higher end concentrated in tech-heavy markets and Azure-leaning enterprises. Total comp with bonus and equity often exceeds $250,000.

The variance is wide because cloud platform, metro, and company type all move the number. A senior AWS engineer in a Series C startup in Denver will land at a different number than a senior Azure engineer in a Fortune 100 in New York, even with the same resume. Pulling two or three salary aggregator data points before posting is the cheapest research the hiring manager can do.

Should I list specific tools or keep the JD generic?

Specific. Generic JDs attract generic candidates. Naming Terraform, EKS, and your observability stack pulls applicants who have used those tools in production and filters out the ones who haven’t.

The exception is the preferred section, where listing alternatives is fine. “Terraform required, comparable experience with Pulumi or CDK considered” is a clean way to handle it. Listing every IaC tool in the requirements section signals that you do not have one and you are hoping the candidate will pick.

How does this template differ for a contract or contract-to-hire role?

The technical bullets stay the same. The intro changes to call out the engagement model, the start date, and whether there is a conversion path. Contract roles attract different candidates, and the JD has to be honest about that.

Contract cloud engineers are typically in the senior to staff range, hourly, with a different motivation profile than full-time hires. The strongest contractors look for short-cycle, high-impact work. A JD that hides the contract nature until offer stage will lose them. KORE1’s contract staffing practice runs the cloud engineer contract market across most U.S. metros, and the intake conversation always starts with whether the role is genuinely contract or whether the manager is hoping to convert.

Where to Go From Here

If you are running a cloud engineer search and the JD is not pulling the candidate flow you expected, the fastest fix is usually narrowing the platform, tightening the seniority band, and adding two specific sentences about what the role actually owns day one. Most of the rewrites we do at intake are exactly that.

If you would like a second opinion on a cloud engineer JD before posting it, or you are running a search that has stalled, reach out to our team. We work across thirty-plus U.S. metros and have a recruiter on the cloud desk who has likely seen the version of the role you are trying to hire for in the last quarter.