Lesson 036 · AWS Learning Path

AWS 036: Shared responsibility model

Anil Jalela · Published Jul 31, 2025 · 5 min read

The problem

A managed service fails a security review because the team assumes AWS handles every patch, permission, backup, and data-protection decision. Another team rebuilds controls that AWS already operates.

Shared responsibility changes with the service model and feature. It must be evaluated at the control level.

Final outcome

You will assign responsibilities for EC2, a managed relational database, and a highly abstracted service; identify shared and inherited controls; and produce a responsibility matrix with owner, evidence, and escalation.

The core boundary

AWS: security of the cloud
customer: security in the cloud

AWS operates facilities, physical hardware, networking, and the virtualization foundation. Customers select services and Regions, control identities and permissions, configure network access, protect data, and secure what they deploy.

The exact split depends on the service. The customer controls more layers on EC2 than on DynamoDB, but always retains data, identity, application, and configuration responsibilities relevant to the workload.

Responsibility changes by abstraction

"AWS patches it" does not mean the customer can ignore maintenance windows, engine versions, compatibility, testing, or application recovery.

Control categories

Inherited controls

The customer inherits controls AWS fully operates, such as physical environmental controls for AWS facilities.

Shared controls

AWS provides part of the control, and the customer implements its part. Patch management is shared because AWS patches infrastructure while the customer patches EC2 guest systems. Training and incident management also have provider and customer components.

Customer-specific controls

The customer determines requirements and implementation, such as classifying business data, approving user access, and defining application authorization.

Security is only one dimension

Shared responsibility also applies to:

• resilience;
• availability architecture;
• backup and restore;
• monitoring;
• cost;
• regulatory compliance;
• data lifecycle;
• incident response;
• application correctness.

AWS can make multiple Availability Zones available, but the customer decides whether and how a workload uses them. AWS can provide backup features, but the customer defines retention, access, restore testing, RTO, and RPO.

Scenario 1: EC2 web application

AWS operates data centers, physical hosts, and the virtualization layer. Customer responsibilities include:

• supported operating-system image;
• guest patches and hardening;
• application and dependencies;
• security groups and network paths;
• instance role;
• encryption choices;
• secrets;
• backups;
• logs, alarms, and incident response;
• multi-AZ architecture;
• termination and retained volumes.

An EC2 status check can report healthy infrastructure while the customer's application is vulnerable or unavailable.

Scenario 2: Amazon RDS

AWS manages underlying hosts and the database service infrastructure, including many routine engine and operating-system tasks according to the chosen engine and service behavior.

The customer still owns:

• engine and version selection;
• instance or capacity configuration;
• network placement and security groups;
• database users and authentication;
• parameter choices;
• schema, queries, and application behavior;
• encryption and key decisions;
• backup retention and restore validation;
• Multi-AZ and read-scaling choices;
• monitoring;
• data classification and deletion.

Do not assume a managed backup exists forever or meets the workload recovery objective.

Scenario 3: Amazon S3

AWS operates the distributed storage service. The customer controls:

• bucket and object access;
• public-access settings;
• IAM and bucket policies;
• encryption and key access;
• versioning and lifecycle;
• replication;
• object ownership;
• data classification;
• logging and monitoring;
• accidental deletion protection;
• application use of pre-signed URLs.

The absence of a server to patch does not remove authorization and data-governance risk.

Practical matrix

Create:

mkdir -p "$HOME/nitwings-aws/evidence/aws-036"

Create responsibility-matrix.md with at least these controls:

Do not write only "shared." State the exact action on each side.

Console evidence exercise

Read-only:

1. Open EC2 and inspect instance, volume, security-group, and status-check pages.
2. Open RDS and inspect database configuration categories without creating a database.
3. Open S3 and inspect account-level Block Public Access.
4. Open IAM and inspect the current principal type.
5. Open Billing and confirm the budget from AWS 025.

For each page, name one AWS-operated layer and one customer configuration visible there. An empty inventory still allows service-level responsibility analysis.

Incident scenario

An S3 bucket is accidentally made accessible to an unintended principal.

Do not answer only "customer fault." Analyze:

1. preserve and verify the finding;
2. identify the effective permission path;
3. restrict exposure using the smallest safe change;
4. assess whether data was accessed;
5. rotate affected credentials if needed;
6. preserve logs;
7. notify data and security owners;
8. correct preventive controls;
9. retest.

AWS operates S3 infrastructure. The customer configures the bucket and identity policies. AWS services can provide preventive and detective features, while the customer must enable, configure, monitor, and act on them.

Common misconceptions

Certification decision points

When the service becomes more abstracted, AWS manages more infrastructure. Customer responsibility shifts upward to configuration, code, identity, data, and governance. Choose a managed service to reduce undifferentiated operations, but validate which specific tasks it removes.

Exam scenarios often ask who patches the guest OS, who configures a security group, who protects data, or who maintains physical facilities. Read the service model before answering.

Completion gate

Pass when the matrix contains exact responsibilities, evidence, and owners for EC2, RDS, and S3; the learner distinguishes inherited, shared, and customer-specific controls; and the incident response assigns actions without treating the model as blame.

No AWS resources were changed.

Official sources

• AWS Shared Responsibility Model
• Shared responsibility for resiliency
• Security Pillar