Cloud Security Engineering

Every major cloud provider frames its responsibility model around the same basic split, even though the exact wording differs. AWS describes it as "security of the cloud" (AWS's job) versus "security in the cloud" (the customer's job). Microsoft and Google publish equivalent models under different names. In every case, the provider is responsible for the physical security of data centers, the underlying hardware, the virtualization or hypervisor layer, and the operation of the managed control planes for the services it offers. The customer is always responsible for their data, how identity and access are configured, and how the services they've chosen to use are set up.

The model doesn't reduce the total amount of security work — it relocates it. Engineers new to cloud sometimes read "shared" as "the provider has this covered" and stop reading there. Breach post-mortems consistently say otherwise: the large majority of cloud security incidents trace back to the customer side of the line — a storage bucket left publicly readable, an over-permissioned IAM role, an unpatched guest operating system, a database left reachable from the internet — rather than a compromise of the provider's own infrastructure.

The exact location of the responsibility line moves depending on how much of the stack the provider manages for a given service. As a workload moves from infrastructure-as-a-service toward software-as-a-service, more of the stack shifts to the provider, but the customer's portion never disappears entirely.

• •IaaS (AWS EC2, Azure Virtual Machines, GCP Compute Engine): the customer owns guest OS patching, host-level firewall configuration, and everything running on the instance; the provider owns the hypervisor and physical layer
• •PaaS (AWS RDS, Azure App Service, GCP Cloud SQL/App Engine, and managed Kubernetes control planes): the provider patches the OS and runtime; the customer still owns identity and access configuration, network access rules, and the data itself
• •SaaS (a vendor-hosted email, CRM, or collaboration platform): the provider manages nearly the entire stack; the customer still owns identity configuration, data sharing and retention settings, and which users have access to what

AWS publishes its shared responsibility model with services broken out individually, since the line differs from one service to the next even within a single provider — a self-managed database on EC2, a managed instance on RDS, and a serverless option like Aurora Serverless each put the boundary in a different place. Azure documents responsibility per service in the same way, and adds a further distinction worth knowing: for many services, whether encryption keys are Microsoft-managed or customer-managed is itself a responsibility toggle within the same service, not a separate product decision. GCP publishes a similar model but has more recently framed it as "shared fate" rather than only shared responsibility — the emphasis being that GCP takes a more active role in helping customers land on secure configurations by default (secure-by-default settings, guided setup, and built-in recommendations) rather than simply documenting where the line sits and leaving the customer to work out the rest.

The practical takeaway is to check the specific service's documentation rather than assuming a blanket rule for a whole provider. The same organization can have services on both ends of the spectrum — a self-managed VM with a wide-open responsibility surface, and a fully managed SaaS product where nearly the only lever left is identity configuration.

A short list of the ways teams misapply this model in practice, each of which shows up repeatedly in breach reports:

• •Assuming a service encrypts data at rest in a way that meets a specific compliance requirement, when the default is often a provider-managed key rather than a customer-managed key with the audit trail and access control a requirement may demand
• •Assuming a managed database is fully secured because the provider patches it, while leaving default credentials in place or leaving the instance reachable from the public internet
• •Treating a provider's own compliance certification (SOC 2, ISO 27001) as proof that a customer's workload is compliant — the certification covers the provider's infrastructure, not how the customer configured their resources on top of it
• •Assuming the provider will proactively flag a customer-side misconfiguration — most providers do not monitor or alert on customer resource configuration by default; that's the customer's own responsibility to build