What AWS/Azure/GCP Actually Protect (Hint: Not Everything)

"The cloud is secure." You've heard it a hundred times from every cloud provider's sales team. And they're not wrong: their part is secure. The physical data centers, the hypervisors, the underlying network infrastructure; that's locked down tight. AWS, Azure and GCP are genuinely good at securing their side of the equation.

Your side? That's a different story.

The shared responsibility model is one of those concepts everyone nods along to in a slide deck and then promptly ignores in practice. The line between what the cloud provider secures and what you secure is blurrier than most teams realize. And the stuff that lives in that gray area is exactly where breaches happen.

The shared responsibility model, for real this time

Every cloud provider publishes a shared responsibility model. The basics are the same across all three.

What they handle. Physical security. Hardware. Hypervisors. The global network backbone. Managed service infrastructure. If it's below the virtualization layer, it's their problem. And honestly, they're better at it than you would be. You're not going to out-secure AWS's data center physical security program. Don't try.

What you handle. Everything you put in there. Your data. Your configurations. Your identity and access management. Your network rules. Your encryption decisions. Your application code. Your operating systems (if you're running VMs). Basically, if you created it, configured it or deployed it, it's yours.

The gray area. This is where people get burned. "Secure by default" often isn't. Managed services handle some security for you, but not all of it. A managed database handles patching, but you're still responsible for access controls, encryption settings and network exposure. A managed Kubernetes service handles the control plane, but your pod security, network policies and workload configurations are on you.

The further up the stack you go, from IaaS to PaaS to SaaS, the more the provider handles. But "more" doesn't mean "all."

Where people get burned

After years of doing cloud security assessments, the same patterns show up over and over.

Default settings will get you. Cloud services are often open by default because the providers optimize for developer experience, not security. S3 buckets used to be public by default (AWS finally fixed that, but plenty of legacy buckets are still out there). Azure storage accounts default to allowing access from all networks. GCP is better about opinionated defaults, but it's not immune.

The rule is simple: assume every default is wrong until you've verified otherwise. If you didn't explicitly configure it to be secure, it probably isn't.

IAM is where complexity kills you. AWS has over 15,000 IAM actions. Azure has nearly 19,000. Every service adds more. Developers need access to build things. They grant broad permissions to unblock themselves. Those permissions never get tightened. Six months later, you've got service accounts with admin-level access that nobody remembers creating.

Cloud IAM is your responsibility, and it's the single biggest attack surface in most cloud environments. The providers give you the tools to do it right, but they just don't do it for you.

Encryption assumptions are dangerous. "Our data is encrypted" is one of the most misleading statements in cloud security. Encrypted at rest? With what key? Who manages it? Can your cloud provider access it? Encrypted in transit? Between which services? Is TLS enforced or just available?

Each cloud offers multiple encryption options: provider-managed keys, customer-managed keys, customer-provided keys. The security implications of each are dramatically different. But "it's encrypted" gets checked on the compliance form and nobody digs deeper.

If you didn't turn on logging, it's not on. CloudTrail in AWS, Activity Log in Azure, Cloud Audit Logs in GCP; these exist, but not all of them are on by default, and even when they are, they don't capture everything. Data-plane logging, VPC flow logs, DNS query logs: all optional, all cost money, all critical for incident response.

You can't investigate what you didn't log. And when a breach happens, "we didn't have logging enabled" is a devastating sentence.

Network defaults are too permissive. Security groups that allow 0.0.0.0/0 on port 22. Network ACLs that allow all traffic. Virtual networks with no segmentation. Public endpoints on services that should be private. Every cloud makes it easy to open things up and harder to lock them down.

What each cloud does differently

They're not all the same, and knowing the differences matters.

AWS takes the approach of "here's maximum flexibility: securing it is your problem." The good news: you can lock things down precisely. The bad news: the sheer number of services and configurations means there are a thousand ways to get it wrong. AWS gives you 47 security services to help. Whether that's empowering or overwhelming depends on your team.

Azure is tightly integrated with the Microsoft ecosystem: Entra ID, M365, Defender. If you're a Microsoft shop, this integration is a strength. But Azure's complexity is real, and the overlap between Azure AD, subscriptions, management groups and resource-level permissions creates confusion. The good news is that Microsoft Defender for Cloud provides a unified view across Azure and extends to AWS and GCP.

GCP is the most opinionated of the three. Defaults tend to be more secure. Organization policies are easier to enforce top-down. The trade-off is a smaller ecosystem and fewer services, which means less flexibility but fewer footguns. For teams that want guard rails built into the platform, GCP is often the easiest starting point.

Filling the gaps

Knowing the model is step one. Actually closing the gaps requires deliberate effort.

Map the responsibility line for your specific stack. Don't just read the generic shared responsibility diagram. For every service you use, understand exactly what the provider handles and what you handle. A managed Kubernetes service has a different responsibility split than a VM. A serverless function has a different split than a container. Document it.

Assume defaults are wrong. Build a hardening baseline for every service you deploy. CIS Benchmarks are a good starting point. Your CSPM tool (see Blog #2) should be checking these continuously. When a new service gets deployed, it should inherit secure configurations automatically, through IaC templates, not manual configuration.

Use third-party tools for what clouds don't do well. Cloud-native security tools are good, but they're strongest within their own ecosystem. For multicloud visibility, attack path analysis and consistent policy enforcement across AWS, Azure and GCP, tools like Palo Alto's Cortex Cloud, Microsoft Defender for Cloud (yes, it does multicloud) and CrowdStrike's Falcon Cloud Security fill the gaps that native tools leave.

Document what you're responsible for, then actually do it. This sounds obvious, but most organizations haven't written down who owns what in their cloud security model. Which team is responsible for IAM reviews? Who monitors network configurations? Who handles encryption key management? If nobody owns it, nobody's doing it.

Bottom line

The cloud is secure. Your use of it probably isn't. That's not a knock on your team; it's a reflection of how complex cloud security has become and how easy it is to assume the provider is handling more than they are.

Read the shared responsibility documentation for every cloud you use. It's not exciting reading, but it's the most important thing you can do to understand your actual risk exposure. Map the gaps for your specific services. Assume defaults are insecure. Turn on logging before you need it.

And when in doubt, assume it's your problem. Because it almost certainly is.

Next up: DLP Isn't Just Blocking Credit Card Numbers Anymore