Cloud Engineers Job Description Template (2026)

Cloud engineer job descriptions fail before a single candidate reads them, usually for one of two reasons. They either list every AWS, Azure, and GCP service ever invented as requirements, or they are so vague that they attract generalists who have touched cloud peripherally rather than engineers who have run production infrastructure under real constraints.

This template corrects both problems. It gives you a ready-to-customize structure that is platform-specific, honest about what the role actually involves, and optimized to attract candidates with production depth rather than certification breadth. Use the full template below directly or adapt it for your environment.

What Cloud Engineers Actually Do

Before writing requirements, clarify what your cloud engineer will actually own. The role varies significantly by company stage and infrastructure maturity, and requirements that do not reflect the real job lead to mismatches that surface two months into the placement.

At most companies, a cloud engineer owns some combination of: designing and maintaining the cloud account structure, writing and reviewing infrastructure as code, managing network topology (VPCs, subnets, peering, egress), implementing security controls (IAM policies, security groups, secrets management), optimizing cloud spend (Reserved Instances, Savings Plans, rightsizing), and operating the CI/CD infrastructure pipeline.

At companies with dedicated platform engineering or DevOps teams, the cloud engineer’s scope narrows to infrastructure provisioning and security, with separate teams owning CI/CD and developer experience. At smaller companies, the cloud engineer owns all of it. Specify which model applies to your organization before you write a single requirement.

Core Technical Requirements

Requirements should reflect what is actually required to be productive in your environment on day 60, not a wish list for a candidate who would replace your entire engineering team. Separate hard requirements from preferences, and list no more than 6-8 hard requirements.

Platform Expertise

List your primary cloud platform as a hard requirement with specifics. “3 to 5 years of AWS experience with production ownership of EKS, RDS, Lambda, and CloudFront” is a requirement. “Experience with AWS, Azure, or GCP” is not. If your environment is multi-cloud, list the primary platform and note that experience with the secondary is preferred, not required.

Infrastructure as Code

Name the specific IaC tool your team uses and the depth of experience required. “2+ years writing Terraform modules for production environments, including remote state management and module versioning” is specific. “Familiarity with IaC tools” attracts candidates who have run a tutorial. If you use CDK or Pulumi, say so. If your existing codebase is Terraform but you are considering CDK, note the primary requirement and the direction of travel.

Networking Fundamentals

Cloud engineers who cannot reason about networking cause expensive production incidents. Require demonstrated understanding of VPC design, subnet strategy, security group rules, NAT gateway placement, and cross-account peering. If your architecture involves Transit Gateway, Direct Connect, or PrivateLink, include those explicitly.

Compliance and Security

If your infrastructure touches regulated data, require relevant experience explicitly. “Experience operating infrastructure in a SOC 2 Type II environment, including audit log management, IAM policy review, and secrets rotation” is specific and filterable. Do not list HIPAA, SOC 2, PCI DSS, and FedRAMP as parallel requirements unless all four genuinely apply; requiring all four is implausible and will filter out strong candidates who meet the two that actually matter.

Nice-to-Have Skills

Separate nice-to-haves from requirements and keep the list short. Three to five preferences communicate genuine priority. Ten preferences read as additional requirements and suppress applications from strong candidates who do not tick every box.

Common genuine preferences for cloud engineering roles include: experience with GitOps tooling (ArgoCD, Flux), prior work with a FinOps framework or cloud cost allocation tagging strategy, exposure to service mesh architectures (Istio, Linkerd), container security scanning (Trivy, Snyk), or a relevant professional certification (AWS Solutions Architect Professional, Azure Administrator Associate, GCP Professional Cloud Architect).

Certifications belong in the preferred section, never as hard requirements, unless the role has a regulatory context where the certification is a contractual deliverable. In that case, state the specific certification and the timeline for achievement.

The Full JD Template

The template below is built for a senior cloud engineer role targeting a nearshore or remote hire. Customize the bracketed fields for your environment. Remove sections that do not apply rather than leaving them blank or generic.

Compensation Ranges

Publishing a compensation range in your cloud engineer JD increases qualified application volume and reduces time wasted on candidates with misaligned expectations. For nearshore cloud engineers hired through a staffing partner, the ranges below reflect 2026 all-in placement costs through Kore BPO:

These ranges cover salary, benefits administration, and account management support. There are no upfront search fees. All-in costs remain 40 to 60% below the equivalent US-based senior cloud engineer role.

Remote-Ready JD Considerations

A JD for a nearshore or remote cloud engineer requires a few additions that are not standard in US domestic postings. These additions signal to strong candidates that you have built distributed teams before and that the role is genuinely remote-first, not a domestic role with an optional WFH day.

Specify the timezone requirement clearly. “Full availability during US Central hours (9am-5pm CT, UTC-6)” is unambiguous. “US timezone overlap” is not. Costa Rica operates UTC-6 year-round without daylight saving time, which means Central Time engineers have full overlap with no seasonal shift and Eastern Time engineers are 1 hour ahead at most.

Describe your async communication infrastructure. Does your team use Slack, Linear, or Notion for async documentation? Do you have architecture decision records (ADRs) or a documented runbook library? A remote cloud engineer inheriting undocumented infrastructure is a risk for both sides; acknowledging your documentation maturity honestly in the JD attracts candidates who are comfortable with that state and can improve it.

State the onboarding structure. “First two weeks are infrastructure orientation, no production access for 10 business days” builds confidence in candidates who want to do their first work correctly rather than quickly. It also signals that your team has experienced the cost of rushing a cloud engineer into production-critical tasks before they have enough context.

Common JD Mistakes

Requiring all three major cloud platforms at the senior level. There are very few engineers who have senior-level depth on AWS, Azure, and GCP simultaneously. Engineers who list all three at depth are often overstating experience on two of them. Pick your primary platform and require depth there; note the secondary as preferred.

Using salary ranges that reflect 2021 market data. Cloud engineering compensation has shifted substantially over the past few years. Ranges that have not been updated suppress applications from candidates who are calibrated to current market rates and attract engineers who are unaware they are undervaluing themselves, which creates retention risk from the first month.

Listing the team structure but not the infrastructure state. Candidates evaluate your JD as much as you evaluate their resume. An honest description of the infrastructure state (greenfield build, managed migration, inherited legacy IaC debt) helps candidates self-select accurately and signals that you have thought carefully about the challenge you are asking them to take on.

Omitting the reporting line and team size. A cloud engineer embedded in a 3-person infrastructure team with a CTO reporting line operates very differently from one who is 1 of 12 in a platform engineering org reporting to a Director. Both are legitimate roles. Omitting this information creates expectations mismatches that surface in the first week.

Frequently Asked Questions