AWS Shared Responsibility Across EC2, Databases, and Serverless Computing

Hello. In the previous lesson, you learned where AWS resources live: Regions provide geographic isolation, Availability Zones provide fault isolation within a Region, and edge locations improve delivery latency. This lesson changes the question from where does the workload run? to who must secure and operate each layer of it?

The AWS shared responsibility model is central to both the SAA-C03 exam and real architecture work. By the end, you should be able to assign responsibilities correctly in an EC2, Amazon RDS, or AWS Lambda scenario—and avoid the common mistake of assuming that “managed by AWS” means “nothing left for the customer to do.”

---

The central distinction: security of the cloud and security in the cloud

AWS operates the cloud infrastructure: its facilities, physical servers, networking equipment, storage hardware, and the foundational software that makes AWS services work. AWS calls this security of the cloud.

You, as the customer, secure the way your organization uses AWS: your data, identities, permissions, application behavior, and the configurations you choose. This is security in the cloud.

The boundary is not fixed. It moves depending on the service abstraction level:

• With Amazon EC2, AWS provides virtualized infrastructure, but you operate the guest operating system and most of the software stack.
• With Amazon RDS, AWS operates much more of the database platform, including the underlying host and routine database-engine maintenance.
• With AWS Lambda, AWS operates the servers, operating systems, and execution platform; you focus on function code, data, permissions, and configuration.

This is not a transfer of all risk to AWS. It is a division of operational duties by layer.

A practical rule is:

If AWS does not expose a layer for you to manage, AWS normally operates that layer. If you can configure a security-relevant setting, you are responsible for configuring it appropriately and verifying it works.

That rule is useful, but do not apply it mechanically. A managed service may execute a task on your behalf while you still choose the policy, schedule, retention period, access model, or recovery objective.

---

A layer-by-layer way to reason about responsibility

Before looking at individual services, separate a workload into layers. For each layer, ask: who operates it, and who configures its use?

Layer or control	Typical responsibility
AWS Regions, AZ facilities, physical access	AWS
Physical servers, storage devices, core networking	AWS
Virtualization layer and host operating system	AWS
Guest operating system inside an EC2 instance	Customer
Database schema, database users, SQL permissions, query design	Customer
Application code and dependencies selected by the customer	Customer
Data classification and data retention decisions	Customer
IAM roles, policies, and application access permissions	Customer
Encryption choices and key-access permissions	Customer
Security group and VPC configuration	Customer
Monitoring configuration, alert thresholds, and incident response	Customer

Some entries are shared controls rather than a clean handoff. For example:

• AWS patches the infrastructure supporting AWS services.
• On EC2, you patch the guest OS and your installed applications.
• On RDS, AWS provides and releases infrastructure and database-engine updates, while you must plan maintenance windows and apply or schedule required updates where the service requires it.
• AWS supplies logging services such as CloudWatch, but you decide which events to log, how long to retain them, which alarms matter, and who responds to alerts.

The shared responsibility model is therefore not merely a security diagram. It is an operating model for security, resilience, compliance, and day-to-day maintenance.

---

EC2: you operate the server inside AWS infrastructure

Amazon EC2 is infrastructure as a service. AWS makes a virtual machine available in a selected Region and Availability Zone, but the operating system inside that instance is your responsibility.

Suppose you launch an EC2 instance running Linux, install a web server, and connect it to a self-managed SQL Server or PostgreSQL database. AWS is responsible for the physical host, the facility, the underlying network, and the virtualization layer. You are responsible for nearly everything visible after connecting to the instance.

Your EC2 responsibilities

For an EC2-based workload, the customer typically owns:

• Selecting and hardening the Amazon Machine Image (AMI).
• Patching and securing the guest OS.
• Managing local users, SSH access, passwords, and configuration files.
• Installing, patching, and configuring web servers, agents, libraries, and database software.
• Configuring security groups and, where applicable, network ACLs and route tables.
• Managing IAM permissions, especially the instance role.
• Protecting application secrets and credentials.
• Encrypting data and controlling access to encryption keys.
• Defining backups, testing restoration, and meeting retention requirements.
• Monitoring application health, operating-system logs, capacity, and suspicious activity.
• Designing high availability, such as using instances across multiple AZs.

For a self-managed database on EC2, this includes database-engine patching, backups, database users, schemas, query performance, replication, and failover design. That resembles traditional server administration, except AWS has removed the data-center and physical-hardware layer.

AWS responsibilities for EC2

AWS remains responsible for:

• Physical data centers and environmental controls.
• Hardware lifecycle and physical storage media.
• Physical networking and AWS backbone infrastructure.
• The virtualization layer and host operating system that run EC2.
• The availability of the EC2 service infrastructure, according to applicable service commitments.

A security group is a useful exam example. AWS supplies and operates the security-group capability. You choose whether port 22, 443, 1433, or any other port is allowed, from which sources, and whether those rules meet the workload’s needs. If an EC2 instance is publicly reachable because its security group allows inbound access from everywhere, that is a customer configuration issue.

Exam cue: If a question asks who patches the operating system on an EC2 instance, the answer is the customer. AWS does not patch the guest OS for a standard EC2 instance.

---

Amazon RDS: AWS manages the database platform, not your database use

Amazon RDS is a managed relational database service. You select an engine, such as PostgreSQL, MySQL, MariaDB, Oracle, or SQL Server; choose an instance class and storage; and create a DB instance or cluster. AWS operates the underlying infrastructure and much of the database platform for you.

For an SQL developer, the key distinction is straightforward: RDS removes server-level administration, but it does not remove responsibility for database design and data governance.

What AWS operates in RDS

AWS manages the infrastructure on which RDS runs, including the physical facilities, hardware, host operating system, and core managed database-service platform. AWS also provides service capabilities such as:

• automated backups and point-in-time recovery features;
• database maintenance mechanisms and patches;
• monitoring integrations;
• Multi-AZ failover capability when you configure a Multi-AZ deployment;
• managed storage and replacement of failed underlying components.

However, “AWS manages RDS” should not be read as “AWS makes all database decisions.” You still select the engine version, maintenance window, backup-retention setting, network placement, and availability configuration. You must understand the service’s maintenance notifications and schedule required updates within stated deadlines.

What you operate in RDS

You remain responsible for the database as a business system:

• Data: classification, retention, deletion, and protection of customer data.
• Schema: tables, indexes, constraints, stored procedures, and migrations.
• Database access: database accounts, roles, privileges, and authentication design.
• Queries: query construction, indexing strategy, performance investigation, and connection behavior.
• Network access: VPC placement, security-group rules, and private versus public accessibility.
• Encryption choices: encryption at rest, encryption in transit, and permissions to use customer managed KMS keys where applicable.
• Backup policy: backup retention settings, business recovery requirements, and restore testing.
• Availability choices: deciding whether to configure Multi-AZ, read replicas, or other topology choices.
• Monitoring and response: alarms, log analysis, capacity planning, and incident handling.

For example, AWS can automatically fail over a correctly configured Multi-AZ RDS deployment. But AWS cannot decide that your business requires a Multi-AZ architecture; that is your architecture decision. Likewise, AWS may provide automated backups, but you must choose an appropriate retention period and prove that a database can be restored within the required recovery time.

Exam cue: “Minimize database administration overhead while retaining a relational database” usually points toward Amazon RDS or Aurora, not a self-managed database on EC2.

---

Serverless: AWS manages the execution environment, but you still secure the application

“Serverless” means you do not provision or operate servers for the workload. It does not mean the application is exempt from security, compliance, access control, or operational responsibility.

Consider an API Gateway endpoint that invokes a Lambda function, which writes an order to DynamoDB. AWS runs the servers, operating system, Lambda execution environment, underlying networking infrastructure, and scaling platform. You write the function and configure how it is allowed to interact with the rest of AWS.

AWS responsibilities in a Lambda workload

AWS operates:

• the physical infrastructure and facilities;
• Lambda compute fleet, host operating systems, and runtime execution environment;
• scaling of the Lambda service infrastructure;
• managed-service platform maintenance;
• the underlying service availability mechanisms.

You do not log in to a Lambda server to patch Linux. There is no server for you to administer in that sense.

Customer responsibilities in a Lambda workload

You still own the security and quality of what your function does:

• Writing secure function code and maintaining its dependencies.
• Handling input validation, authorization decisions, and safe error handling.
• Selecting a least-privilege Lambda execution role.
• Configuring resource policies and invocation permissions where required.
• Protecting secrets and using an appropriate secrets service rather than embedding credentials in code.
• Encrypting and governing customer data.
• Choosing timeout, memory, concurrency, and retry behavior.
• Configuring VPC, subnet, and security-group settings if the function must access VPC resources.
• Setting log retention, creating alarms, monitoring failures, and responding to incidents.
• Configuring the security of connected services: API Gateway authorization, SQS queue permissions, DynamoDB access, and so forth.

If a Lambda function has an execution role that allows s3:* against every bucket in the account, AWS has correctly operated Lambda—but the workload is still over-permissioned because of a customer IAM decision. If the function contains a SQL injection vulnerability or exposes sensitive data in logs, those are also customer responsibilities.

Exam cue: “No server administration” does not mean “no configuration.” In a serverless design, look closely at IAM roles, API authorization, data access, logging, encryption, and event permissions.

---

Compare the three scenarios

The most useful comparison is not “which service is secure?” All three can be used securely. The question is: which service gives you the correct balance of control and operational responsibility?

Responsibility area	EC2 with self-managed software	Amazon RDS	AWS Lambda
Physical facility and hardware	AWS	AWS	AWS
Host OS and virtualization	AWS	AWS	AWS
Guest OS patching	Customer	AWS	AWS
Database-engine platform patching	Customer, if self-managed	AWS manages service updates; customer plans required maintenance actions	Not applicable
Application code	Customer	Customer	Customer
Schema and query optimization	Customer	Customer	Depends on connected data store; customer owns application data logic
IAM and access design	Customer	Customer	Customer
Security-group configuration	Customer	Customer	Customer when Lambda uses VPC networking
Data classification and encryption decisions	Customer	Customer	Customer
Backup and recovery requirements	Customer designs and validates	Customer configures policy and validates restoration; AWS operates managed backup capabilities	Customer defines protection for data stores and validates recovery
Scaling architecture	Customer configures and operates capacity mechanisms	Customer selects capacity and topology options	AWS scales service infrastructure; customer configures concurrency and downstream capacity

As service abstraction increases, AWS takes on more undifferentiated operational work. Your accountability becomes more concentrated in identity, data, configuration, and application behavior.

This is why managed services are often strong architectural choices: not because responsibility disappears, but because the team can spend less time patching hosts and more time on controls that directly protect the application and its data.

---

Applying the model to architecture statements

Use the following reasoning patterns in an exam question or a design review.

Scenario 1: EC2 vulnerability patch

A company runs an application on Amazon Linux EC2 instances. A critical package vulnerability is announced.

The customer must patch the guest OS or affected application package, test the change, and deploy it safely. AWS remains responsible for the infrastructure below the instance, but it does not administer the customer’s guest OS.

Scenario 2: RDS administrator account

A company uses Amazon RDS for PostgreSQL. A former employee’s database administrator account remains active.

AWS operates the RDS infrastructure, but the customer must remove or restrict the database account, review access privileges, and investigate the account’s activity. Managed infrastructure does not replace identity governance.

Scenario 3: Lambda data exposure

A Lambda function writes customer records to DynamoDB. The function’s execution role permits reads from all DynamoDB tables in the account, including tables containing unrelated sensitive data.

AWS secures the Lambda platform and DynamoDB service infrastructure. The customer must revise the Lambda execution role to allow only the specific actions and table ARNs required. This is a least-privilege IAM problem.

Scenario 4: RDS backup feature versus recovery readiness

An RDS instance has automated backups enabled, but the team has never performed a restore test and has not checked whether its retention setting meets the business requirement.

AWS provides and operates the automated backup capability. The customer is responsible for defining recovery objectives, selecting retention, restricting backup access where needed, and verifying that restoration works.

---

Fast exam-recognition guide

If the question says…	Think…
“Patch the operating system on EC2”	Customer responsibility
“Protect the physical data center”	AWS responsibility
“Configure a security group”	Customer responsibility
“Choose encryption and control access to customer data”	Customer responsibility
“Maintain host OS for RDS”	AWS responsibility
“Create database users and grant SQL permissions in RDS”	Customer responsibility
“Optimize slow customer SQL queries in RDS”	Customer responsibility
“Patch Lambda servers”	AWS responsibility
“Restrict a Lambda function’s permissions”	Customer responsibility
“Secure code, event permissions, logs, and API authorization”	Customer responsibility

Avoid these traps:

• “AWS is responsible for all security in AWS.”
  AWS is responsible for security of the cloud; customers retain substantial responsibility in the cloud.

• “RDS means AWS owns database security.”
  AWS manages the platform, while the customer owns access controls, data, schema, queries, connectivity, and recovery requirements.

• “Lambda eliminates patching responsibility.”
  It eliminates server and OS patching, but not secure-code maintenance, dependency management, IAM configuration, or application monitoring.

• “A managed backup feature means recovery is guaranteed.”
  AWS supplies the mechanism. The customer still sets policy and validates that recovery meets business needs.

---

The shared responsibility model shifts responsibility upward as you move from EC2 to RDS to Lambda:

• EC2 gives you the most operating-system and software responsibility.
• RDS removes infrastructure and much database-platform administration, while leaving database design, access, network controls, and recovery policy with you.
• Lambda removes server management, but application code, IAM, data protection, logging, and configuration remain customer responsibilities.
• In every model, AWS protects the underlying cloud infrastructure; the customer must securely configure and operate the workload placed on it.

Next, you will trace a cloud application request through DNS, TCP or UDP ports, HTTP, and TLS. That request path will make the customer responsibilities for security groups, network exposure, certificates, and application-layer protection much more concrete.