What is Cloud Security?

What cloud security is

Cloud security is the practice of protecting data, applications, identities, and infrastructure that run on cloud platforms. That primarily means Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP), but it also covers second-tier providers like Oracle Cloud, IBM Cloud, and Alibaba Cloud, and the SaaS layer (Microsoft 365, Salesforce, Snowflake, GitHub, and so on).

It is not a single product or a single team. In a mature organization, cloud security spans configuration management, identity and access, network controls, data protection, application security, threat detection, incident response, and compliance, across hundreds or thousands of accounts, subscriptions, and projects.

If you're new to the field, see the cloud security glossary for plain-English definitions of the acronyms in this article.

The shared responsibility model

The most important concept in cloud security is the shared responsibility model. Cloud providers secure some things; you secure the rest. The line moves depending on the service. Read the full breakdown across IaaS, PaaS, SaaS and serverless →

The classic framing:

• Security of the cloud is entirely the provider's job: physical data centers, the network backbone, the hypervisor, the managed-service internals.
• Security in the cloud is your job: your configurations, IAM policies, code, data, network rules, and the workloads you deploy.

Where the line sits depends on the service model:

• IaaS (raw VMs like EC2): you secure almost everything above the hypervisor, which means OS patching, network rules, IAM, applications, and data.
• PaaS (managed services like RDS and App Service): the provider patches the runtime; you still own configuration, access controls, and data. Cloud Run is different: it runs the container image you deploy, so the OS packages in that image are yours to patch unless you deploy on Google's buildpack base images with automatic base image updates turned on.
• SaaS (Microsoft 365, Salesforce): the provider runs the application; you still own user accounts, data classification, sharing settings, and integrations.

Almost every notable cloud breach comes down to a customer-side failure rather than a provider compromise. The Capital One, Snowflake/UNC5537, and LastPass incidents are all instructive, and Microsoft Storm-0558 is the instructive exception: a stolen Microsoft signing key and a Microsoft token-validation flaw. See the breach kill chains for full step-by-step analyses.

The core pillars of cloud security

You can carve up cloud security a dozen ways. The pillars below are the ones most teams organize around.

Identity and access management (IAM)

In the cloud, identity is the new perimeter. Every API call is authenticated and authorized against an identity: a user, a role, a service principal, or a workload identity. Strong IAM means least-privilege policies, no long-lived access keys where you can avoid them, MFA everywhere, and continuous review of who can do what. Most cloud breaches involve at least one identity failure: an over-privileged role, a leaked key, a phished session token.

Configuration and posture

The cloud is a giant configuration surface. Its day-to-day failure modes are public S3 buckets, open security groups, unencrypted disks, disabled logging, and weak password policies. CSPM tools exist to find them at scale and keep them fixed. See how CSPM, CNAPP, CWPP, CIEM and DSPM compare →

Network security

The building blocks are VPCs, subnets, security groups, network ACLs, private endpoints, transit gateways, and service meshes. The principles of segmenting, restricting, and monitoring are familiar, but the implementation is provider-specific and changes constantly.

Data protection

Encrypt data at rest and in transit, manage keys (KMS, Key Vault, Cloud KMS), classify what's sensitive, and prevent exfiltration. Increasingly this also means thinking about what data you let LLMs and AI services see.

Application and workload security

Secure code, dependency scanning, container image hardening, runtime protection for VMs and Kubernetes, serverless function security, and the CI/CD pipeline that ships it all. CWPP and CNAPP platforms cover much of this. For the account-structure foundation underneath it, see cloud landing zones.

Threat detection and response

The pieces are CloudTrail, Azure Activity Log, and GCP Audit Logs feeding a SIEM; provider-native services like GuardDuty, Defender for Cloud, and Security Command Center; detection content mapped to MITRE ATT&CK Cloud techniques; and a response runbook for when something fires.

Compliance and governance

SOC 2, ISO 27001, PCI DSS, HIPAA, FedRAMP, GDPR, the NIS2 Directive. Most compliance work is answering two questions: did you implement the controls, and can you prove it? The proof mostly comes from configuration evidence the cloud already produces.

The threats that matter

Forget "advanced persistent threats" for a minute. The breaches that actually happen tend to come from a small set of repeatable patterns:

Real attacks chain several of these together. To see exactly how, walk through the cloud breach kill chains, all mapped to MITRE ATT&CK Cloud techniques.

The tool landscape (CSPM, CNAPP, CWPP, CIEM)

Expect a lot of acronyms. Here is a working map of the major categories:

• CSPM (Cloud Security Posture Management). Continuously scans your cloud accounts for misconfigurations against a benchmark like CIS or your own policies. Examples: Prowler, ScoutSuite, Steampipe, plus commercial platforms.
• CWPP (Cloud Workload Protection Platform). Protects running workloads: VMs, containers, and serverless functions. Includes vulnerability scanning, runtime detection, and file integrity monitoring.
• CIEM (Cloud Infrastructure Entitlement Management). Analyzes IAM at scale: who can assume which role, which permissions go unused, and where the privilege-escalation paths are.
• CNAPP (Cloud-Native Application Protection Platform). The umbrella category: a single platform that bundles CSPM, CWPP, and CIEM, and often vulnerability management, container security, and IaC scanning. The market is consolidating into CNAPP.
• DSPM (Data Security Posture Management). Finds and classifies sensitive data across cloud stores, then tracks who can access it.
• SIEM/SOAR. Centralizes logs and automates response. The cloud-native variants matter more as log volume explodes.
• Provider-native services. AWS GuardDuty/Security Hub/IAM Access Analyzer; Microsoft Defender for Cloud + Entra; GCP Security Command Center. Often the cheapest credible starting point.

For specific tools, hands-on labs, and certifications, see the cloud security resources catalog.

How to get started

If you're trying to break into cloud security or level up, this order works for most people:

1. Pick one cloud. AWS, Azure, or GCP. Don't try to learn three at once. AWS has the deepest community and the most learning material.
2. Learn IAM and networking first. Almost every breach involves one or both. The provider's free training (AWS Skill Builder, Microsoft Learn, Google Cloud Skills Boost) is fine for fundamentals.
3. Practice on intentionally vulnerable environments. CloudGoat, flAWS, EntraGoat, CNAPPGoat, and PwnedLabs let you exploit and defend without getting fired. See our cloud security CTF directory.
4. Read real breach post-mortems. Understanding how Capital One, SolarWinds, Snowflake, MGM, and LastPass happened teaches more than any textbook. Walk through the breach kill chains.
5. Pick up one foundational certification. CCSK (Cloud Security Alliance) is vendor-neutral and a great anchor. AWS Security Specialty, Microsoft SC-100/SC-500, and Google's Cloud Security Engineer are the provider-specific options. See our cloud security certifications guide.
6. Join a community. Talking to practitioners is how you learn what's current. CSOH meets every Friday on Zoom, free, no vendor pitches.

For a structured plan with specific milestones, see the cloud security learning path.

Frequently asked questions

Is cloud security different from regular cybersecurity?

The principles are the same, but the implementation is wildly different. On-prem, you control the network and physical access; in the cloud, you don't. Identity takes over the job of the perimeter, configuration becomes the attack surface, and because everything is API-driven, defenders and attackers alike can automate all of it.

Do I need to know how to code?

Not to start. You will pick up Python and shell over time, plus enough Terraform or CloudFormation to read what your team is deploying. Reading code matters more than writing it for most cloud security roles.

How long does it take to get a cloud security job?

It depends entirely on your starting point. A working sysadmin or network engineer can usually transition in 6-12 months of focused learning plus a cert. Someone starting from zero is more like 1-2 years. Hands-on labs and a portfolio of CTF write-ups beat passive coursework.

What's the salary like?

In the US, cloud security engineers typically land in the $130k-$220k range depending on location, seniority, and whether you're at a big tech company. Specialized roles (cloud incident response, detection engineering, CNAPP architects) trend higher. Outside the US, ranges vary substantially, so check local sources.

Should I pay for a bootcamp?

Usually no. The free and low-cost material is excellent if you're disciplined: official provider training, CSA's CCSK study guide, PwnedLabs, our resources catalog, and the CTF directory. Pay for SANS or a focused cert lab if your employer is footing the bill.

What's CNAPP and do I need to care?

CNAPP is the all-in-one cloud security platform category: CSPM, CWPP, and CIEM in one tool. If you're an operator at a company buying tools, you'll almost certainly evaluate CNAPP vendors. If you're learning, focus on the underlying concepts (posture, workload, entitlement, runtime) and the products will make sense.