CONCEPT Cited by 5 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 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-09-17-aws-building-cloud-native-pacs-on-aws — the security section of the cloud-native PACS reference architecture is framed explicitly under the shared responsibility model: AWS secures the cloud infrastructure, while the customer configures services, manages access, and implements audit controls (encryption at rest/in transit, KMS rotation, CloudTrail + S3 access-log audit, least-privilege IAM, Config monitoring) to meet HIPAA/GDPR and data residency obligations for sensitive DICOM patient data.
- 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-addonconfiguration 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: rapid-fleet-patching-via-managed-service.
Related¶
- managed-data-plane — the system-design primitive; Shared Responsibility is the contractual framing of the same shift.
- well-architected-framework — the companion design- review framework.
- systems/aws-lambda — the furthest-right extreme (AWS owns everything below the function).
- systems/eks-auto-mode — the canonical middle-column instance.
- disruption-budget-guarded-upgrades — the retained- customer-responsibility primitive when AWS owns node churn.
- rapid-fleet-patching-via-managed-service — the security-patching-axis pattern realising the managed side of the responsibility line.
- pre-disclosure-patch-rollout — the disclosure posture vendor-operated fleet-patching enables.
- fleet-patching — the operational capability on the managed-tier side of the line.
- maintenance-window — the customer-side contract that negotiates when vendor-side responsibility is exercised.
- concepts/coordinated-disclosure — the industry norm the security-patching responsibility split interacts with.
- systems/mongodb-atlas / systems/mongodb-community-edition — canonical three-tier (managed / EA / self-hosted) realisation of the responsibility line for a database product.
Merged aliases¶
shared-responsibility-model-platform