The 60-second version: Cloud security protects data, identities, and workloads running on AWS, Azure, GCP, and similar platforms. The cloud provider secures the underlying platform; you secure how you configure and use it. Most real breaches come from misconfigurations, over-privileged IAM, stolen credentials, or insecure APIs — not exotic zero-days. The toolkit is built around posture management (CSPM), workload protection (CWPP), entitlement analysis (CIEM), and increasingly the all-in-one CNAPP platforms.
📖 On this page
What cloud security actually is
Cloud security is the practice of protecting data, applications, identities, and infrastructure that run on cloud platforms — primarily Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP), but also second-tier providers like Oracle Cloud, IBM Cloud, and Alibaba Cloud, plus 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 — all running 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 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, 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. Public S3 buckets, open security groups, unencrypted disks, disabled logging, weak password policies — these are the day-to-day failure modes. CSPM tools exist to find them at scale and keep them fixed.
Network security
VPCs, subnets, security groups, network ACLs, private endpoints, transit gateways, service meshes. The principles are familiar — segment, restrict, monitor — 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. CWPP and CNAPP platforms cover much of this.
Threat detection and response
CloudTrail, Azure Activity Log, 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. A response runbook for when something fires.
Compliance and governance
SOC 2, ISO 27001, PCI DSS, HIPAA, FedRAMP, GDPR, the NIS2 Directive. Most of this is "did you implement controls and can you prove it" — and most of the proof 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:
- Misconfiguration. Public buckets, exposed databases, open admin endpoints, missing logging.
- Over-privileged identities. A workload that has
*:*when it should have read-only on one bucket. Capital One is the canonical example. - Credential theft. Phishing, malware, info-stealers, hardcoded secrets in source code, leaked tokens in CI logs. Snowflake/UNC5537 was almost entirely credential reuse.
- Insecure APIs and SSRF. Web apps that can be coerced into calling internal endpoints, including the cloud metadata service. IMDSv2 exists because of Capital One.
- Supply-chain compromise. A poisoned dependency, a compromised CI/CD step, a malicious GitHub Action. SolarWinds is the marquee case.
- Account takeover. MFA fatigue, session token theft, social engineering of helpdesks. Scattered Spider/MGM is the textbook example.
- Insider risk. Departing engineers, over-broad access, audit gaps.
- AI/LLM-specific risks. Prompt injection, data leakage through model outputs, agentic systems with too much authority.
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)
The acronym soup is real. Here's 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 the running workload — VMs, containers, serverless. Includes vulnerability scanning, runtime detection, file integrity monitoring.
- CIEM — Cloud Infrastructure Entitlement Management. Analyzes IAM at scale. Who can assume what role? Which permissions are unused? Where are the privilege-escalation paths?
- CNAPP — Cloud-Native Application Protection Platform. The umbrella category. A single platform that bundles CSPM + CWPP + CIEM and often vulnerability management, container security, and IaC scanning. The market trend is consolidation 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 are increasingly important 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, the path that actually works for most people:
- 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.
- 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.
- 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.
- Read real breach post-mortems. Understanding how Capital One, SolarWinds, Snowflake, MGM, and LastPass actually happened teaches more than any textbook. Walk through the breach kill chains.
- Pick up one foundational certification. CCSK (Cloud Security Alliance) is vendor-neutral and a great anchor. AWS Security Specialty, Microsoft SC-100/AZ-500, and Google's Cloud Security Engineer are the provider-specific options. See our cloud security certifications guide.
- Join a community. Talking to practitioners is how you learn what's actually current. CSOH meets every Friday on Zoom, free, no marketing.
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. The implementation is wildly different. In on-prem environments you control the network and physical access; in the cloud you don't. Identity becomes the perimeter. Configuration becomes the attack surface. Everything is API-driven, which means everything is automatable — both for defense and for attackers.
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 — 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 + 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.
Ready to go deeper?
Pick your next step:
- Follow the CSOH cloud security learning path — beginner to advanced, with milestones.
- Compare cloud security certifications — CCSK, CCSP, AWS, Azure, GCP, CKS.
- Practice on cloud security CTFs — 38+ free challenges across providers.
- Read real breach kill chains — Capital One, Snowflake, MGM, SolarWinds, mapped to ATT&CK.
- Join the Friday Zoom session — free, weekly, vendor-neutral.