Shared Responsibility Model: AWS, Azure, GCP Cloud Security

A lot of teams only learn the shared responsibility model when something breaks.

The pattern is familiar. A company moves fast on AWS, Azure, or GCP. The provider handles infrastructure. Managed services reduce toil. The platform looks secure because it's running inside a major cloud. Then an incident lands. A storage policy is too open. A Kubernetes secret is exposed through a bad deployment path. An over-privileged identity gets abused. The first reaction is usually the wrong one: “Wasn't the provider supposed to prevent this?”

That question is the whole problem. Cloud providers secure the parts they control. You still own the parts you configure, deploy, grant access to, and fill with data. In modern stacks, that line gets harder to see, not easier, especially once you add Kubernetes, GitOps, Terraform, OpenTofu, OPA Gatekeeper, ArgoCD, FluxCD, and multi-cloud architecture.

The 3 AM Alert That Changes Everything

The alert usually doesn't say “you misunderstood the cloud.” It says something more concrete and more painful.

A platform team gets paged in the middle of the night because sensitive records were accessed unexpectedly. Logging shows the cloud platform stayed up. The managed database stayed up. The network backbone stayed up. The provider did exactly what it promised. The breach still happened because the customer-side controls failed.

I've seen teams lose hours arguing about the wrong boundary. Security asks whether the provider missed a control. Engineering points at a managed service and assumes the underlying platform should have blocked the path. Meanwhile, the root cause sits in customer-owned territory: identity policy, network rules, guest OS patching, workload configuration, application code, or deployment automation.

The cloud removes a lot of operational burden. It does not remove accountability.

That's why the shared responsibility model matters. It's not a compliance diagram for slide decks. It's the operating rulebook for cloud security. If your team doesn't know where provider responsibility ends and customer responsibility starts, incident response turns into finger-pointing.

The dangerous misconception is simple: moving to the cloud feels like outsourcing security. It isn't. You outsource specific layers of infrastructure management. You do not outsource ownership of your data, your identities, your runtime choices, or your release process.

The teams that handle incidents well usually have one thing in common. They've already translated the model into daily engineering practice. Access is codified. Infrastructure is version-controlled. Policies are enforced before deployment. Drift gets detected early. Ownership is explicit.

The teams that struggle treat the model as vendor documentation they read once during migration and never operationalized.

What Is the Shared Responsibility Model

The shared responsibility model defines who secures which parts of a cloud environment. AWS formally introduced it in 2011 as a foundational framework that separates “Security of the Cloud” from “Security in the Cloud”. The provider secures the cloud infrastructure it operates, while the customer secures the assets and configurations it controls, as outlined in Datadog's overview of the model.

Security of the cloud versus security in the cloud

This split is clearer if you think about an apartment building.

The landlord is responsible for the building structure, shared entrances, elevators, wiring in common areas, and the physical security of the property. You're responsible for locking your apartment, controlling who gets keys, protecting what's inside, and not creating hazards in your own unit.

Cloud works the same way.

The cloud service provider owns the physical facilities, hardware, core networking, and virtualization layers. You own what you deploy on top of that. That includes your data, identities, operating system choices in IaaS, application code, firewall rules, and service configuration.

A lot of teams get tripped up by the word “shared.” It sounds like both parties partially own the same control. In practice, that's not how the model works. Each party has full responsibility for the assets under its control. That's why cloud incidents often feel unfair to customers. The provider may be operating exactly as promised while your environment is still exposed.

Why the model matters in day-to-day engineering

This is not just a legal distinction. It affects architecture, audit scope, incident response, and team design.

If your team runs managed Kubernetes, for example, the provider may secure control plane infrastructure, but your team still owns workload security, RBAC decisions, secret handling, admission policy, and namespace boundaries. If you run a SaaS platform, the vendor may operate the application stack, but your team still owns who can access data and how that data is governed.

That's also why cloud compliance work goes sideways when teams only focus on vendor attestations. Provider certifications help, but they don't replace your own controls. If you're trying to align with governance expectations, this cloud compliance guide is the right mindset: inherited controls reduce effort, but they don't erase customer obligations.

Practical rule: If your team can configure it, deploy it, grant access to it, or store data in it, assume you own its security unless your SLA clearly says otherwise.

How Responsibility Shifts Across IaaS PaaS and SaaS

Where teams get confused is not the basic split. It's the moving line. The boundary changes depending on whether you consume infrastructure, platform, or software.

IaaS gives you control and gives you work

In IaaS, the provider handles the physical layer, virtualization layer, and core network controls. You take over the guest operating system, middleware, application code, and data endpoints. AWS is explicit that if you're running infrastructure on its platform, you must handle guest OS updates, security patches, and security group configuration, as described in AWS shared responsibility guidance.

That's where many self-managed VM estates go wrong. Teams like the flexibility of EC2, virtual networks, and custom runtimes. They underestimate the amount of security ownership that comes with that choice.

A simple comparison helps:

PaaS reduces toil but not application risk

In PaaS, the provider takes over more. The guest operating system and runtime environment move into provider scope. Your team no longer patches the underlying OS for that platform service. That's useful. It removes a category of work and a category of failure.

It does not mean your app is secure by default.

Your team still owns application logic, code security, configuration, and access decisions. If a platform service deploys your code, your insecure dependency, weak authorization logic, or exposed secret is still your problem. The line moved, but it did not disappear.

Many startup teams often get sloppy. They choose managed app platforms to move faster, then assume “managed” means “fully secured.” It means the provider manages the platform layer. It does not mean the provider reviews your release practices or protects your business logic.

A short visual explainer is useful here:

SaaS narrows your surface area, not your accountability

In SaaS, the provider manages the entire application stack, and the customer responsibility narrows mostly to data protection and identity management. This shifting boundary is formalized in the SLA, and a weak or unclear SLA creates security gaps, as explained in Sysdig's breakdown of IaaS, PaaS, and SaaS responsibility shifts.

That's the part many executives miss. A SaaS vendor can secure the service while your tenant remains badly governed. If your users have broad access, if MFA rollout is inconsistent, if data sharing is too open, or if integrations are over-permissioned, the vendor can still be meeting its obligations while your risk remains high.

The practical trade-off is straightforward:

• Choose IaaS when you need deep control and can sustain strong operational discipline.
• Choose PaaS when you want less platform management but still need tight ownership of application security.
• Choose SaaS when you want maximum abstraction, but are prepared to govern identities, tenant settings, and data use carefully.

Your Security Checklist What You Still Own

The fastest way to make the shared responsibility model useful is to turn it into a checklist your team can operate against.

One fact should anchor that checklist. The customer retains absolute and non-transferable responsibility for protecting data stored in the cloud. Azure's position is clear: customers always own their data and identities, including classification and encryption decisions, as summarized in CrowdStrike's shared responsibility overview.

Data and identity come first

If your team gets only two areas right, make them these.

• Classify data deliberately: Know which systems hold regulated, customer, financial, health, or internal operational data. Don't assume a managed service changes the sensitivity of what you store there.
• Define encryption ownership: Decide who manages keys, where encryption is required, and how exceptions get approved. Provider tooling helps, but your team still chooses the policy.
• Control data movement: Backups, exports, analytics pipelines, and cross-region copies often escape scrutiny. They still sit inside your security scope.
• Tighten IAM aggressively: Use role-based access, short-lived credentials where possible, and clear joiner-mover-leaver processes. Human access is usually broader than it should be.

A lot of organizations spend months hardening infrastructure while leaving identity messy. That's backwards. Identity is the control plane for your entire cloud estate.

If access governance is weak, every other control becomes easier to bypass.

Network and workload hygiene still belong to you

Even with managed services, your team usually still decides how traffic flows and what workloads are allowed to do.

Start with a practical runbook:

1. Review ingress paths: Know which services are internet-facing and why.
2. Reduce broad trust relationships: Avoid wide-open east-west traffic inside virtual networks and clusters.
3. Patch what you still manage: If you run IaaS, patching the guest OS is your responsibility. If you run containers, that responsibility moves into base images and workload dependencies.
4. Scan artifacts before release: Images, packages, and deployment manifests should be checked before they land in runtime.
5. Protect secrets at the pipeline and runtime layers: Hardcoded secrets, weak secret rotation, and overexposed CI variables cause repeated incidents.

For teams building internal standards, this cloud security and compliance reference is a useful companion because it ties security controls back to the operating model, not just the audit checklist.

What works and what doesn't

A short contrast makes this easier to apply:

Implementing Your Role with IaC and Policy as Code

Manual cloud security breaks as soon as environments get busy.

The shared responsibility model gets blurry in places the standard diagrams barely mention. In cloud native stacks, ownership extends beyond workloads and data into the systems that build, approve, and reconcile them. That includes Terraform, Terragrunt, OpenTofu, CI/CD pipelines, ArgoCD, FluxCD, admission policies, and the logging and alerting config that tells you when something went wrong.

The 2024 U.S. Department of Defense guidance makes the partnership point clearly in its DoD guidance on the shared responsibility model. In practice, the hard part is not the high-level split between provider and customer. The hard part is the gray zone inside Kubernetes, GitOps, and multi-cloud delivery workflows, where responsibility is distributed across repos, controllers, policies, and pipelines.

Infrastructure as Code makes ownership auditable

Console-driven infrastructure creates a security model based on memory, speed, and whoever had access during the incident. That fails under pressure.

IaC turns cloud configuration into something teams can review, test, approve, and roll back. With Terraform or OpenTofu, teams define IAM, networks, managed services, clusters, and guardrails in version control. The value is concrete. Change history is visible. Drift is easier to spot. Secure patterns can be reused instead of rebuilt from scratch in each account or subscription.

The trade-off is real. IaC does not remove risk. It shifts risk into modules, variables, state handling, and pipeline permissions. I have seen teams with clean Terraform repos and weak branch protection ship bad access policies faster than manual teams ever could.

A better operating pattern is simple. Treat infrastructure code like production application code. Require peer review. Test modules before promotion. Restrict who can apply changes. Separate plan from apply. Keep state access narrow and monitored.

This is also why automation literacy matters for security ownership. Teams building delivery platforms need to understand how approval flow, deployment runners, and reconciliation tools can introduce or block risk. This guide for engineering teams explains that connection well.

Policy as Code closes the Kubernetes gap

Kubernetes creates one of the biggest gray zones in the shared responsibility model.

A managed control plane does not cover how a cluster is used. Your team still owns namespace design, RBAC, workload privilege, admission rules, image provenance, network policies, secret handling, and service-to-service access patterns. Those controls usually live across YAML, Helm values, Kustomize overlays, Git repos, and CI checks. That spread is exactly why teams lose track of ownership.

Policy as Code brings those decisions into a system that can be tested and enforced. With OPA Gatekeeper or similar tooling, teams can block workloads that violate standards before they hit the cluster. Common examples include rejecting privileged containers, restricting hostPath mounts, requiring approved registries, enforcing labels needed for cost and incident ownership, and preventing risky security contexts.

The point is not to write more rules. The point is to remove ambiguity. If a platform team says production workloads must meet a baseline, the cluster and pipeline should enforce it. For teams standardizing that layer, this policy as code playbook is a useful next step.

Use policy in three places: pull requests, CI, and admission. If it only runs after deployment, it becomes reporting, not control.

GitOps creates a responsibility layer many teams miss

GitOps is not just a deployment preference. It is part of the security model.

Once ArgoCD or FluxCD reconciles production from Git, the repo becomes a control plane. Merge permissions matter. Branch protection matters. Secret encryption strategy matters. Policy checks before merge matter. Rollback behavior matters. If the repository accepts a bad change, the reconciler will apply it consistently and quickly.

That changes how teams should read the shared responsibility model. The cloud provider still secures the managed components it operates. Your team secures the declared intent, the review path, the repository controls, and the policy checks that govern what reaches production.

Teams that handle this well usually standardize a few rules:

1. Every environment is declarative
2. Every policy is testable
3. Every production change passes through Git review
4. Every exception has an owner and an expiry date
5. Every reconciler, runner, and service account has tightly scoped access

That is what implementation looks like in real environments. Responsibility is not just about who owns the server or the service. It is also about who owns the code and automation that decide what the environment becomes.

Common Pitfalls and a Modern Operating Model

The teams that struggle with the shared responsibility model rarely lack tools. They lack clean ownership across the gray zones, especially where Kubernetes, GitOps, and policy enforcement overlap.

Four mistakes that keep showing up

The first is the PaaS and SaaS fallacy. Teams buy a managed service and assume security ownership moved with it. It did not. The provider runs the platform. Your team still owns tenant settings, identity design, data classification, secret handling, and how users and workloads are allowed to interact with the service.

The second is configuration drift. The baseline in Terraform or OpenTofu looks clean, but production tells a different story. A console fix during an incident, a temporary firewall rule, an IAM exception for a pipeline, and an emergency Kubernetes change can leave the declared state and the live state out of sync for months. In GitOps environments, that drift is even more dangerous because teams assume Git reflects reality when it no longer does.

The third is IAM complacency. This one shows up everywhere. Cloud roles stay broad because narrowing them takes time. Kubernetes service accounts inherit more access than the workload needs. CI runners keep permissions long after the original project changed. Microsoft's guidance on cloud shared responsibility calls out identity and access management as a customer responsibility area, which is exactly why weak ownership here creates so many preventable incidents in managed environments too: Microsoft shared responsibility in the cloud.

The fourth is patching blind spots in IaaS. Teams know the provider secures the underlying infrastructure, but they still miss what runs inside the guest OS. VM patching gets split across platform, security, and application teams, so no one owns the full lifecycle. The result is predictable. Base images age, emergency fixes bypass the normal pipeline, and vulnerabilities stay open because each team assumes another team handled the update.

A better operating model

The fix is operational, not theoretical.

Strong teams define control ownership at the layer where the decision is made. That means separate owners for identity, network policy, cluster posture, workload policy, secrets, and CI/CD permissions. “Platform owns everything” sounds tidy, but in practice it hides risk and slows remediation because the wrong team gets paged and the right team lacks authority.

A modern model also treats the cloud-native control plane as part of the responsibility boundary. In Kubernetes, that includes admission control, namespace standards, image provenance, secret distribution, and RBAC. In GitOps, it includes repository permissions, branch protections, reconciler credentials, and rollback rules. In policy-as-code, it includes where policy runs, who can approve exceptions, and how those exceptions expire.

A few operating rules usually separate mature teams from noisy ones:

• Every control has a named owner and backup owner
• Every production change is traceable to code, policy, or a documented break-glass action
• Every exception has a ticket, an approver, and an expiry date
• Every cluster and cloud account is checked for drift
• Every workload identity is scoped to a specific task
• Every incident produces a control change, not just a meeting note

Mature cloud security comes from visible ownership, codified guardrails, and continuous verification across infrastructure, platforms, and delivery pipelines.

The review cycle matters too. Annual responsibility reviews are too slow for environments that change daily. Monthly control reviews, recurring IAM cleanup, patch validation for base images and VMs, drift detection, and policy tests tied to pull requests create a far better operating rhythm. The best teams I have worked with treat these checks as part of normal delivery, not as a security side process.

What practical maturity looks like

You can spot a mature operating model quickly.

The team can explain where provider responsibility ends and where their own engineering controls begin, including the gray areas around managed Kubernetes, shared CI systems, and GitOps reconcilers. Their infrastructure code matches production closely. Their policy layer blocks bad changes before deployment. Their incident reviews result in tighter templates, safer defaults, and narrower permissions.

Less mature teams keep relying on memory, manual exceptions, and assumptions about what the provider “probably covers.” That is usually where the shared responsibility model fails in real environments.

Own Your Security It Is Not an Option

The shared responsibility model is often presented as a boundary chart. In practice, it's an accountability model.

If your team is building on AWS, Azure, or GCP, the provider gives you secure infrastructure foundations. That's valuable. It lets you move faster and avoid running data centers yourself. But cloud speed only helps if your side of the boundary is engineered with the same discipline as the provider's side.

That matters even more in Kubernetes, GitOps, and multi-cloud environments. The old infrastructure-versus-application split is no longer enough. Your responsibilities now include the policy layer, the pipeline layer, and the operational logic that continuously reconciles production state. If those layers are weak, the cloud won't save you.

The good news is that this is solvable. Teams don't need perfect architecture on day one. They need clear ownership, strong defaults, version-controlled infrastructure, policy enforcement, and regular review of what's running.

The 3 AM alert becomes less likely when responsibility is explicit. And if an incident still happens, recovery is faster when your controls are codified and your boundaries are understood.

Stop assuming the provider owns more than it does. Start building your side of the model like production-grade software. That's what secure cloud adoption looks like.

If your team needs help turning the shared responsibility model into real engineering practice, CloudCops GmbH works with startups and enterprises to build secure cloud-native platforms using Terraform, OpenTofu, GitOps, Kubernetes, observability, and policy-as-code. They help teams move from vague ownership to auditable, automated controls that hold up in production.

Continue Reading

Read Zero Trust Architecture: A Guide for Cloud-Native Teams

Jun 26, 2026

Zero Trust Architecture: A Guide for Cloud-Native Teams

Implement a robust Zero Trust Architecture in your cloud-native stack. Our guide covers principles, Kubernetes patterns, a migration roadmap, and compliance.

zero trust architecture

+4

C

CloudCops

Read Identity Management Platforms: DevOps & Platform Guide 2026

Jun 15, 2026

Identity Management Platforms: DevOps & Platform Guide 2026

Guide to identity management platforms for DevOps and platform teams. Explore capabilities, Kubernetes integration, IaC, and selection criteria.

identity management platforms

+4

C

CloudCops

Read DDoS Protection Cloud: Complete Guide for Platform Teams

Jun 13, 2026

DDoS Protection Cloud: Complete Guide for Platform Teams

Get a complete guide to DDoS protection cloud services. Explore defense layers, managed options (AWS, Azure, GCP), Kubernetes mitigation & IaC for platform

ddos protection cloud

+4

C

CloudCops