Every beginner who moves from managing a personal laptop to running workloads on a public cloud eventually asks the same question: if something breaks or gets hacked, whose fault is it — mine, or the cloud provider’s? The shared responsibility model is the answer the entire cloud industry has settled on.

Every beginner who moves from managing a personal laptop to running workloads on Amazon Web Services, Microsoft Azure, or Google Cloud Platform eventually reaches the same question: “If something breaks or gets hacked, whose fault is it — mine, or the cloud provider’s?” The shared responsibility model is the answer the entire cloud industry has settled on. It is a documented, contractual, and technical division of security duties between the cloud provider and the customer using that cloud.

Think of the shared responsibility model as a boundary line drawn across a stack of technology layers — physical data centers at the bottom, your application code and data at the top — where everything below the line is the provider’s job to secure, and everything above the line is yours. The exact position of that line moves depending on whether you are consuming Infrastructure as a Service, Platform as a Service, or Software as a Service, but the line always exists, and understanding exactly where it sits for your workload is one of the single most important skills a software architect, developer, or operations engineer can have.

Where the concept came from

Before cloud computing existed in its modern form, organizations owned or leased entire data centers. Every layer, from the concrete floor to the application logic, was the company’s own responsibility. There was no ambiguity because there was no second party. Security teams built firewalls, patched operating systems, wired physical access badges, and audited their own database servers, all under one roof and one budget.

That changed once Amazon launched Amazon Web Services publicly around 2006, offering compute and storage as rentable, on-demand infrastructure. For the first time, a company’s servers were sitting inside a building it did not own, managed in part by people it did not employ. Early adopters quickly discovered that cloud computing did not eliminate the need for security discipline — it redistributed it. AWS was responsible for keeping the physical hardware, network cabling, and virtualization layer secure, while the customer remained responsible for what they installed, configured, and stored on top of that infrastructure.

As more providers entered the market and as high-profile misconfiguration incidents made headlines — unsecured storage buckets leaking millions of customer records, for example — the industry converged on formalizing this division into what we now call the shared responsibility model. Today, every major cloud provider publishes an explicit shared responsibility document, and it has become one of the first things any cloud certification exam (AWS Certified Solutions Architect, Azure Fundamentals, Google Associate Cloud Engineer) tests candidates on.

A quick beginner-friendly framing

By the end of this tutorial you will be able to draw the responsibility line confidently for any cloud service you use, explain it clearly to a non-technical stakeholder, write code and configuration that respects it, and recognize the recurring anti-patterns that cause the real-world breaches examined later in this guide.

Why does this model need to exist at all? Because no single party can secure a system it does not fully control — and no cloud provider could realistically inspect the contents of every customer’s private application code, business logic, and data without destroying the confidentiality and autonomy that made cloud computing attractive in the first place.

Couldn’t the cloud provider simply secure everything, end to end, since they control the data centers? The honest answer is: no single party can secure a system it does not fully control, and no cloud provider could realistically inspect, harden, or patch the contents of every customer’s private application code, business logic, and data without violating that customer’s confidentiality and autonomy.

The core tension

Cloud computing works because a provider builds one enormous, shared, highly engineered platform and rents slices of it to thousands or millions of customers. That shared platform must remain secure and isolated for every tenant — this is the provider’s job, and they invest billions of dollars and thousands of security engineers into it. But what each customer chooses to build, how they configure their portion of that platform, what credentials they issue, and what data they upload is fundamentally private to that customer. The provider cannot and should not be reading your database contents to check if you encrypted sensitive fields correctly.

This creates an unavoidable split:

• The provider secures the parts of the stack that are common infrastructure shared across all customers — physical security, network backbone, hypervisor isolation, and (depending on the service) the managed software layer itself.
• The customer secures the parts of the stack that are unique to their own workload — identity and access configuration, data classification and encryption choices, application code, and network rules they define.

What goes wrong without this clarity

Without an explicit shared responsibility model, two dangerous failure modes appear repeatedly in real organizations:

The motivation, restated simply

The shared responsibility model exists to remove ambiguity. It gives every engineer, architect, auditor, and executive a shared vocabulary and a shared checklist so that security work is neither skipped because “someone else must be doing it” nor duplicated because nobody trusts the boundary. It turns an abstract worry — “is my cloud environment secure?” — into a concrete, layer-by-layer accountability map that a team can actually act on, review during design discussions, and revisit whenever a new managed service enters the picture.

Before going deeper, let’s precisely define the vocabulary this entire tutorial depends on. Every term below is one you will see repeatedly in provider documentation, compliance audits, and job interviews.

3.1 Shared responsibility model — the formal definition

The shared responsibility model is a security and compliance framework that defines which security tasks are performed by the cloud service provider and which are performed by the customer, based on the type of cloud service consumed. It is typically visualized as a stacked diagram of technology layers, with a horizontal line separating “provider-managed” from “customer-managed” layers.

3.2 “Security OF the cloud” vs. “Security IN the cloud”

This is the single most quoted phrase in shared responsibility documentation, popularized by AWS but conceptually used by every major provider:

3.3 The service model spectrum: IaaS, PaaS, SaaS

The exact position of the responsibility line shifts depending on how much of the stack the provider manages for you. There are three foundational service models, and understanding them is essential to understanding the model itself.

• Infrastructure as a Service (IaaS): The provider gives you raw virtualized compute, storage, and networking — think of renting a virtual machine. You install and manage almost everything above the hypervisor: operating system, runtime, middleware, and application.
• Platform as a Service (PaaS): The provider manages the operating system, runtime, and middleware, so you only deploy application code and manage your data and configuration. Managed database services and managed Kubernetes control planes are classic PaaS-like offerings.
• Software as a Service (SaaS): The provider manages nearly the entire stack, including the application itself. You are only responsible for your data, your user accounts, and how you configure the application’s built-in settings.

3.4 Customer data

Customer data refers to any content the customer uploads, generates, or stores using the cloud service: files, database records, source code, logs, and configuration. Regardless of which service model is used, customer data is always the customer’s responsibility to classify, protect, and control access to. No provider takes ownership of deciding how sensitive your data is or who inside your organization should see it.

3.5 Identity and access management (IAM)

IAM is the system of accounts, roles, and permission policies that determines who — human or machine — can perform which actions on which resources. In nearly every service model, configuring IAM correctly is the customer’s job. The provider builds and secures the IAM engine itself (the software that evaluates policies), but the customer decides what those policies say.

3.6 Encryption at rest and in transit

Encryption at rest protects data stored on disk; encryption in transit protects data moving across a network. Providers typically offer the encryption tools and infrastructure (key management services, TLS termination) but the customer must usually choose to enable them, choose which keys to use, and decide which data needs protection.

3.7 Configuration vs. code

A useful mental distinction: configuration is how you set up a provider’s managed service (bucket permissions, security group rules, IAM policies), while code is what you build on top of it (your application logic). Both fall on the customer’s side of the line in most service models, and both are common sources of security incidents when handled carelessly.

3.8 Compliance inheritance

Cloud providers undergo independent audits (SOC 2, ISO 27001, PCI DSS, and others) for the infrastructure layers they manage, and customers can “inherit” some of that compliance coverage for the parts of the stack the provider controls. However, customers must still demonstrate their own compliance for the layers they manage — inheriting a provider’s SOC 2 report does not automatically make a customer’s application compliant if their own IAM policies or data handling practices are flawed.

3.9 How different providers describe the same idea

Every major cloud provider publishes its own version of this model, and while the underlying concept is identical, the terminology and diagrams differ slightly. Recognizing these differences matters because job postings, certification exams, and vendor documentation will each use their own house vocabulary for what is fundamentally the same boundary.

The “shared fate” idea from Google Cloud is worth calling out explicitly because it represents an evolution of the classic model. Rather than treating the boundary as a strict handoff point, shared-fate philosophy encourages the provider to supply secure defaults, automated guardrails, and proactive guidance so that customers are less likely to make a costly configuration mistake in the first place. The underlying division of duties does not change, but the provider takes a more active hand in helping the customer succeed at their half of the job.

To really internalize the shared responsibility model, it helps to see it laid out as an architecture diagram — a vertical stack of technology layers with the responsibility boundary drawn at different heights depending on the service model.

4.1 The components on the provider’s side

• Physical facilities: Data center buildings, badge access systems, security guards, surveillance, fire suppression, and environmental controls.
• Hardware: Physical servers, storage arrays, network switches, and cabling — including secure decommissioning of failed disks.
• Virtualization layer (hypervisor): The software that carves one physical machine into many isolated virtual machines, ensuring one customer’s workload cannot see or interfere with another’s.
• Managed service internals: For PaaS/SaaS offerings, the provider also secures the operating system, database engine, or application runtime itself, including patching known vulnerabilities.
• Global network backbone: The high-speed private network connecting the provider’s own data centers and edge locations.

4.2 The components on the customer’s side

• Identity and access policies: Which users, groups, and machine roles exist, and precisely what permissions each is granted.
• Network configuration the customer controls: Virtual network layout, subnet design, security group and firewall rules the customer defines within their account.
• Guest operating system (IaaS only): Patching, hardening, and antivirus/endpoint protection on virtual machines the customer manages.
• Application code: Everything the customer writes and deploys, including how it validates input, authenticates users, and handles secrets.
• Data classification and encryption choices: Deciding what is sensitive, enabling encryption, and managing encryption keys where the provider allows customer-managed keys.
• Client-side and endpoint security: Securing the laptops, browsers, and developer credentials used to access the cloud console or APIs.

4.3 Verifying boundaries with code

Even though the provider secures the hypervisor and physical layer, customers can and should programmatically verify that their own side of the boundary — the configuration layer — is correctly locked down. Below is a small Java example using the AWS SDK to check whether a storage bucket the customer owns is publicly accessible, something entirely within the customer’s responsibility to catch.

import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.services.s3.model.GetPublicAccessBlockRequest;
import software.amazon.awssdk.services.s3.model.GetPublicAccessBlockResponse;

public class BucketExposureChecker {

    private final S3Client s3Client;

    public BucketExposureChecker(S3Client s3Client) {
        this.s3Client = s3Client;
    }

    // Returns true if the bucket blocks all forms of public access.
    // This check covers configuration the CUSTOMER owns under the
    // shared responsibility model -- the provider will not do this for you.
    public boolean isBucketLockedDown(String bucketName) {
        GetPublicAccessBlockRequest request = GetPublicAccessBlockRequest.builder()
                .bucket(bucketName)
                .build();

        GetPublicAccessBlockResponse response =
                s3Client.getPublicAccessBlock(request).publicAccessBlockConfiguration();

        return response.blockPublicAcls()
                && response.blockPublicPolicy()
                && response.ignorePublicAcls()
                && response.restrictPublicBuckets();
    }
}

Notice what this code does not do: it never touches the hypervisor, the physical disks, or the storage engine’s internal replication logic. Those are entirely the provider’s domain. It only inspects a configuration setting that belongs to the customer.

It is one thing to draw a line on a diagram; it is another to understand the actual mechanisms that make that line real and enforceable in a live cloud environment. This section explains what happens “under the hood.”

5.1 Multi-tenancy and isolation

Cloud providers run many customers’ workloads on the same shared physical hardware — this is called multi-tenancy. The provider’s core security engineering job is ensuring that customer A’s virtual machine, storage volume, or database instance can never read, write, or even detect customer B’s resources, despite physically sharing a server, disk array, or network switch. This isolation is enforced through the hypervisor (for compute), storage virtualization layers (for disks), and network virtualization (virtual private clouds, VLANs, and software-defined networking).

5.2 The control plane vs. the data plane

Cloud architecture separates the control plane (the APIs and systems used to configure resources — create a VM, attach a disk, set a permission) from the data plane (the actual flow of the customer’s application traffic and data). The provider secures both planes’ underlying infrastructure, but the customer’s IAM decisions determine who can issue control-plane commands against their account, and the customer’s application code determines how data flows through the data plane.

5.3 How IAM policy evaluation actually works

When a user or service tries to perform an action (say, reading a file from a storage bucket), the provider’s IAM engine evaluates every applicable policy attached to that identity and that resource, and returns an explicit allow or deny decision. The provider guarantees this evaluation engine is implemented correctly and cannot be bypassed — that is their responsibility. But the actual content of those policies — who gets which permissions — is written entirely by the customer.

// Simplified illustration of policy evaluation logic
// (conceptually similar to how cloud IAM engines decide access)
public class PolicyEvaluator {

    public enum Decision { ALLOW, DENY }

    public Decision evaluate(List<Policy> policies, String action, String resource) {
        boolean explicitDeny = policies.stream()
                .anyMatch(p -> p.denies(action, resource));

        if (explicitDeny) {
            return Decision.DENY; // explicit deny always wins
        }

        boolean explicitAllow = policies.stream()
                .anyMatch(p -> p.allows(action, resource));

        return explicitAllow ? Decision.ALLOW : Decision.DENY; // default deny
    }
}

The provider is responsible for making sure this evaluation logic runs correctly, at scale, without being circumvented by an attacker manipulating the underlying platform. The customer is responsible for making sure the policies list passed into that evaluator does not contain overly broad, dangerous rules such as granting every action on every resource to every user.

5.4 Shared key management

Most providers offer a managed Key Management Service (KMS). The provider secures the hardware security modules that generate and store the actual cryptographic key material, ensuring keys cannot be extracted even by the provider’s own employees in a well-designed system. The customer decides which resources use encryption, which keys protect them, and who is allowed to use those keys to decrypt data — a purely customer-side configuration decision.

5.5 Metadata services and their double-edged nature

Cloud virtual machines often expose an internal metadata endpoint that lets the operating system retrieve temporary credentials without hardcoding secrets. The provider secures the underlying metadata service infrastructure. However, if the customer’s application has a vulnerability — such as a server-side request forgery flaw — that allows an attacker to query this metadata endpoint from outside, the resulting credential theft is a customer-side application security failure, not a provider infrastructure failure. This exact mechanism was central to one of the largest cloud data breaches in history.

5.6 Software-defined networking and customer-defined segmentation

Modern cloud networks are built on software-defined networking, meaning that what looks like a physical network topology to the customer is actually an abstraction implemented in software by the provider across shared physical switches and routers. The provider guarantees this abstraction is enforced correctly — packets from one customer’s virtual network genuinely cannot leak into another customer’s virtual network, even though they may traverse the very same physical cabling.

Within that guaranteed abstraction, however, the customer designs their own network topology: how many subnets to create, which subnets are reachable from the public internet, and which internal services can talk to which other internal services. A provider will happily let a customer place a database directly in a public-facing subnet if that is what the customer configures — the isolation guarantee only promises that other tenants cannot reach it, not that the customer’s own design is sound. This is precisely why network segmentation design is consistently listed as a customer-owned control in every provider’s documentation.

5.7 Shared responsibility for patching, illustrated end to end

Patching deserves its own walk-through because it is one of the clearest illustrations of how responsibility shifts with service model. Consider a known vulnerability disclosed in a popular open-source component:

• If that component is part of the hypervisor or the provider’s own managed database engine, the provider is responsible for identifying, testing, and deploying the patch across their fleet, typically without any customer action required, and often communicated only after the fact for transparency.
• If that component is part of the guest operating system on a customer-managed virtual machine, the customer must identify the exposure, schedule a patch window, test compatibility with their own workload, and apply the update themselves.
• If that component is a library the customer’s own application depends on, no provider action is possible at all — only the customer can update their own dependency tree, rebuild, and redeploy.

This three-way split is a useful mental exercise to run for any newly disclosed vulnerability: ask which of these three buckets it falls into before assuming “the provider will handle it.”

Responsibility does not just apply to static infrastructure layers — it also applies across the entire lifecycle of data, from the moment it is created to the moment it is deleted. Understanding this flow helps you avoid gaps where nobody, provider or customer, is actively protecting a stage of the data’s journey.

6.1 Creation and ingestion

When data is first created or uploaded, the customer decides how sensitive it is and what protection it needs. The provider secures the transport mechanism (TLS termination, network hardware) as long as the customer configures the connection to actually use encryption in transit — an unencrypted HTTP endpoint is a customer configuration choice, not a provider failure.

6.2 Storage

Once data lands in a storage service, the provider guarantees durability (multiple copies, redundancy across physical disks) and secures the storage hardware itself. The customer decides encryption-at-rest settings, access permissions, and retention policies.

6.3 Processing

While data is being processed by compute resources, the provider ensures process isolation between tenants at the hypervisor level. The customer’s application code determines how that data is handled in memory, logged, or passed to third-party services — a frequent source of accidental data leakage, for example logging sensitive fields in plaintext.

6.4 Transmission between services

Data frequently moves between microservices, regions, or third-party integrations. The provider secures its internal backbone network. The customer is responsible for configuring encryption in transit for anything crossing a boundary they control, including calls to external APIs.

6.5 Archival and retention

Long-term archival storage tiers are secured physically by the provider. The customer decides retention duration, and whether archived data must remain encrypted with customer-managed keys for compliance reasons such as financial record-keeping requirements.

6.6 Deletion and disposal

When a customer deletes data, the provider is responsible for the secure physical disposal or overwriting of decommissioned storage media so that data cannot be recovered by a future tenant of that hardware. The customer is responsible for actually issuing the deletion request in the first place, and for making sure backups or replicas they control are also purged in line with their own data retention obligations.

The model is powerful precisely because it forces every decision to be an explicit trade-off — between how much of the stack you want to control and how much of the operational burden you are willing to carry.

7.1 Advantages of the shared responsibility model

7.2 Trade-off: control vs. operational burden

7.3 Deliberately shifting the line as an architectural strategy

Experienced architects sometimes treat the responsibility line itself as a lever they can pull deliberately. A small engineering team with limited dedicated security staff might intentionally favor managed, higher-level services — accepting less low-level control in exchange for offloading patching, hardening, and much of the operational security burden onto the provider. A large enterprise with a mature, well-staffed security organization might instead choose lower-level services precisely because it wants fine-grained control over configuration that a fully managed SaaS product would not expose. Neither choice is inherently right; the skill lies in matching the chosen service model to the organization’s actual capacity to handle the responsibility that model leaves on the customer’s side of the line.

This same lever also applies over time, not just at initial design. A startup might deliberately begin on heavily managed services to move quickly with a small team, then gradually take on more customer-side responsibility as it grows a dedicated platform or security function capable of handling lower-level infrastructure safely. Revisiting this trade-off periodically, rather than treating an early architectural choice as permanent, is itself a mark of a mature engineering organization.

The shared responsibility model itself is not a performance feature, but the way responsibilities are split has real performance and scalability implications worth understanding.

8.1 Provider-side scaling guarantees

Because the provider owns the physical and virtualization layers, they are also responsible for ensuring that layer scales to meet demand — adding more physical capacity, maintaining network throughput, and ensuring the hypervisor does not become a bottleneck as more tenants share the same hardware. Customers benefit from this scaling without having to provision physical hardware themselves.

8.2 Customer-side scaling responsibility

However, everything above the responsibility line — how an application is architected to scale, how a database schema is indexed, how caching is used — remains the customer’s job. A poorly designed application will not scale well no matter how much elastic infrastructure the provider offers underneath it. Autoscaling groups, load balancer configuration, and connection pool sizing are customer-owned decisions in most service models.

8.3 Security controls and performance overhead

Security responsibilities the customer owns, such as enabling TLS everywhere, using strict IAM policy checks on every request, or running intrusion detection agents, all introduce some performance overhead. Balancing this overhead against risk tolerance is itself a customer-side architectural decision — the provider does not choose your trade-off for you.

High availability is another area where responsibilities interleave closely, and it is a frequent source of confusion because “the provider had an outage” and “my application went down” are not always the same event.

9.1 What the provider guarantees

Cloud providers publish Service Level Agreements (SLAs) promising a certain percentage of uptime for individual services, along with the physical redundancy (multiple availability zones, backup power, redundant networking) needed to achieve it. This is squarely the provider’s responsibility — they must engineer their data centers and regions to survive hardware failures, power outages, and even entire facility losses without service interruption.

9.2 What the customer must still design for

Provider-level redundancy does not automatically make a customer’s own application highly available. If a customer deploys their entire application into a single availability zone, or a single region, they remain fully exposed to an outage in that zone even though the provider offered multiple zones to choose from. Designing multi-zone or multi-region deployments, configuring health checks, and implementing failover logic are customer responsibilities.

// Example: customer-owned failover logic when a primary
// region-specific service becomes unavailable.
// The PROVIDER guarantees each region's underlying infrastructure;
// the CUSTOMER must decide how their application reacts to a region failure.
public class RegionFailoverClient {

    private final String primaryEndpoint;
    private final String secondaryEndpoint;
    private final HttpClient httpClient;

    public RegionFailoverClient(String primaryEndpoint,
                                 String secondaryEndpoint,
                                 HttpClient httpClient) {
        this.primaryEndpoint   = primaryEndpoint;
        this.secondaryEndpoint = secondaryEndpoint;
        this.httpClient        = httpClient;
    }

    public HttpResponse<String> callWithFailover(HttpRequest.Builder requestBuilder)
            throws IOException, InterruptedException {
        try {
            HttpRequest primaryRequest = requestBuilder
                    .uri(URI.create(primaryEndpoint))
                    .timeout(Duration.ofSeconds(2))
                    .build();
            return httpClient.send(primaryRequest, HttpResponse.BodyHandlers.ofString());
        } catch (IOException | HttpTimeoutException primaryFailure) {
            // Primary region unreachable -- fail over to secondary region.
            HttpRequest secondaryRequest = requestBuilder
                    .uri(URI.create(secondaryEndpoint))
                    .timeout(Duration.ofSeconds(2))
                    .build();
            return httpClient.send(secondaryRequest, HttpResponse.BodyHandlers.ofString());
        }
    }
}

9.3 Backups: a frequently missed customer responsibility

Many customers assume that because a provider guarantees durability of stored data (multiple physical copies), they do not need their own backups. Durability protects against hardware failure; it does not protect against a customer accidentally deleting data, an application bug corrupting records, or a malicious actor wiping a database. Backup strategy, retention, and restore testing remain a customer responsibility even for the most durable managed storage services.

9.4 Disaster recovery planning

Disaster recovery (DR) plans — defining recovery point objectives and recovery time objectives, and rehearsing failover — are customer-owned artifacts. The provider gives you the building blocks (multiple regions, snapshot tools, replication services), but assembling them into a tested DR plan for your specific application is your job.

9.5 Chaos testing your own assumptions

A mature way to validate that your side of the availability responsibility is genuinely solid is to deliberately inject failure into your own environment — terminating instances, cutting off a simulated availability zone, or throttling a dependency — and observing whether your application degrades gracefully or falls over completely. This practice, often called chaos engineering, exists precisely because provider-level redundancy guarantees are only half the story; the other half is whether your own application was actually built to take advantage of that redundancy. Many teams discover, only through this kind of deliberate testing, that a supposedly multi-zone deployment still has a single point of failure hiding in a shared configuration value, a hardcoded endpoint, or a dependency that was never actually made redundant.

This section is the heart of the tutorial: a layer-by-layer breakdown of exactly which security controls belong to whom, with concrete technical detail for each.

10.1 Physical security — Provider

Biometric access control, 24/7 surveillance, perimeter fencing, and staff background checks at data center facilities are entirely provider-owned. No customer, no matter how large, is given physical access to audit a public cloud provider’s data center floor.

10.2 Network infrastructure security — Provider

The physical network backbone, DDoS mitigation at the edge of the provider’s network, and hardware-level network isolation between tenants are provider responsibilities. Providers invest heavily in global anti-DDoS infrastructure that would be prohibitively expensive for most individual companies to replicate.

10.3 Hypervisor and virtualization security — Provider

Ensuring that a vulnerability cannot allow one customer’s virtual machine to read another customer’s memory or storage is one of the provider’s most critical and continuously tested responsibilities. This includes patching hypervisor vulnerabilities the moment they are discovered, often before public disclosure.

10.4 Identity and access management — Customer

While the provider builds a robust IAM engine, the customer must:

• Apply the principle of least privilege — granting only the permissions a user or service actually needs.
• Enable multi-factor authentication for all human accounts, especially privileged administrator accounts.
• Rotate and never hardcode long-lived credentials in source code.
• Use short-lived, scoped roles for machine-to-machine access instead of static keys wherever possible.
• Regularly audit unused accounts, stale permissions, and overly broad wildcard policies.

// Example: enforcing least-privilege by validating a requested
// IAM policy document before it is applied -- a customer-owned
// guardrail, since the provider will happily apply an overly broad
// policy if the customer submits one.
public class LeastPrivilegeValidator {

    private static final String WILDCARD_ACTION   = "*";
    private static final String WILDCARD_RESOURCE = "*";

    public void validate(IamPolicyStatement statement) {
        if (WILDCARD_ACTION.equals(statement.getAction())
                && WILDCARD_RESOURCE.equals(statement.getResource())) {
            throw new PolicyRejectedException(
                "Refusing to apply a policy granting all actions on all resources. "
              + "Scope the action and resource explicitly.");
        }

        if (statement.isAdminAction() && !statement.requiresMfa()) {
            throw new PolicyRejectedException(
                "Administrative actions must require multi-factor authentication.");
        }
    }
}

10.5 Data encryption — Shared, with customer choices dominant

The provider supplies the cryptographic infrastructure: hardware security modules, key management services, and encryption libraries built into their storage and database services. The customer decides:

• Whether to enable encryption at rest (in some services this is opt-in, though increasingly providers enable it by default).
• Whether to use provider-managed keys or customer-managed keys for greater control over key rotation and revocation.
• Whether application-layer encryption is needed for especially sensitive fields, on top of infrastructure-level encryption.
• How TLS is configured for data in transit, including minimum supported protocol versions.

10.6 Application security — Customer

Everything related to how the customer’s own code behaves is customer responsibility: input validation, protection against injection attacks, secure session management, dependency vulnerability scanning, and secure handling of secrets. A cloud provider cannot secure a SQL injection vulnerability inside code the customer wrote and deployed.

10.7 Guest operating system security — Customer (IaaS only)

For virtual machines, the customer is responsible for applying operating system patches, configuring host-based firewalls, running endpoint detection tools, and hardening the OS according to security benchmarks. In PaaS and SaaS models, this responsibility shifts to the provider.

10.8 Network configuration within the customer’s account — Customer

Virtual network design, subnet segmentation, security group and network access control list rules, and whether resources are exposed to the public internet at all are entirely customer decisions. The provider gives you the tools to build a private, segmented network; whether you actually use them correctly is up to you.

10.9 Third-party and supply chain security — Customer

Any third-party libraries, container base images, or software-as-a-service integrations the customer chooses to use are the customer’s responsibility to vet, patch, and monitor for known vulnerabilities, even though they might be pulled from a public repository hosted by yet another provider.

10.10 Containers and Kubernetes — a nuanced split

Container orchestration platforms deserve special attention because the responsibility boundary within a managed Kubernetes service is more layered than a simple IaaS/PaaS split suggests. Consider a managed Kubernetes offering:

• Provider-managed: the Kubernetes control plane itself — the API server, scheduler, and etcd data store that coordinates the cluster — including patching known control-plane vulnerabilities and ensuring the control plane’s own high availability.
• Customer-managed: the worker nodes’ operating system (unless using a fully serverless container option), what container images are deployed, how pods are configured (including whether they run with excessive privileges), network policies between pods, and secrets mounted into containers.
• Always customer-managed regardless of provider: the contents of the container images themselves — vulnerable base images, outdated dependencies, or hardcoded secrets baked into a layer are entirely the customer’s responsibility to catch before deployment.

// Example: a customer-owned admission check that rejects
// Kubernetes pod specifications requesting privileged mode,
// a common misconfiguration that widens the attack surface
// far beyond what the managed control plane can protect against.
public class PrivilegedPodAdmissionCheck {

    public void validate(PodSpec podSpec) {
        for (Container container : podSpec.getContainers()) {
            SecurityContext context = container.getSecurityContext();

            if (context != null && context.isPrivileged()) {
                throw new AdmissionRejectedException(
                    "Container '" + container.getName() + "' requests privileged mode. "
                  + "Privileged containers can access the host system directly and "
                  + "must be explicitly justified and approved.");
            }

            if (context == null || context.allowsPrivilegeEscalation()) {
                throw new AdmissionRejectedException(
                    "Container '" + container.getName() + "' must explicitly disable "
                  + "privilege escalation.");
            }
        }
    }
}

This nuance illustrates an important general principle: even within a single managed service, there can be multiple sub-layers, each with its own owner. Treating “Kubernetes security” as a single monolithic responsibility, owned entirely by either side, is itself a common source of gaps.

10.11 Serverless functions — the narrowest customer surface, not a zero surface

Serverless compute (Function as a Service) offerings push the responsibility line further toward the provider than almost any other model — there is no server, virtual machine, or container host for the customer to patch at all. Yet the customer remains responsible for the function’s own code, the permissions granted to the function’s execution role, how secrets are retrieved at runtime, and validating any input the function receives. Serverless breaches overwhelmingly trace back to an overly permissive execution role or a vulnerability in the function’s own logic — the same customer-side pattern seen throughout this tutorial, just at a smaller surface area.

Visibility into what is happening in a cloud environment is itself split by the shared responsibility model, and getting this split wrong is a very common gap.

11.1 Infrastructure-level monitoring — Provider

Providers monitor the health of their own physical and virtualization infrastructure continuously — hardware failures, network congestion, and hypervisor anomalies are detected and remediated by the provider’s own operations teams, often before customers notice any impact.

11.2 Account and resource-level logging — Customer must enable and review

Providers typically offer detailed audit logging services that record every API call made within a customer’s account — who did what, when, and from where. Crucially, in most cases, the customer must explicitly enable this logging, configure where logs are stored, set an appropriate retention period, and — most importantly — actually review or alert on them. A provider will not proactively tell a customer “someone in your account just disabled logging” unless the customer has configured a system to detect that.

// Example: a lightweight Java job that checks whether audit logging
// is currently enabled for the account -- a customer responsibility,
// since disabled logging is a common precursor to undetected breaches.
public class AuditLoggingHealthCheck {

    private final CloudTrailClient cloudTrailClient;

    public AuditLoggingHealthCheck(CloudTrailClient cloudTrailClient) {
        this.cloudTrailClient = cloudTrailClient;
    }

    public void assertLoggingEnabled(String trailName) {
        GetTrailStatusResponse status = cloudTrailClient.getTrailStatus(
                GetTrailStatusRequest.builder().name(trailName).build());

        if (!status.isLogging()) {
            throw new SecurityConfigurationException(
                "Audit trail '" + trailName + "' is disabled. "
              + "This is a customer-owned control under the shared responsibility model "
              + "and must be re-enabled immediately.");
        }
    }
}

11.3 Application-level metrics and alerting — Customer

Metrics about application behavior — error rates, latency, unusual traffic spikes indicative of an attack, failed login attempts — must be instrumented and alerted on by the customer. The provider may offer the underlying metrics platform, but deciding what “normal” looks like for your specific application, and what threshold should trigger an alert, is a customer judgment call.

11.4 Compliance evidence collection — Customer

During an audit, the customer must produce evidence that they reviewed logs, responded to alerts, and maintained access records for their own environment. Provider-side audit certifications only cover the provider’s layer; the customer must maintain their own evidence trail for the layers they control.

11.5 Alert fatigue and tuning — Customer

Enabling logging and metrics is only the first step; a stream of alerts nobody reads or trusts is functionally the same as having no alerts at all. Tuning alert thresholds so that they are sensitive enough to catch genuine anomalies but not so noisy that engineers begin ignoring them is an ongoing, customer-owned discipline. Providers can supply the raw telemetry and the alerting infrastructure, but deciding what “too many failed login attempts” or “too much outbound data transfer” means for your specific application requires domain knowledge only the customer possesses.

The shared responsibility model also varies depending on the broader deployment model chosen — public cloud, private cloud, hybrid cloud, or on-premises — and it is worth mapping these out explicitly since they are frequently confused with the service models (IaaS/PaaS/SaaS) discussed earlier.

12.1 Public cloud

The scenario this entire tutorial has focused on: a third-party provider owns and operates shared infrastructure, and the responsibility line is defined by the service model (IaaS, PaaS, or SaaS) chosen within that public cloud.

12.2 Private cloud

Infrastructure dedicated to a single organization, sometimes hosted on the organization’s own premises and sometimes hosted by a provider but not shared with other tenants. Here, the customer organization typically takes on a much larger share of physical and infrastructure-level responsibility than in public cloud, since there is no multi-tenant provider absorbing that burden the same way.

12.3 Hybrid cloud

A mix of public cloud and private/on-premises infrastructure, connected together. Responsibility boundaries must be mapped separately for each environment, and — critically — the customer becomes responsible for securing the connections between environments, an integration point neither environment’s provider fully owns.

12.4 On-premises (for comparison)

No shared responsibility model exists in a traditional on-premises setup because there is no cloud provider; the organization owns responsibility for every layer, from the physical building to the application code. Understanding this baseline helps clarify exactly how much the shared responsibility model actually offloads once an organization migrates to the cloud.

12.5 Choosing a deployment and service model together

In practice, architects choose a combination — for example, running most workloads as PaaS in a public cloud, while keeping a small set of highly regulated workloads in a private cloud connected via a hybrid network link. Each combination redraws the responsibility map, so documenting it explicitly per workload is essential rather than relying on a single blanket assumption for the entire organization.

12.6 Function as a Service — the fourth service model

Beyond IaaS, PaaS, and SaaS, many architects now recognize Function as a Service (FaaS), or serverless computing, as a distinct point on the spectrum, sitting even further toward full provider management than typical PaaS. The provider handles server provisioning, scaling individual function invocations up and down automatically, and patching the underlying execution environment between deployments. The customer’s remaining surface narrows down almost entirely to function code, its configuration, and the permissions attached to it — but as discussed earlier in the security deep dive, that narrow surface is still very much the customer’s to secure.

Data-layer services are where the shared responsibility model gets tested most often in day-to-day engineering work, because these are the services developers touch constantly.

13.1 Managed databases

With a managed relational or NoSQL database service, the provider handles patching the database engine, automated-backups infrastructure, underlying storage durability, and often high-availability failover mechanics. The customer remains responsible for:

• Network access rules controlling which resources can even reach the database.
• Database-level user accounts, roles, and permissions (separate from cloud IAM).
• Whether encryption at rest and in transit is enabled for that specific database instance.
• Schema design, query performance, and indexing strategy.
• Actually testing that automated backups can be restored successfully.

// Example: customer-owned check that a database is not
// reachable from the public internet -- a classic
// misconfiguration that caused several well-known breaches.
public class DatabaseExposureAudit {

    private final RdsClient rdsClient;

    public DatabaseExposureAudit(RdsClient rdsClient) {
        this.rdsClient = rdsClient;
    }

    public List<String> findPubliclyAccessibleInstances() {
        DescribeDbInstancesResponse response = rdsClient.describeDBInstances();

        return response.dbInstances().stream()
                .filter(DbInstance::publiclyAccessible)
                .map(DbInstance::dbInstanceIdentifier)
                .collect(Collectors.toList());
    }
}

13.2 Unmanaged databases (self-hosted on a virtual machine)

If instead the customer installs a database engine themselves on an IaaS virtual machine, the responsibility line shifts significantly: the customer now also owns patching the database software itself, configuring its own backup jobs, and hardening the operating system it runs on. This is a common trade-off decision — more control, but a much larger share of the security and operational burden.

13.3 Caching layers

Managed caching services (in-memory data stores used to speed up applications) follow a similar pattern: the provider secures the underlying nodes and, often, encryption in transit between the application and the cache. The customer decides access control to the cache, whether sensitive data should even be cached, and appropriate expiration policies, since cached data can sometimes persist longer than the customer expects.

13.4 Load balancers

Managed load balancing services handle the underlying distribution infrastructure, health-check engine reliability, and often automatic TLS certificate renewal if configured to do so. The customer configures which backend targets receive traffic, what security policies (such as minimum TLS version) are enforced, and which network paths are allowed to reach the load balancer in the first place.

Modern applications are rarely a single monolith; they are collections of services communicating over APIs, often through an API gateway. The shared responsibility model applies here too, layer by layer.

14.1 API gateway infrastructure — Provider

If using a managed API gateway service, the provider secures the gateway’s own infrastructure, ensures it scales to handle traffic spikes, and keeps the gateway software itself patched.

14.2 API authentication and authorization — Customer

Deciding how each API endpoint authenticates callers (API keys, OAuth tokens, mutual TLS), and which endpoints require which permission scopes, is entirely a customer design decision. A managed gateway can enforce whatever rules the customer configures, but it will not invent secure defaults on its own.

// Example: a simple customer-owned authorization filter for a
// microservice, verifying a caller's token scope before allowing
// access to a sensitive endpoint. The gateway infrastructure below
// this code is provider-managed; the logic itself is customer-owned.
public class ScopeAuthorizationFilter implements Filter {

    private static final String REQUIRED_SCOPE = "orders:write";

    @Override
    public void doFilter(ServletRequest request,
                          ServletResponse response,
                          FilterChain chain) throws IOException, ServletException {

        HttpServletRequest  httpRequest  = (HttpServletRequest)  request;
        String token = httpRequest.getHeader("Authorization");

        if (token == null || !TokenValidator.hasScope(token, REQUIRED_SCOPE)) {
            HttpServletResponse httpResponse = (HttpServletResponse) response;
            httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN,
                    "Missing required scope: " + REQUIRED_SCOPE);
            return;
        }

        chain.doFilter(request, response);
    }
}

14.3 Inter-service communication in microservices — Customer

In a microservices architecture, the provider secures the underlying network fabric connecting compute resources, but the customer decides whether service-to-service traffic is encrypted, whether services authenticate each other (rather than blindly trusting any caller on the internal network), and how service identity is verified — often through a customer-configured service mesh.

14.4 Rate limiting and abuse protection — Shared

Providers often offer infrastructure-level DDoS protection and basic rate-limiting tools at the network edge. The customer must configure application-specific rate limits — for example, preventing one authenticated user from making an excessive number of expensive requests — since the provider has no visibility into what “abusive” behavior looks like for that specific business logic.

14.5 Third-party API integrations — Customer

Whenever a customer’s microservice calls an external, third-party API, the customer is responsible for securely storing that third party’s credentials, validating the responses received, and handling failures gracefully. No cloud provider is involved in securing a relationship between the customer and an unrelated third-party vendor.

14.6 API schema validation and input handling — Customer

A managed API gateway can enforce that requests conform to a schema the customer defines, reject malformed payloads, and apply basic size or rate limits. But writing that schema, deciding which fields are required, and choosing how strictly to validate incoming data is a customer design decision. A gateway configured to accept an overly permissive schema will happily forward malicious payloads straight through to backend services, where the customer’s own application code becomes the last line of defense.

14.7 Observability across service boundaries — Customer

In a distributed microservices architecture, tracing a single user request as it hops across a dozen services is essential both for debugging and for spotting anomalous behavior that could indicate an attack in progress. Providers may offer distributed tracing infrastructure, but instrumenting each service to propagate trace identifiers correctly, and deciding what constitutes suspicious cross-service behavior, remains squarely a customer engineering responsibility.

A short round-up of the patterns mature cloud teams converge on for their side of the boundary, and the anti-patterns that reliably produce the breaches you read about.

15.1 Pattern: Least-privilege by default

Start every new role, service account, or API key with zero permissions, and add only the specific permissions required, rather than starting broad and trying to narrow down later. This pattern directly addresses the customer’s core IAM responsibility.

15.2 Pattern: Policy as code

Define IAM policies, network rules, and encryption settings as version-controlled infrastructure code rather than manual console clicks. This makes the customer’s half of the responsibility boundary auditable, reviewable, and reproducible — turning an implicit assumption into an explicit, testable artifact.

15.3 Pattern: Defense in depth across the boundary

Do not rely on a single control at the responsibility line. Combine network-level restrictions, IAM policy restrictions, and application-level authorization checks, so that a single customer-side misconfiguration does not immediately translate into a breach.

15.4 Pattern: Automated configuration-drift detection

Continuously scan the customer-owned configuration layer (storage permissions, security groups, IAM policies) for drift away from an approved secure baseline, and alert immediately when drift is detected — this is exactly the kind of tool Netflix’s internal security tooling and many commercial “cloud security posture management” products are built to do.

15.5 Anti-pattern: “The cloud is secure, so we’re secure”

Treating a provider’s marketing claims or compliance certifications as a substitute for configuring your own environment correctly. This is the single most common root cause of cloud breaches discussed throughout this tutorial.

15.6 Anti-pattern: Wildcard permissions “just to get it working”

Granting broad, unrestricted permissions during development with the intention of tightening them later, and then never actually tightening them before shipping to production.

15.7 Anti-pattern: Treating internal network traffic as automatically trusted

Assuming that because traffic originates from inside the customer’s own virtual network, it does not need authentication between services. Modern architecture increasingly assumes zero trust — verifying every request regardless of its network origin — precisely because internal network boundaries are a customer-owned control, not an inherently trustworthy one.

15.8 Anti-pattern: No ownership mapping

Using dozens of cloud services without ever documenting, even informally, which team member or process is responsible for reviewing each service’s customer-side configuration. This anti-pattern is an organizational failure as much as a technical one.

A compact, portable checklist for keeping your side of the boundary healthy year-round — and the recurring mistakes that quietly cause the majority of preventable cloud incidents.

16.1 Best practices

• Read the provider’s specific shared responsibility documentation for every service you use — the exact boundary can differ subtly between, for example, a managed database and a managed container platform from the same provider.
• Enable and centralize audit logging from day one, not after an incident makes you wish you had.
• Apply least privilege everywhere, and review permissions on a recurring schedule, not just when something breaks.
• Encrypt data at rest and in transit by default, and use customer-managed keys for your most sensitive data categories.
• Automate configuration checks so that customer-side misconfigurations are caught by tooling, not by an attacker.
• Test backups and disaster recovery plans regularly — an untested backup is only a hypothesis.
• Document responsibility ownership per service and per team, so that during an incident nobody has to guess who should be paged.
• Treat every third-party integration and dependency as part of your side of the boundary, and vet it accordingly.

16.2 Common mistakes

• Leaving storage resources publicly accessible by default, or by accident during a quick test that was never reverted.
• Hardcoding credentials in source code or configuration files instead of using the provider’s secret management tools.
• Disabling audit logging to reduce cost, without weighing the security visibility that is lost.
• Assuming replication equals backup, and discovering otherwise only after accidental data loss.
• Granting broad administrative roles to automated pipelines that only ever need a narrow set of permissions.
• Failing to rotate long-lived access keys, leaving stale credentials as a standing risk for years.
• Not validating the security posture of container images or open-source dependencies before deploying them into production.
• Confusing compliance inheritance with full compliance, and skipping customer-side audit evidence collection entirely.

16.3 A practical onboarding checklist

Whenever your team adopts a new managed cloud service, work through this checklist before sending real traffic or real data to it. It condenses everything covered in this tutorial into a repeatable, concrete process rather than an abstract principle you have to remember from scratch every time.

• Read the provider’s documented responsibility split for this specific service, not a generic summary from memory.
• Confirm encryption at rest is enabled, and decide whether provider-managed or customer-managed keys are appropriate for the data involved.
• Confirm encryption in transit is enforced, including the minimum acceptable protocol version.
• Create a dedicated, narrowly scoped identity or role for this service rather than reusing an existing broad-permission role.
• Explicitly verify the service is not publicly reachable unless that is an intentional, reviewed design decision.
• Enable audit logging for the service and route those logs into your existing centralized monitoring pipeline.
• Define and document a backup or data-recovery approach, and calendar a date to actually test a restore.
• Record, in your team’s shared responsibility tracking document, exactly what your team owns for this service and who owns it.

The same pattern shows up across every industry and every company size: the provider’s infrastructure performs as engineered, and every preventable incident traces back to how the customer’s half of the model was handled.

17.1 Financial services: the metadata service breach

A widely studied 2019 breach involved a major financial institution running workloads on public cloud infrastructure. An attacker exploited a misconfigured web application firewall to perform a server-side request forgery attack, reaching the cloud provider’s internal metadata service and extracting temporary credentials associated with an overly permissive role. Those credentials were then used to access and exfiltrate data from cloud storage containing over 100 million customer records. The cloud provider’s own infrastructure functioned exactly as designed throughout; the failure occurred entirely within the customer’s configuration and application security responsibilities — an object lesson in how the shared responsibility model plays out in practice.

17.2 Netflix: proactive customer-side tooling

Netflix runs the vast majority of its streaming infrastructure on public cloud compute. Rather than assuming the provider’s security posture was sufficient, Netflix’s engineering teams built internal open-source tools specifically to continuously audit their own customer-side configuration — monitoring IAM policies, security group rules, and storage permissions for risky changes in near real time. This reflects a mature organizational understanding that the provider’s infrastructure security and the customer’s configuration security are two entirely separate ongoing efforts.

17.3 Healthcare and regulated industries

Healthcare organizations using cloud infrastructure to store patient data must satisfy regulations that hold the organization itself accountable for data protection, regardless of which infrastructure it runs on. Providers typically offer a business associate agreement or equivalent contractual commitment covering their own infrastructure-layer obligations, but the healthcare organization remains fully responsible for access controls, encryption choices, and audit logging on their own side of the boundary — compliance certification of the underlying platform does not transfer compliance obligations away from the customer.

17.4 Retail and e-commerce at scale

Large e-commerce companies operating during high-traffic shopping events depend heavily on the provider’s elastic infrastructure scaling automatically underneath them. At the same time, these companies invest significant engineering effort into their own side of the boundary: rate-limiting checkout endpoints against bot-driven inventory hoarding, encrypting stored payment tokens, and rigorously testing failover between regions — illustrating how both halves of the shared responsibility model must function well together for a smooth customer experience during peak load.

17.5 Startups: the cost of skipping the customer side

A recurring pattern among early-stage startups is standing up cloud infrastructure quickly under time pressure, deferring identity and access hardening “until later,” and later discovering an exposed database or storage bucket during a routine security review — or worse, during an actual incident. This pattern underscores that the shared responsibility model is not a theoretical compliance topic; it has direct, practical consequences from the very first day a workload goes live, regardless of company size.

17.6 SaaS supply chain: when a vendor’s customer-side mistake affects you

An increasingly common scenario involves organizations that consume a third-party SaaS product, which in turn runs on top of a public cloud provider. If that SaaS vendor mismanages its own customer-side responsibilities — for instance, misconfiguring the identity policies protecting its own backend infrastructure — the resulting breach can expose data belonging to every one of that vendor’s customers simultaneously, even though none of those downstream customers made any mistake themselves. This layered reality is why security-conscious organizations increasingly ask their own SaaS vendors detailed questions about how those vendors handle their own half of the shared responsibility model with the cloud provider beneath them, rather than assuming that “SaaS” alone is a sufficient answer to “is our data safe with this vendor.”

Fast, opinionated answers to the questions that come up first when teams are just starting to internalize the shared responsibility model — followed by a compact summary and the ideas worth carrying away into every design conversation.

Summary

The shared responsibility model is the framework that divides cloud security duties between the provider, who secures the shared physical and virtualization infrastructure, and the customer, who secures their own data, identity configuration, and application logic built on top of it. The exact position of that dividing line shifts depending on whether you consume Infrastructure as a Service, Platform as a Service, Software as a Service, or Function as a Service, but a customer-owned portion always remains, no matter how managed the service becomes. Every real-world case study examined in this tutorial traces back to the same lesson: cloud providers overwhelmingly secure their own layer correctly, and the overwhelming majority of preventable incidents occur within the customer’s own configuration and code.

For a software architect or engineer, the practical value of internalizing this model goes well beyond passing a certification exam. It changes how you evaluate a new managed service, how you write a design document, and how you respond when something goes wrong in production. Instead of a vague worry about “cloud security” as an undifferentiated risk, you gain a precise, layer-by-layer map you can walk through for any workload: what does the provider guarantee here, and what have I explicitly configured, coded, or tested myself? That single habit of thought, applied consistently across every service your team adopts, is what separates organizations that read about cloud breaches in the news from organizations that quietly avoid becoming one.