Skip to content

CONCEPT Cited by 4 sources

Shared Responsibility Model

The Shared Responsibility Model is AWS's contract-level framing for which party — AWS or the customer — is responsible for what parts of a running workload. The canonical short form is "AWS is responsible for security of the cloud; the customer is responsible for security in the cloud." But the real model is richer, and the responsibility line moves per service — different AWS services cut the line at different layers.

The layer ladder

From bottom to top, with each AWS service form drawing the line at a different level:

Layer Self-hosted on EC2 Standard EKS EKS Auto Mode Fargate / Lambda
Data center / hardware AWS AWS AWS AWS
Hypervisor AWS AWS AWS AWS
Guest OS customer customer AWS AWS
OS patching customer customer AWS AWS
Node lifecycle (creation / termination) customer customer (or managed nodegroups) AWS AWS
Cluster upgrade cadence n/a customer AWS n/a
Default add-ons n/a customer AWS n/a
K8s control plane n/a AWS AWS n/a
Node-pool policy (instance types, zones) customer customer customer n/a
Workload (Deployments, HPA, Services) customer customer customer customer
Application code customer customer customer customer
Disruption controls (PDBs, NDBs) customer customer customer (load-bearing) n/a

EKS Auto Mode is the important middle column — it shifts OS, patching, node lifecycle, add-on management, and cluster upgrade cadence from customer to AWS, without making the service fully serverless.

The load-bearing caveat: disruption controls

When AWS takes responsibility for "we will terminate and replace nodes on a schedule", the customer's retained responsibility is "my workloads must survive node replacement gracefully." For EKS Auto Mode this materialises as:

  • Pod Disruption Budgets (PDBs) — bound simultaneous pod terminations.
  • Node Disruption Budgets — bound concurrent node replacements.
  • Maintenance windows — pin when AWS is allowed to do the disruption.

Without these three, AWS's responsibility shift silently becomes "AWS will randomly take your service down." The line shifted, but a new contract surface appeared in the customer's lap.

See patterns/disruption-budget-guarded-upgrades.

Why the model is load-bearing in case-study posts

Case-study posts often describe the move in responsibility as the primary value of an adopted service:

  • "EKS Auto Mode … takes care of the patching of the underlying operating system (Bottlerocket), the different Amazon EKS add-ons installed by default, and the upgrade of the cluster, so Generali DevOps and Cloud team can focus on supporting their application teams." (Source: sources/2026-03-23-aws-generali-malaysia-eks-auto-mode)

The "expanded Shared Responsibility Model" phrasing is exactly the contract-level language of the framework being extended by a new service offering.

Seen in

  • sources/2026-03-23-aws-generali-malaysia-eks-auto-mode — canonical wiki reference. The post explicitly describes EKS Auto Mode's "expanded Shared Responsibility Model" as the architectural value. Generali's retained responsibility centers on disruption budgets and workload discipline (stateless-only + immutable pods).
  • sources/2026-03-31-aws-streamlining-access-to-dr-capabilities — applies the same framing to the resilience dimension (the canonical Shared Responsibility Model for Resiliency whitepaper). AWS provides the DR primitives (AWS Backup / AWS DRS / snapshots / replication); the customer retains orchestration, testing, and configuration translation — AWS Resilience Competency Partners (e.g. Arpio) package the retained-customer side as a managed service.
  • sources/2026-04-06-aws-unlock-efficient-model-deployment-simplified-inference-operator-setup-on-amazon-sagemaker-hyperpod — Kubernetes-operator-layer responsibility shift at the HyperPod Inference Operator (2026-04-06). Pre-2026 Helm shape: customer owns Helm-release lifecycle, dependency-version management, IAM-role creation, S3-bucket for TLS certs, VPC endpoint config, dependency add-on install. Post-2026 EKS add-on shape: AWS owns all of those; customer declares intent via the aws eks create-addon configuration blob. Named quantified friction reduction (no methodology): "hours before a single model can serve predictions" → "within minutes of cluster creation". Responsibility line moves one more layer into previously-customer-operated scaffolding on the same "responsibility line moves per service" axis as the EKS Auto Mode and Lambda points on the spectrum.
  • sources/2025-12-30-mongodb-server-security-update-december-2025 — security-patching responsibility axis realised across three MongoDB product tiers as three line positions. Atlas: MongoDB owns fleet-patching velocity end-to-end; CVE-2025-14847 deployed to "tens of thousands of customers / hundreds of thousands of instances" in ~6 days, before public disclosure. Enterprise Advanced: MongoDB ships the patched build, customer operates the rollout on its own cadence. Community Edition: patch + community-forum notification at public-CVE time, customer wholly owns deployment. Canonical three-tier realisation of the responsibility line on the security- patching axis — analogous to AWS's EC2-self-managed / EKS-standard / EKS-Auto-Mode / Fargate gradient on the infrastructure axis, for a database product. Companion pattern: patterns/rapid-fleet-patching-via-managed-service.
Last updated · 200 distilled / 1,178 read