Shared Responsibility Model

Concepts Covered

• Security of the cloud
• Security in the cloud
• Customer data responsibility
• Infrastructure service responsibility
• Managed service responsibility
• Identity and access management
• Patch management
• Encryption and key ownership
• Configuration mistakes
• Exam traps around managed services

1. Plain-English Definition

The shared responsibility model explains which security and operational responsibilities belong to AWS and which belong to the customer.

The common phrase is:

AWS is responsible for security of the cloud.
Customers are responsible for security in the cloud.

AWS operates the global infrastructure: facilities, hardware, physical networking, and the foundational services that make the cloud work. Customers decide what to build on top: accounts, identities, networks, compute, storage, databases, data access, encryption choices, application code, logging, and configurations.

The boundary changes depending on the service. On EC2, you manage more of the stack. On RDS, AWS manages the database infrastructure and many operational tasks. On S3, there is no server for you to patch, but you still control bucket policies, object permissions, encryption choices, lifecycle rules, and data classification.

The model is not a slogan. It is a checklist for every architecture decision.

2. Why This Matters In AWS

AWS can remove a lot of undifferentiated work, but it cannot decide your business security posture for you.

AWS can protect the physical data centers. It cannot know whether a bucket should be public. AWS can offer encryption. It cannot always decide which keys you should use or who should decrypt the data. AWS can provide IAM. It cannot know which engineer should have production access. AWS can patch managed service infrastructure. It cannot fix insecure application code that you deploy.

For the exam, this matters because many wrong answers over-transfer responsibility to AWS. The fact that a service is managed does not mean the customer has no security duties. The customer usually owns data classification, identity, resource policies, network exposure, encryption configuration, logging choices, and application-level behavior.

For real architecture, this model prevents expensive misunderstandings. A team may move to cloud expecting automatic security, then discover that misconfigured access, missing backups, weak IAM, or public endpoints are still their responsibility.

3. The Beginner Mental Model

Imagine renting an apartment in a secure building.

The building owner handles the foundation, elevators, outer walls, main utilities, and physical security for common areas. You still lock your apartment door, decide who has a key, protect your valuables, choose what furniture goes inside, and avoid leaving private documents in the hallway.

AWS is the building owner. Your workload is the apartment.

The more managed the service, the more AWS handles below you. But you still own what you put into the service and how you expose it.

For EC2:

AWS: physical host, facility, global infrastructure
Customer: OS choices, patching, security groups, data, app, access

For RDS:

AWS: database infrastructure, managed patching options, backups machinery
Customer: schema, data, users, network access, encryption choices

For S3:

AWS: storage platform durability and infrastructure
Customer: bucket policies, data, encryption settings, lifecycle, public access

4. What That Mental Model Misses

The apartment analogy is useful, but AWS services vary more than apartments do.

First, there is a spectrum. Infrastructure services such as EC2 give you more control and more responsibility. Managed services such as RDS, DynamoDB, SQS, SNS, S3, and Lambda shift more operational responsibility to AWS, but not all customer responsibility disappears.

Second, configuration is a customer responsibility even when infrastructure is managed. Public access settings, security group rules, IAM policies, KMS key policies, backup retention, deletion protection, logging, and data lifecycle rules are design choices.

Third, responsibility can be shared within the customer organization. A platform team may own account guardrails. A security team may own monitoring. An application team may own code and data access. "Customer responsibility" does not always mean one person.

Fourth, compliance inheritance is not compliance completion. AWS provides compliant infrastructure and reports for many frameworks, but customers must still configure workloads, document controls, manage data, and prove their side of the model.

5. AWS Mechanics

The responsibility line is easiest to reason about by service type.

With EC2, AWS manages the facility, hardware, host virtualization, and service platform. You manage the guest operating system, patching, installed software, IAM permissions, security groups, network ACLs, encryption choices, backups, and application code.

With containers on ECS or EKS, responsibilities depend on whether you use EC2 launch type, Fargate, or managed control planes. Fargate removes host management, but you still own container images, IAM task roles, secrets, logs, and network exposure.

With RDS, AWS manages database infrastructure, storage platform behavior, backups machinery, failover mechanisms, and maintenance windows. You still choose engine settings, backup retention, Multi-AZ, encryption, parameter groups, users, schemas, and access paths.

With S3, AWS manages the storage service. You own bucket naming, object keys, policies, ACL choices if used, Block Public Access, versioning, lifecycle, replication, encryption settings, and who can read or write objects.

With IAM, AWS provides the identity system. You own policy design, least privilege, role trust policies, MFA requirements, federation, access reviews, and credential hygiene.

6. Architecture Examples

Consider a web app on EC2 with an RDS database.

AWS secures the data centers, physical servers, and managed service foundation. The customer configures the VPC, subnets, route tables, security groups, EC2 AMIs, operating system patches, application secrets, RDS access, database users, backup retention, encryption, and logging.

If the EC2 operating system is not patched, that is the customer's problem. If an RDS instance is publicly accessible and accepts traffic from anywhere, that is also the customer's problem. If a storage device fails underneath the managed platform, that is AWS's problem.

Now consider a static website on S3 and CloudFront.

There are no EC2 servers to patch. But the customer still chooses whether the bucket is public, whether CloudFront uses origin access controls, whether objects are encrypted, how logs are retained, and who can deploy new content.

The service got simpler. The responsibility did not vanish. It moved upward into configuration, identity, and data governance.

7. SAA-C03 Exam Signals

When a question asks who patches the guest operating system on EC2, the answer is the customer.

When a question asks who protects the physical data center, the answer is AWS.

When a question asks who controls access to objects in S3, the answer is the customer.

When a question asks who manages the underlying database host for RDS, the answer is AWS. But if the question asks who grants database users or configures encryption and network access, that is the customer.

When a question emphasizes "least operational overhead," a managed service may be preferred because AWS assumes more operations. But the customer still designs access, data protection, monitoring, and recovery.

8. Common Traps

Do not say "AWS is responsible for security" without saying which layer. That is too vague for architecture.

Do not assume managed means secure by default for your use case. Managed means AWS operates more of the infrastructure. You still configure the service.

Do not forget data. Customer data is almost always the customer's responsibility: classification, access, retention, deletion, encryption decisions, and legal handling.

Do not confuse AWS compliance programs with your workload compliance. AWS can provide controls for its side. You must implement and document your side.

Do not treat IAM as optional because a workload runs inside a private subnet. Network privacy and identity permissions are separate controls.

9. What To Learn Next

Next, study IAM Foundations. Shared responsibility tells you that customers own access decisions; IAM is the main AWS system for making those decisions.

Then study VPC Networking Model, because network placement and exposure are major parts of customer responsibility.

Official AWS references:

• AWS Shared Responsibility Model
• AWS Security Best Practices
• IAM User Guide