← Fundamentals

▶ Play from here · 345 min

Starts this lesson and continues through 32 more to the end of certification prep.

The Shared Responsibility Model — and how the line moves for EC2, RDS, Lambda and S3

Why this lesson matters

"The AWS shared responsibility model" is a "Knowledge of" line in Task 1.1 (domain 1 page, fetched 2026-09-25). But the model is not a Domain 1 fact to memorise — it's a tool that answers a recurring question type: "Who must do X?" Who patches this? Who encrypts this? Whose fault is this open bucket? The answer depends on which service the stem named, and the whole skill is knowing where the line sits for that service.

The model, verbatim

From Shared Responsibility Model, fetched 2026-09-25:

"Security and Compliance is a shared responsibility between AWS and the customer. This shared model can help relieve the customer's operational burden as AWS operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall."

The two halves:

AWS responsibility "Security of the Cloud" — "AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services."

Customer responsibility "Security in the Cloud" — "Customer responsibility will be determined by the AWS Cloud services that a customer selects. This determines the amount of configuration work the customer must perform as part of their security responsibilities."

   CUSTOMER — security IN the cloud          (how much of this is yours depends on the service)
   ─────────────────────────────────
   customer data · IAM · encryption choices · network/firewall config
   applications · GUEST OS  ◄──────────────── the line that moves
   ═══════════════════════════════════════════════════════════════════
   AWS — security OF the cloud
   ─────────────────────────────────
   host OS · virtualization layer · hardware · networking · facilities
   Regions · Availability Zones · edge locations

The diagram's labels come from the page's own alt text: customer = "customer data, platform, applications, OS and firewall configuration, encryption, and traffic protection"; AWS = "software, compute, storage, database, networking, hardware/infrastructure, regions, availability zones, edge locations".

⚠️ Host OS vs guest OS is the whole model in two words. AWS owns the host OS and hypervisor. The guest OS — the one inside your instance — is yours on EC2. A distractor that says "AWS patches the operating system of your EC2 instance" is wrong on the page's first paragraph.

The page's own worked examples

The same page names two service types explicitly:

"a service such as Amazon Elastic Compute Cloud (Amazon EC2) is categorized as Infrastructure as a Service (IaaS) and, as such, requires the customer to perform all of the necessary security configuration and management tasks. Customers that deploy an Amazon EC2 instance are responsible for management of the guest operating system (including updates and security patches), any application software or utilities installed by the customer on the instances, and the configuration of the AWS-provided firewall (called a security group) on each instance."

"For abstracted services, such as Amazon S3 and Amazon DynamoDB, AWS operates the infrastructure layer, the operating system, and platforms, and customers access the endpoints to store and retrieve data. Customers are responsible for managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions."

That's lesson 1's IaaS/PaaS line, restated as security: whoever manages the OS is responsible for patching it.

Three kinds of control

Also from the SRM page, verbatim:

⚠️ "Shared" does not mean "both do the same thing". It means both do a thing, "in completely separate contexts". Patching is shared because AWS patches the infrastructure and you patch the guest.

How the line moves — four services

Each service's security chapter restates the model for itself. What follows is quoted from each, fetched 2026-09-25.

EC2 — the line is low; you own the guest OS

Security in Amazon EC2:

"Security in the cloud – Your responsibility includes the following areas:

• Controlling network access to your instances, for example, through configuring your VPC and security groups.
• Managing the credentials used to connect to your instances.
• Managing the guest operating system and software deployed to the guest operating system, including updates and security patches.
• Configuring the IAM roles that are attached to the instance and the permissions associated with those roles."

RDS — AWS takes the OS; you still own access, encryption choices and timing

Security in Amazon RDS lists what you do:

• "Run your DB instance in a virtual private cloud (VPC)… for the greatest possible network access control."
• "Use AWS Identity and Access Management (IAM) policies to assign permissions that determine who is allowed to manage Amazon RDS resources."
• "Use security groups to control what IP addresses or Amazon EC2 instances can connect to your databases."
• "Use Secure Socket Layer (SSL) or Transport Layer Security (TLS) connections…"
• "Use Amazon RDS encryption to secure your DB instances and snapshots at rest."
• "Use the security features of your DB engine to control who can log in to the databases."

And the line AWS draws for itself:

"You have to configure security only for your use cases. You don't have to configure security access for processes that Amazon RDS manages. These include creating backups, replicating data between a primary DB instance and a read replica, and other processes."

Who patches the OS on RDS? From Maintaining a DB instance:

"Periodically, Amazon RDS performs maintenance on Amazon RDS resources. … Maintenance most often involves updates to the following resources in your DB instance: Underlying hardware · Underlying operating system (OS) · Database engine version."

But the timing is partly yours, and so is one category of update:

"An optional update can be applied at any time. … RDS does not apply these updates automatically."

"A mandatory update is required and has an apply date. … After the specified apply date, Amazon RDS automatically upgrades the operating system for your DB instance… during one of your assigned maintenance windows."

"Staying current on all optional and mandatory updates might be required to meet various compliance obligations."

⚠️ So on RDS the line is not "AWS does all patching". AWS performs the OS and engine maintenance; you choose the maintenance window, and you must apply optional updates yourself or they stay pending. A stem that says "the security team requires the latest OS patches on the database" is asking you to apply pending maintenance, not to SSH in — you have no OS access to patch.

⚠️ The RDS pages I fetched do not contain an explicit sentence "customers cannot access the RDS host OS". The inference above (you can't SSH in to patch) follows from the maintenance model, but if you need it verbatim, read the RDS FAQ.

Lambda — AWS takes the runtime too; you own code, config, and the update mode

Understanding how Lambda manages runtime version updates:

"Lambda keeps each managed runtime up to date with security updates, bug fixes, new features, performance enhancements, and support for minor version releases. … By default, for functions using managed runtimes, Lambda applies runtime updates automatically. With automatic runtime updates, Lambda takes on the operational burden of patching the runtime versions."

And AWS gives Lambda its own shared-responsibility table, Understanding the shared responsibility model for Lambda runtime management:

⚠️ Container-image Lambda functions move the line back towards you. If you deploy Lambda as a container image, nobody patches your function's runtime unless you rebuild and redeploy it.

Data, from Data protection in AWS Lambda: "AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure." And: "Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3."

⚠️ I could not retrieve Lambda's main Security in AWS Lambda page (lambda-security.html returned an empty shell on 2026-09-25), and the Lambda pages I did fetch don't state in one sentence that AWS manages the operating system of the execution environment. The runtime tables above are verbatim; for the OS statement, read the Lambda security chapter.

S3 — the line is high; you own data, access and detection

Security in Amazon S3:

"For Amazon S3, your responsibility includes the following areas:

• Managing your data, including object ownership and encryption.
• Classifying your assets.
• Managing access to your data using IAM roles and other service configurations to apply the appropriate permissions.
• Enabling detective controls such as AWS CloudTrail or Amazon GuardDuty for Amazon S3."

⚠️ An exposed S3 bucket is always the customer's side. AWS runs the storage; "Managing access to your data" is on the customer's list. No exam answer blames AWS for a public bucket.

The line, side by side

The constant row is the bottom one. Across every service, your data, your IAM, your encryption choices stay yours. What moves is everything below the application.

What "security of the cloud" looks like in practice: Nitro

One concrete example of AWS's side, from the Nitro security whitepaper page No AWS operator access, fetched 2026-09-25:

"By design the Nitro System has no operator access. There is no mechanism for any system or person to log in to EC2 Nitro hosts, access the memory of EC2 instances, or access any customer data stored on local encrypted instance storage or remote encrypted EBS volumes."

Lesson 5 covers Nitro properly. The point here: the "host OS and virtualization layer" in the model is not an abstraction — it's a specific system with a specific design.

Check yourself

1. In the model's first paragraph, which operating system is the customer's?
2. Name the three kinds of control and AWS's example of the one called "inherited".
3. An auditor wants RDS instances on the latest OS patch level. The console shows an available OS update. Will RDS apply it on its own?
4. Your Lambda functions are deployed as container images. Who patches the runtime?
5. A bucket was made public by a developer. Whose side of the model is that?

Answers

1. The guest OS — "The customer assumes responsibility and management of the guest operating system (including updates and security patches)". AWS owns the host OS.
2. Inherited, shared, customer-specific. Inherited example: "Physical and Environmental controls."
3. No. "An optional update can be applied at any time… RDS does not apply these updates automatically." You apply it (now or at the next window).
4. You. For container images, Lambda publishes updated base images; the customer must "Redeploy functions regularly using the latest container base image to pick up the latest patches."
5. The customer's. S3's list of customer responsibilities includes "Managing access to your data."

Teaching this section

• Redraw lesson 1's IaaS/PaaS/SaaS stack and call the shaded boundary "the line". Then slide it: EC2 → RDS → Lambda → S3. The model becomes one moving line rather than four tables.
• The RDS maintenance screen is the best demo. Show a required vs available update and ask who has to act on each. It breaks the "AWS patches RDS, done" oversimplification.
• Discussion prompt: "Lambda container images vs zip deployment — which puts more on the customer?" Most people guess wrong because "serverless" sounds like "AWS does everything".
• Watch for: host vs guest OS confusion; "shared" read as "both do the same thing"; blaming AWS for misconfiguration.
• Timing: 25 minutes.