How to Become a Cloud Security Engineer: What 183 Open Postings Ask For

The road into cloud security as hiring teams write it down: 183 open postings read word for word, with the clouds, tools, years, certifications and salaries they name.

A cloud security engineer keeps an organization's workloads on AWS, Azure or Google Cloud safe by owning the half of the stack the provider leaves to the customer: who and what may call which API, how accounts and networks are fenced off, what the infrastructure code is allowed to create, how containers run, and how an intrusion is spotted and contained when it happens anyway. The realistic way in is sideways from a job that already runs cloud infrastructure (DevOps, site reliability, platform or systems engineering), or from a security seat that already watches cloud logs, rather than straight from a course. The postings say so plainly. Among 183 cloud security postings whose every word this board went through on 12 November 2026, only 7 were internships or associate seats, five years was the middle request wherever a minimum was given, and AWS turned up in 83% of them, Kubernetes in 77%.

How the sample was drawn. CyberJobs.cc reads the careers systems of about 300 employers every hour, and its "cloud security" specialty held only 76 roles in that read. That count understates the field, because much cloud security work is posted as security engineering, infrastructure security, platform security, product security or detection. So the sample has two parts. The first is every open posting whose title names cloud work (cloud, AWS, Azure, GCP, Google Cloud, Kubernetes or containers): 93 titles, of which 5 were set aside after reading because the word named a product or an operations job rather than security of a cloud (a database reliability engineer, an engineer for a firewall appliance's container runtime, a developer of cloud services for connected cars, an internship applying AI to cloud operations and the manager of a code security product team), leaving 88. The second is every other posting whose own duties make securing, attacking or watching cloud infrastructure the center of the job. Those were found by screening all 2,150 open postings for the density of cloud terms in their duties and requirements, then reading each flagged posting and keeping the 95 whose work is mainly cloud accounts, cloud identity, Kubernetes, infrastructure code or cloud detection. Together that is 183 postings from 94 employers, read from the board's full job feed. Unless a sentence gives a different base, read each count below as a share of that 183. Pay comes only from ranges employers printed. Figures the board can recount live are written so that they refresh when you load the page: right now the cloud security specialty lists 76 open roles, 14 of them remote.

Contents

1. What the work is: securing the customer's half of the cloud
2. Four kinds of cloud security job, and the titles they use
3. Which clouds and tools the postings name
4. The ladder: levels, years and the few seats for beginners
5. A learning order where each skill rests on the last
6. Certifications, ranked by how often postings name them
7. Starting points: which job you move from
8. What cloud security engineers are paid
9. AI workloads and GPU clouds: the newest part of the job
10. A sequence for the next eighteen months
11. Common questions about becoming a cloud security engineer

1. What the work is: securing the customer's half of the cloud

Start with what changes when a company moves into a public cloud. The servers, cables, cooling and hypervisors stop being its problem. What remains is everything expressed as configuration: accounts, roles, keys, network rules, storage settings, container images and the code that creates all of them. Every one of those objects is created by an API call, often by a pipeline rather than a person, and many of them are reachable from the internet the moment they exist. That has two consequences that explain the whole job. A single mistake can be copied into hundreds of resources in minutes, because the same template builds them all. And the attacker no longer needs to break into a building or a server first; a leaked credential or a storage bucket set to public is enough.

A cloud security engineer therefore spends less time on firewalls and endpoints than an on-premises engineer did, and more on three things: making the safe configuration the default, catching the unsafe one quickly when it appears anyway, and noticing when a valid identity is used for something it should never do. The parts of the job below follow roughly the order a new engineer meets them.

The shared responsibility line

Every major provider publishes a split of duties, and the job lives on the customer's side of it. AWS describes its own share as security "of" the cloud (the hardware, software, networking and facilities that run its services) and the customer's share as security "in" the cloud: the guest operating system on a virtual machine, the applications installed on it, the configuration of the security group that acts as its firewall, the data and its encryption, and the permissions granted through IAM. How much falls on the customer depends on the service. On a virtual machine the customer handles nearly everything above the hypervisor; on a managed service such as S3 the provider runs the platform, but the customer still owns the data and who may touch it - AWS shared responsibility model.

Microsoft names four duties the customer keeps whatever the deployment type, from on-premises servers to software as a service: data, endpoints, accounts and access management, the last covering role-based access control, multifactor authentication and conditional access - Microsoft Learn, updated 24 August 2026. That list is most of a cloud security engineer's job description. The provider will not stop anyone from granting a contractor administrator rights, opening a storage account or skipping MFA on a service account; those are configuration choices, and configuration is yours.

Identity and permissions

In a cloud account the real perimeter is the permission policy, because an attacker holding a valid key simply calls the API like any engineer. Of the 183 postings, 86 (47%) named IAM or identity and access management outright, 42 asked for least privilege by name, 29 named workload identity (the identities machines and services use to call each other), and 13 named organization-level guardrails such as AWS service control policies. Ridgeline's principal infrastructure security engineer posting asks for company-wide guardrails built from service control policies and IAM permission boundaries; ClickUp wants people, pipelines and services moved toward least privilege and just-in-time access.

The clearest lesson of why this matters comes from an incident that needed no exploit at all. In 2024 a financially motivated group Mandiant tracks as UNC5537 logged into the data platform accounts of many companies with stolen usernames and passwords, and Mandiant and Snowflake notified about 165 potentially exposed organizations. Mandiant named three factors behind the intrusions: the affected accounts had no multifactor authentication, credentials taken by infostealer malware were still valid years after they were stolen because nobody had rotated them, and the accounts had no network allow lists restricting where logins could come from. At least 79.7% of the accounts the group used had prior credential exposure - Mandiant, 10 June 2024. None of those three gaps is a software bug. Each is an identity setting that a cloud security engineer exists to enforce across every account, not just the ones somebody remembered.

Posture management

Posture management is the continuous inventory of what exists in the cloud and how it is configured, measured against a standard. Its tools carry acronyms: CSPM for configuration checks, CWPP for workload protection, CIEM for permissions, DSPM for sensitive data, and CNAPP for platforms that bundle them. In the sample, 55 postings (30%) named CSPM or CNAPP, 18 named workload protection and 7 named CIEM.

The standard being compared against is often a CIS Benchmark. The Center for Internet Security publishes consensus configuration guides for more than 25 vendor product families, including foundations benchmarks for each major cloud (AWS Foundations version 7.1.0, Microsoft Azure Foundations 7.0.0, Google Cloud Platform Foundation 5.0.1 at the time of reading) and a Kubernetes benchmark with variants for Amazon EKS, Azure AKS, Google GKE, Red Hat OpenShift and Oracle OKE - CIS. Twenty postings named CIS. Snyk's senior product security engineer posting, for one, asks for infrastructure to be benchmarked against the CIS Google Cloud Foundation Benchmark.

Running a posture tool is the easy part. The skilled part is deciding which of the thousands of findings matter in your environment, getting them fixed by the team that owns the resource, and then removing the cause so the same finding does not return next week. Coupa's two senior security engineer postings describe that last step directly: write auto-remediation for cloud misconfiguration and drift so that common findings close without a ticket ever being routed by hand.

Reviewing infrastructure as code

Most cloud resources in a mature company are created from code (Terraform, CloudFormation, Pulumi, Bicep or similar) that passes through a pull request and a pipeline before it touches the account. That gives a security engineer a much better place to intervene than the running account: the change can be reviewed, tested and blocked before the mistake exists. Infrastructure as code appeared in 112 postings (61%), Terraform by name in 80 (44%), CloudFormation in 25, and Pulumi in only 2.

Policy as code is the scaled version of review. Instead of reading every pull request, the engineer writes rules (in Open Policy Agent's Rego, in admission controllers such as Gatekeeper, or in scanners that read Terraform plans) that fail a build when a change opens a database to the internet or grants a wildcard permission. Thirty-nine postings named policy as code or one of its tools. Coupa wants these guardrails wired into CI/CD "as pre-merge and pre-deploy gates rather than after the fact reviews", and Veeam's security engineer III posting asks that anything fixed once land in the modules and pipelines so it stays fixed everywhere. A rule that blocks too much gets switched off by the teams it annoys, so precise, well-explained rules are a craft of their own.

Kubernetes and containers

Kubernetes was the single most named technology in the sample after AWS: 141 postings (77%) named it or one of the managed versions (EKS, GKE, AKS, OpenShift), and 117 (64%) named containers or a container runtime. That is because a large share of modern cloud workloads run as containers on a cluster, and a cluster is a small cloud of its own inside the cloud, with its own identities (service accounts), its own permission system (RBAC), its own network rules and its own API that attackers target.

The work on a cluster has a recognizable shape. Images are scanned and signed before they may run. Every pod is measured against one of three Pod Security Standards, which run from Privileged, a deliberately open profile that permits known escalations, through Baseline to Restricted, the one that follows "current Pod hardening best practices" - Kubernetes documentation. Admission controllers enforce those rules, network policies limit which pods may talk, and runtime tools watch for a container doing what its image never should. MongoDB's three infrastructure security postings bundle all of it into one duty: RBAC, network policies, admission controls with Gatekeeper and runtime threat detection across several clouds. Service meshes (20 postings) and eBPF tooling (10) appear at the advanced end.

Detection in the cloud

Prevention never covers everything, so cloud security teams also watch. The most important log is the control plane, the record of every API call in the account (CloudTrail on AWS, activity and audit logs on Azure and Google Cloud), joined with identity provider sign-ins, Kubernetes audit logs and network flow logs. Native detection services sit on top (GuardDuty was named in 17 postings, Security Hub in 11, Microsoft Defender for Cloud in 6, Google's Security Command Center in 4), and 48 postings (26%) named a SIEM.

The threats have been shifting. Google Cloud's threat intelligence found that in the second half of 2025, exploitation of software flaws became the main way into the Google Cloud environments it investigated, at 44.5% of intrusions, ahead of weak or missing credentials at 27% - BleepingComputer, 9 March 2026. The same report described exploitation arriving within days of disclosure, with cryptocurrency miners deployed about 48 hours after one, while identity compromise still underpinned most intrusions into cloud and software-as-a-service environments - Help Net Security, 11 March 2026. A detection engineer therefore runs two jobs at once: watching identities for misuse, and knowing fast which exposed workloads run a component that just became exploitable. Saviynt's detection posting asks for that blend across AWS, Azure and Google Cloud.

Incident response in the cloud

Responding to a cloud intrusion differs from responding on a laptop fleet. Evidence lives in API logs and snapshots, a compromised machine may already have been replaced by autoscaling, and the first containment step is usually revoking credentials and sessions. An attacker with a valid role can create keys, users or compute in regions nobody watches, so responders must know the account structure well enough to trace everything an identity touched. Incident response or forensics appeared in 55 postings (30%), and 21 mentioned on-call duty. Ridgeline's staff infrastructure security engineer leads high-impact cloud incidents as technical lead or incident commander; at vendors the work is done for clients, as in Wiz's incident responder posting and CrowdStrike's cloud incident response consultant.

2. Four kinds of cloud security job, and the titles they use

The search phrase is "cloud security engineer", but the 183 postings describe four distinct jobs, and the title alone rarely tells you which one you are reading.

The in-house seat is what most people mean by the phrase, and it is two thirds of the sample. Product engineering at a vendor is software engineering first: Illumio alone had seven open "cloud security" or "container security" engineering roles, all building its products. Research seats cluster at a few vendors, Wiz most of all with seven. Customer-facing seats include consultancies such as GuidePoint Security, support engineers at SentinelOne and Palo Alto Networks, field architects at data platforms and a CrowdStrike instructor.

The titles hide a lot of this work. Just 43 of the 183 had a title putting cloud, Kubernetes or containers next to an engineering or architecture role (cloud security engineer, security engineer for cloud, cloud security architect, cloud detection engineer and their variants). Another 21 said infrastructure security, 9 said platform security and 5 said DevSecOps. Forty-three carried a general security title (security engineer, product security engineer, incident responder and the like) with no hint of cloud at all, even though their duties centered on cloud infrastructure. And none of the 95 postings found through their text had the word cloud in the title. If you only search for the phrase you will miss more than half of the jobs that fit you. The board's cloud security engineer title page lists the titled ones, and the specialty's own list sits under cloud security roles; search the infrastructure and platform security titles as well.

By the board's employer groups, the 183 postings came from security software companies (61), software and internet companies (44), cloud, data and infrastructure companies (35), banks, payment and crypto firms (17), security consultancies (11), AI labs (10) and defense and space companies (5). The cloud and data companies page lists every security role at the providers and data platforms themselves, where some of the deepest cloud work sits because their product is the cloud.

3. Which clouds and tools the postings name

A count of what employers write into their requirements is the closest thing there is to a market-wide syllabus. Each figure below counts a posting once if its title or text names the item, whether as a requirement, a preference or part of the stack the team runs.

AWS is the default, and multi-cloud is common. Five postings in six named AWS (151, or 83%); Google Cloud followed with 116 (63%) and Azure with 105 (57%). Half the sample (92 postings) named all three, usually as "experience with AWS, Azure or GCP", which is less a demand to master three platforms than a signal that depth in one transfers. The pairs tell the real story: 24 postings named AWS alone and 23 named AWS with Google Cloud, against only one posting naming Azure alone and one naming Google Cloud alone. Of the 153 postings that named any of the three, 151 included AWS. Thirty postings named none of the big three. Seventeen of those came from cloud providers and AI labs securing platforms of their own ( IONOS, Crusoe, Firmus, Nscale, Vultr, xAI, Anthropic, Mistral AI and others), and most of the rest were product, research and support roles at security vendors. If the employers you want run on Microsoft, Azure is the right first cloud; for everyone else it makes a strong second.

Cloud knowledge is not confined to these seats. Across the whole board, 829 of 2,150 open security postings (39%) mentioned AWS, Azure or Google Cloud, and so did 676 (34%) of the 1,967 that fell outside this sample.

Code is not optional. Nearly two thirds of the sample wanted Python (117 postings, 64%) and 76 (42%) wanted Go; 124 asked for at least one of them and 69 for both. Bash or shell scripting came up in 37, TypeScript or JavaScript in 24, C or C++ in 22, Java in 21, Rust in 16 and PowerShell in 15. The strength of Go is specific to this field: Kubernetes, Terraform and most cloud-native tooling are written in it, so a security engineer who writes admission controllers, operators or internal services meets it constantly. Python remains the language of automation, glue and analysis.

Categories matter more than brands. Specific commercial platforms were named sparingly. Leaving out Wiz's own postings, 19 of the other 173 named Wiz; Orca came up in 7, Lacework in 4, and Prisma Cloud in 3 of the 176 postings not written by Palo Alto Networks. The providers' native services were named about as often: GuidePoint Security's associate cloud security engineer posting lists IAM policies, CloudTrail, GuardDuty, Security Hub and AWS Config as what a new hire will configure. Employers want someone who knows what a posture platform does and how to act on its findings; any one product can be learned on the job.

Frameworks are present but secondary. ISO 27001 appeared in 31 postings, SOC 2 in 25, CIS in 20, FedRAMP in 16, MITRE ATT&CK in 14, PCI DSS in 13, and NIST in some form in 37 (SP 800-53 by number in only 6). Seven named the newer AI governance frameworks, ISO/IEC 42001 or the NIST AI Risk Management Framework. They matter most at companies selling to regulated customers or the US government, where an engineer must produce evidence that a control works; Coupa's associate posting has a beginner gathering technical evidence for SOC 2, ISO 27001, PCI DSS and FedRAMP audits.

Smaller signals worth knowing. Threat modeling appeared in 61 postings (33%), and it is how a senior engineer decides what to protect first. Secrets management came up in 37, zero trust in 33, serverless or Lambda in 19 and GitHub Actions in 16. Linux by name appeared in 48, which understates it, since nearly every Kubernetes posting assumes it.

4. The ladder: levels, years and the few seats for beginners

Cloud security, as employers post it, is a specialty people move into after they have run infrastructure, not one they start in. The level words in the 183 titles show the shape.

Two things stand out. Titles without a level word are not junior: when they state a number, the middle request is five years, the same as senior titles. And the jump that matters is from senior to staff and principal, where the middle request rises to eight years and the work shifts from owning controls to owning direction. Ridgeline's principal posting asks for a multi-year cloud security architecture vision and the security invariants that govern engineering decisions across every product line; Nscale's senior staff platform security engineer wants twelve or more years and deep reviews of an entire infrastructure-as-a-service platform, one service at a time.

Where years were stated (131 postings), three or fewer was enough in just 15, while 110 wanted at least five and 41 wanted at least eight. Many count adjacent experience: iCapital's DevSecOps platform engineer asks for six years of DevOps or site reliability work with four on AWS, and Klaviyo's infrastructure security posting asks for six years building and operating cloud-native distributed systems, not six years in security. For a career changer that is the most useful fact here: the years are mostly infrastructure years.

The seven entry seats, by name. They are worth reading closely because they show what a first cloud security job looks like when it exists.

• Coupa's associate security engineer (remote, India) asked for zero to two years in security, cloud, DevOps, IT or software engineering, counting internships, research and personal lab projects. It wanted foundational knowledge of cloud IAM, networking and common misconfigurations, scripting in Python, Bash or JavaScript, and listed Security+, ISC2's entry certificate, the AWS Cloud Practitioner or a cloud security certification as a plus.
• GuidePoint Security's associate cloud security engineer (remote, anywhere in the US) asked for one year of hands-on AWS experience, again counting internships, labs and projects, and required the AWS Certified Cloud Practitioner. The work is consulting: assessments, documentation and configuring AWS security services for clients under supervision.
• Tanium's cloud security intern (Durham, North Carolina, hybrid) is for bachelor's students graduating in late 2027 or spring 2028, with a 3.5 grade point average required and some AWS experience.
• Brain Co.'s two security engineering internships (remote in the US) include securing Kubernetes workloads, contributing to Terraform security baselines and finding misconfigurations across AWS, Google Cloud or Azure.
• Sezzle's two security infrastructure internships (remote in Latin America) cover security controls across AWS and Kubernetes, vulnerability triage and SIEM alerts.

Five of the seven were remote. For a beginner's seat in any specialty, check the board's internships and entry-level openings, recounted every hour.

Degrees, clearances and location. Fifty-four postings mentioned a degree, and 36 of those also offered an equivalent-experience path in the same text. Only three required a US government clearance: Second Front (Secret), Trace3 (Secret) and one GuidePoint Security cloud engineer seat (TS/SCI with a polygraph). Fifty-one postings (28%) were fully remote, more than the 18% the board's narrower cloud specialty showed on 11 November, because in-house seats (40 of 125 remote) pull the share up while none of the 18 product engineering roles at vendors was remote. By country, 71 named the United States, 20 India and 18 Israel, where security vendors such as Wiz, Palo Alto Networks and Tenable had cloud seats open, and 41 were open across several countries or named no single one. The remote cloud security page shows today's remote openings and the countries each accepts.

5. A learning order where each skill rests on the last

The order matters because each layer is the vocabulary for the next. Someone who learns a posture tool before IAM evaluation learns to click buttons; someone who learns IAM before networking cannot tell why a harmless-looking role reached a database.

Step 1: networking, the way a cloud implements it

Fifty-seven percent of postings named networking concepts: virtual private clouds, subnets, security groups, segmentation, DNS, private connectivity. Cloud networks are software, but they still follow TCP/IP, routing and DNS, and most cloud attack paths cross a network boundary somewhere. Learn how traffic enters and leaves a VPC, what a security group allows compared with a network ACL, and how private endpoints keep traffic off the internet. Practise by building a three-tier network in a personal account and proving which paths are open.

Step 2: Linux and how compute actually runs

Containers are Linux processes wrapped in namespaces and control groups, and the virtual machines under them are mostly Linux too. Forty-eight postings named Linux directly, and two roles the board filed under cloud security were pure Linux and kernel security work at a GPU cloud (Crusoe's senior staff Linux security engineer and staff kernel security engineer). Be comfortable with processes, permissions, logs and system calls before Kubernetes security.

Step 3: one cloud, learned deeply

Pick one platform and go further than an exam syllabus. On AWS that means how an organization of accounts is structured, how roles are assumed across accounts, how a request is evaluated against identity policies, resource policies, permission boundaries and service control policies, what CloudTrail records and misses, and how encryption keys are scoped. Interviewers probe depth in one platform; postings list breadth across three. With 151 of 183 postings naming AWS, it is the efficient first choice unless your target employers run on Azure.

Step 4: identity, as the center of everything

Treat identity as its own subject. Learn federation (how a corporate identity provider signs people into cloud accounts), human versus machine identities, short-lived credentials, and how privilege escalation works when a role can edit its own policy or hand a stronger role to a service. Workload identity, named in 29 postings, is where the field is heading: services proving who they are with short-lived tokens instead of stored keys. A good exercise is to give a lab role too many permissions and write down every path from it to administrator.

Step 5: infrastructure as code and policy as code

Learn Terraform well enough to write a reusable module, with variables, state, plans and a pipeline that applies them. Then review it as a security engineer would, spotting the open security group, the unencrypted bucket, the wildcard permission. Finally, write the pipeline rule that catches each of those and explains itself when it fails. Write, review, enforce: that is what the 112 infrastructure-as-code postings are asking for.

Step 6: from scripts to software

Automation starts as Python scripts that call provider APIs and ends as services other teams depend on. Learn Python that pages through API results, handles errors and rate limits, and emits output another program can read; then enough Go to read Kubernetes and Terraform provider code and write a small admission webhook. Senior postings increasingly read like software engineering roles with a security specialty: OpenAI's infrastructure security roles ask for strong engineering in Python, Go, Rust or C and C++ and a record of shipping production systems.

Step 7: containers and Kubernetes

With Linux and identity in place, Kubernetes becomes readable: RBAC is another permission system, service accounts another machine identity, network policies another firewall, the API server another control plane to log. Build a cluster, break it (a pod running as root with the host filesystem mounted is the classic first lesson), then fix it with Pod Security Standards, admission policies and network policies.

Step 8: detection and response in the cloud

Last, learn to see attacks in cloud logs. Generate suspicious activity in a lab (a key used from a new location, an unusual chain of assumed roles, a storage policy made public), write the detection that catches it, then practise the response: revoke the credentials, trace everything the identity touched, write a short timeline. People from a SOC have the advantage here; people from infrastructure usually have the gap.

The thread through all of them: threat modeling and writing

Threat modeling (named in 61 postings) is the habit of asking, for any system, what an attacker wants, how they would get it and which control stops each step; it is how engineers prioritize when findings outnumber hours. Writing is how anything gets fixed, because another team does almost every remediation. A review comment that explains the risk in that team's terms gets acted on; a scanner screenshot does not.

6. Certifications, ranked by how often postings name them

Certifications are a weak filter in this specialty. Fifty-four of the 183 postings (30%) named at least one, and only five made one a hard requirement: GuidePoint Security's associate seat (AWS Cloud Practitioner), Agoda's two Kubernetes-heavy security engineer postings (the CKA and CKS), Trace3's cleared DevSecOps cloud engineer (Security+ under the Defense Department's IAT Level II rule, plus an AWS associate-level certification or an equivalent) and Second Front's systems security engineer (a Defense Department 8140 baseline certification such as the CISSP, held or earned within 90 days). Everywhere else they sit under "preferred", "a plus" or "such as".

The CISM, GIAC and OSCP rules follow the board's own certification records; the certifications page shows how many open postings in every specialty name each one today.

The AZ-500 detail matters. Eleven open postings still asked for the Azure Security Engineer Associate, but Microsoft retired it on 31 August 2026. Its replacement is the Cloud and AI Security Engineer Associate, earned through exam SC-500, which Microsoft described as expanding the role to cover the protection of cloud and AI models - Microsoft Tech Community, 3 March 2026. It covers identity, access and governance; storage, databases and networking; compute; and security posture, in a 120-minute exam - Microsoft Learn, updated 25 September 2026. No posting in the sample named SC-500 yet, so a holder should add a few words saying it replaced AZ-500, or a recruiter matching keywords may miss it.

What the ranking means. The two most named credentials are a generalist one (the CISSP) and a platform one (the AWS Security Specialty). The CISSP leans toward seniority and client work: 23 of its 30 mentions came from senior titles or above, and 8 from consultancies, field and support roles, while its experience rule keeps it out of reach early. The AWS Security Specialty maps most directly onto the daily work of most postings, 23 of its 27 mentions being in-house seats, and AWS itself recommends two years of hands-on AWS security before sitting it. The CKS is the only exam in the list performed on a live system, and its domain weights (supply chain security, microservice vulnerabilities and runtime security at 20% each) read like a summary of section 1.

A sensible order. If you are new to cloud entirely, sit a foundational certificate only when a target posting requires it, as GuidePoint's did. Otherwise build and break things in a real account for several months, then sit the security certification of the cloud you chose, when the exam will confirm what you can already do. Add the CKS if your targets run Kubernetes at scale, and leave the CCSP and CISSP until you are aiming at architect, consulting or government seats and have the years they require. The board's CISSP and CCSP comparison sets the two side by side in today's postings.

7. Starting points: which job you move from

Most cloud security engineers arrive from a neighboring job, and the postings are quietly written for them. Where you come from decides what you already have and what you must add.

From cloud, DevOps, site reliability or platform engineering

This is the main road, and the postings make room for it. MongoDB titled three of its infrastructure security seats as site reliability roles; Smartsheet, Tekion, Veeam, iCapital and Gong posted DevSecOps roles that are cloud security in all but name; Okta advertised a staff site reliability engineer for security on Google Cloud. If you already write Terraform, run clusters and carry a pager, you have three of the hardest skills on the list. What you add is the attacker's view: how IAM privilege escalation works, what a malicious pipeline change looks like, how to read CloudTrail for misuse rather than debugging. The move is often internal: own the security findings for your team's accounts, build one guardrail as code that other teams adopt, and join the next incident review. A few months of that beats any certificate on an application.

From running servers and networks

Administrators bring networking and operating systems, steps 1 and 2 of the skill order, and often identity work in a directory service. The gap is code and the cloud itself. xAI's bare-metal and platform infrastructure security engineer sits right on this boundary, covering hybrid connectivity between data centers and clouds and identity across Active Directory and cloud IAM. The fastest path is to move workloads you run into a cloud account at work, automate them as code, then take on their security.

From a SOC or incident response team

Analysts bring detection instincts and incident discipline, which many infrastructure engineers lack. The cloud detection seats are the natural bridge: ID.me's staff cloud detection and response engineer, Saviynt's detection engineer focused on cloud techniques, Second Front's lead SOC engineer who builds detection logic across AWS, Kubernetes and identity and treats detections as code. The gap is building: learning Terraform, Kubernetes and enough Python to automate response. Not in a SOC yet? Our route into SOC analyst work is the earlier step, and many of the alerts it walks through already come from cloud logs.

From application security or software engineering

Developers and product security engineers bring code, which senior postings ask for most insistently. Product security with a cloud core is common in the sample: Snyk's senior product security engineer threat-models its infrastructure across Google Cloud and AWS and uses AI coding agents to draft the Terraform, Kubernetes and pipeline changes that close the gaps; Chainguard's two product security postings harden container images, cluster configurations and cloud IAM; Cribl's principal product security engineer serves as its principal cloud security authority. The 18 product engineering roles at vendors are software jobs first, so a strong developer can enter there and learn the domain while building the tools. Our overview of application security work maps that neighboring field.

Straight from school or university

The direct route exists but is narrow: seven entry seats in a sample of 183, and the two associate roles still asked for up to a year of hands-on cloud work counted from internships and labs. The realistic student path is an internship in cloud security, infrastructure or site reliability, then a first job in cloud or platform engineering, with security added on the job. The strongest student applications show a working project: an account built entirely from code, with guardrails, logging and a detection or two, published with a write-up of what was attacked and how it was caught.

From government or cleared work

Only three of 183 postings required a clearance, so cloud security is mostly a commercial field. Where cleared seats exist they ask for rare combinations: Second Front, whose engineer owns the security architecture of a platform that hosts applications through Defense Department authorization, wanted a Secret clearance, an 8140 baseline certification and knowledge of federal cloud requirements; GuidePoint Security's cleared cloud security engineer wanted TS/SCI with a polygraph. FedRAMP (16 postings) and NIST SP 800-53 knowledge carry over to commercial companies selling to the government. Seats that need a clearance are gathered on the board's cleared security jobs list.

Proof that replaces the years

Whichever door you use, a hiring manager for this job wants to see that you have built and secured something real. A public repository with a Terraform module that creates a locked-down account baseline, a policy-as-code rule set with tests, a short write-up of an IAM escalation path you found in your own lab and the detection that catches it, and a threat model of a small system: four artifacts like those answer most of what an interview will probe. To turn those artifacts into résumé lines, see writing a cybersecurity resume; to rehearse what a cloud interview loop asks, section 7 of our security interview questions.

8. What cloud security engineers are paid

Pay figures here come from the 81 postings in the sample that printed a yearly salary range in US dollars, from 53 employers. Their middle midpoint was $205,500, the median low end of the ranges was $180,000 and the median top end $240,000. Measured the way every salary page here is (from the midpoint a quarter of the way up to the range top nine tenths of the way up), the typical span was $181,500 to $330,000. Those numbers lean toward US technology employers, which are the ones that print pay; consultancies and employers outside the US mostly do not.

By level. Across 25 ranges, unlevelled titles had their middle at $199,750; senior titles sat at $191,000 across 30; staff, principal and lead titles, about $220,000 across 22; and managers and directors, $263,250 across only 4, too few to lean on. Senior sitting below no-level says more about who prints pay than about seniority: the no-level group holds three AI lab ranges, and groups this size move with a few employers. No entry-level seat printed a yearly salary, but internships did: Brain Co. stated $8,000 to $10,000 a month plus a housing stipend, Tanium $55 an hour, and Sezzle $800 a month for its intern in Peru.

By employer. Who you work for moves pay more than your title does.

The pattern follows from what each employer protects and sells. An AI lab or a cloud provider runs infrastructure whose compromise would threaten the whole business, and competes with every well-funded company for the few people who can secure it at that scale. A services firm sells its engineers' hours, so its pay is bounded by what clients are billed. The same logic splits the sample by kind of work: in-house roles securing the employer's own cloud stated a middle of $222,500 across 62 ranges from 47 employers, product engineering roles at vendors $185,000 across 11 ranges (from only 3 employers), and customer-facing and services roles $132,500 across 6.

The title penalty. The 32 postings that named cloud in their title stated a middle of $184,750; the 49 found through their duties stated $225,000. Several of the best-paying employers in the sample (OpenAI, Anthropic and xAI among them) call the job infrastructure security or software security engineering, while the vendors that title product roles "cloud security" pay less. Ranked by title words alone, "cloud security engineer" came 13th of 18 jobs on our list of the best-paid security jobs on 11 November, at $185,000 in the middle; judged by duties instead, the work earns more than the title implies, which is one more reason to search beyond it.

The extremes. The lowest stated ranges were $80,000 to $134,000 for a continuous monitoring engineer at Coalfire, a security services firm, and $102,500 to $136,500 for an information security engineer at Tenable whose posting asked for two to three years of experience. The highest were OpenAI's two principal infrastructure security roles at $401,000 to $510,000, Veeam's staff security engineer at $289,320 to $537,360, and Anthropic's senior software security engineer at $320,000 to $405,000.

Working from home carried no discount. Remote postings that printed pay (27) sat at a $216,000 middle, slightly above the $204,050 of the 54 on-site and hybrid ones.

Today's figures for the specialty. The board's cloud security salary page recalculates the specialty's band from every open role each hour, split by seniority, workplace and employer. Right now the cloud security specialty's middle stated salary is $183k/yr, within a typical band of $154k/yr to $297k/yr. The chart below sets it beside the neighboring specialties, read when you open this page.

Against the whole economy. The US Bureau of Labor Statistics has no separate category for cloud security. The nearest one it tracks is information security analyst, a job that paid a median $129,180 a year in May 2025 across some 192,900 positions, with 21% growth expected over the decade to 2035 - BLS Occupational Outlook Handbook, modified 27 August 2026. The gap reflects who prints pay on this board (technology employers, mostly experienced seats), not a contradiction; the services firms in this sample stated a middle of $125,000. Holding an offer? Put it into the salary calculator to see where it lands among live postings at the same level.

9. AI workloads and GPU clouds: the newest part of the job

The newest corner of cloud security is the infrastructure that trains and serves AI models. Twenty-two postings in the sample came from AI labs (OpenAI, Anthropic, xAI, Mistral AI and Cohere, 10 postings) and cloud and GPU infrastructure providers (Crusoe, CoreWeave, Nebius, Nscale, Firmus and Vultr, 12 postings), and 52 postings in all (28%) mentioned GPUs, AI infrastructure or workloads, training clusters or language models in describing the work.

The problems are classic cloud problems at a harder setting. GPU clouds rent expensive hardware to many customers in turn, so isolation is the core question: Nscale's senior staff platform security engineer must verify that a tenant cannot reach, persist on or learn from hardware after its lease ends, and review hypervisors, GPU partitioning and the out-of-band management network. Multi-tenancy came up in 21 postings and bare metal or high-performance computing in 12. AI labs guard their research and training environments: Anthropic's staff software security engineer designs default-deny network controls and segmentation between research, training and production, shipped as infrastructure as code so new clusters inherit them. Firmus, which runs what it calls an AI factory, was hiring a platform security operations manager to lead its incident response team and a 24-hour on-call roster.

A real example shows why this matters. In September 2024 Wiz researchers disclosed a container escape in the NVIDIA Container Toolkit, the component that gives containers access to GPUs, and estimated that it affected more than 35% of cloud environments; the risk was greatest where customers could run their own GPU-enabled images on shared hosts, because an escape there could expose other customers' data, models and secrets - Wiz, 26 September 2024. That is a Kubernetes and container security problem, which is why the skills in section 5 transfer directly.

The providers are writing AI into their own models of responsibility. Beside its general split, Microsoft now keeps two more: one for generative AI workloads and one for AI agents that act on their own - Microsoft Learn, and its new cloud security certification covers securing AI solutions. Inside the postings, nine named prompt injection, and six named a provider's managed AI services (Bedrock, SageMaker, Vertex AI or Azure OpenAI), usually in the context of controlling what data and permissions an AI application can reach.

Pay follows scarcity. The 7 ranges stated by 4 AI labs had a middle midpoint of $355,500, the highest of any employer group, though that is a small base. The caution is that this frontier rewards depth in the fundamentals rather than a separate AI security skill set: Linux, Kubernetes, network isolation, identity and incident response, applied to very expensive hardware and very valuable data. Security roles built around AI systems, in any specialty, are pulled together on the AI security jobs list.

AI also changes how the job is done. Snyk's posting expects engineers to direct AI coding agents to draft infrastructure fixes, connected to live cloud, posture and ticketing data so the proposals fit the real environment. What gets automated first is the repetitive middle, turning a finding into a pull request; the judgment around it (which finding matters, whether the fix is safe, how to explain it to the owning team) is what senior postings pay for.

10. A sequence for the next eighteen months

Plans like this fail when they become a list of certificates, so this one is built around things you make, which is what postings and interviews check. It assumes a technical job and several hours a week; someone already in cloud or DevOps will move faster through the first two phases.

Months 1 to 3: foundations you can show. Open a personal cloud account with a budget alarm on day one. Build a small network and a web service in it by hand, then rebuild it entirely in Terraform. Read the provider's shared responsibility page and its IAM documentation until you can explain how a request is allowed or denied. Write your notes publicly as you go.

Months 4 to 6: identity and guardrails. Create several accounts in an organization and a deliberately over-permissioned role; document every escalation path from it. Write organization-level guardrails that block the dangerous actions, and Terraform checks that fail a pull request when someone opens a security group to the world. If your job allows it, start owning the security findings for your team's cloud accounts.

Months 7 to 9: containers and Kubernetes. Build a cluster, deploy a workload with obvious weaknesses, and fix them with Pod Security Standards, admission policies, network policies and image scanning. Learn enough Go to read the code of one tool you use.

Months 10 to 12: detection, response and a certification. Turn on the provider's logs and threat detection service in your lab, generate suspicious activity, and write detections and a response runbook for it. Sit the security certification of the cloud you chose, now that the exam will test what you have done.

Months 13 to 18: applications and depth. Apply first where your background is the advantage: infrastructure and DevSecOps seats if you come from operations, cloud detection seats if you come from a SOC, product security seats if you write code. Search by duties, not only titles. Keep one project growing in public, and add the CKS if your targets run Kubernetes at scale.

11. Common questions about becoming a cloud security engineer

What timeline should I expect before landing a cloud security engineer job?

It depends on how much cloud you already run. Of the 131 postings that stated a minimum, the middle asked for five years, and many count infrastructure years toward it. Someone who already writes Terraform and runs clusters mainly needs security practice, which an internal move can supply; someone from outside cloud must first learn a platform deeply and build several projects, as section 10 lays out.

Is it possible to start in cloud security without experience?

Rarely directly. Only seven of 183 postings were internships or associate seats, and the two associate roles still asked for up to a year of hands-on cloud work from internships, labs or projects. The realistic path is a first job in cloud, platform or site reliability engineering, or a SOC seat that handles cloud alerts, then a move once you have built and secured real infrastructure.

What is a typical cloud security engineer salary?

Across the 81 sampled postings that printed a yearly range, the middle midpoint was $205,500 and the typical span $181,500 to $330,000, with AI labs and cloud providers at the top and services firms at the bottom. The board's live middle for the cloud security specialty is $183k/yr, within a typical $154k/yr to $297k/yr.

Should I learn AWS, Azure or Google Cloud first?

AWS for most people: it appeared in 151 of 183 postings, and in 151 of the 153 that named any major cloud. Learn it deeply, then add a second. Choose Azure first only if the employers you want run mainly on Microsoft. Postings listing "AWS, Azure or GCP" usually want depth in one, not mastery of three.

How much coding does cloud security work involve?

A good deal. Python appeared in 64% of postings, Go in 42% and infrastructure as code in 61%. Juniors script against provider APIs and write Terraform; at senior levels many postings read like software engineering roles that want services shipped to production.

Which cloud security certification do employers name most?

The one most often named for hands-on cloud work is the AWS Certified Security - Specialty (27 postings); the CISSP was named slightly more (30), mostly in senior and client-facing postings. Only five postings required any certification. For Azure, note that AZ-500 was retired on 31 August 2026 and replaced by the SC-500 exam for the Cloud and AI Security Engineer Associate. For Kubernetes-heavy employers, the CKS carries weight because it is performed on a live cluster.

How many cloud security jobs are remote?

Fifty-one of the 183 (28%) were fully remote, and they stated slightly higher pay than on-site roles. The board's narrower cloud security specialty shows a lower share, partly because none of the 18 vendor product engineering roles was remote. Five of the seven entry-level seats were remote.

How does a cloud security engineer differ from a cloud engineer or a DevSecOps engineer?

A cloud engineer builds and runs the infrastructure; a DevSecOps engineer builds security checks into the pipelines that deliver it; a cloud security engineer owns the security of the environment itself, from identity and guardrails to detection and response. The lines blur: several DevSecOps and site reliability postings in this sample were cloud security jobs by their duties.

Does AI threaten cloud security jobs?

The postings point the other way. AI is drafting fixes, and AI infrastructure is producing some of the best-paid cloud security seats in the sample. What gets automated is turning a known finding into a change; what employers keep paying for is deciding which risks matter, designing guardrails teams accept, and leading the response when something gets through.

Cloud security is one of ten specialties on this board; our map of security career paths places it among the others and shows how people cross between them, and someone with no security job at all should start with getting into cybersecurity.