Shared Responsibility and Service Models

Goal

The previous section introduced AWS architecture as responsibility placement. This section explains the most important responsibility idea in AWS: security and operations are shared between AWS and the customer, and the exact boundary changes by service choice.

The durable idea is:

Managed services shift responsibility; they do not remove architecture responsibility.

The Short Version

The AWS shared responsibility model separates what AWS operates from what the customer must design, configure, secure, and monitor.

At a high level:

AWS responsibility
  -> infrastructure, facilities, hardware, global cloud foundations

Customer responsibility
  -> workload design, data, identity, configuration, access, applications, operations

The boundary is not identical for every service. A virtual machine gives the customer more operating control and more responsibility. A managed database shifts more infrastructure responsibility to AWS, but the customer still owns data, access, configuration, backup choices, application behavior, and compliance decisions. A serverless function shifts server management away from the customer, but the customer still owns code, permissions, events, observability, and business behavior.

Security Of the Cloud and Security In the Cloud

AWS commonly describes the model as:

Side	Practical Meaning
Security of the cloud	AWS protects the infrastructure that runs AWS services, including facilities, hardware, networking, and foundational service infrastructure.
Security in the cloud	The customer configures and secures their workloads, data, identities, network controls, applications, and service use.

This distinction matters because cloud adoption can reduce some operational burden while increasing the importance of configuration, identity, policy, automation, and review.

For example, AWS operates the physical data centers and foundational infrastructure. But if a team exposes a database publicly, grants broad permissions, stores secrets in code, or ignores backup requirements, that is still an architecture and operations problem for the customer.

Service Models as Responsibility Shifts

Cloud service models are useful because they show responsibility shifts.

Model	What Shifts Toward the Provider	What the Customer Still Owns
IaaS	Physical infrastructure, virtualization, facilities, and cloud control plane.	OS configuration, patching, application software, identity, data, network rules, monitoring, backup, and cost.
Managed platform/service	More infrastructure and platform operations.	Data, access, configuration, workload behavior, integration, observability, compliance, and cost choices.
Serverless	Server provisioning and much runtime scaling responsibility.	Code, events, permissions, failure handling, concurrency behavior, monitoring, security, and cost behavior.
SaaS	Most application and infrastructure operation.	User access, data use, configuration, governance, integration, and business process fit.

The more AWS manages, the more you should ask what remains with your team. Managed does not mean unmanaged by anyone. It means AWS manages a larger part of the stack and your team must manage the remaining decisions well.

Why Service Choice Changes Responsibility

Consider a customer-facing API.

If the team runs it on Amazon EC2, they may own operating system patching, instance configuration, runtime setup, capacity planning, scaling policies, deployment scripts, and host-level monitoring.

If the team runs it in containers, they still own the application and container lifecycle, but some infrastructure responsibilities may shift depending on whether they choose a managed container platform, serverless containers, or Kubernetes.

If the team runs small event-driven logic in AWS Lambda, they no longer manage servers for that function, but they still own code quality, IAM permissions, event sources, retries, concurrency, error handling, logging, and cost.

The architecture question is not "Which service is best?" It is:

Which responsibility boundary fits this workload and team?

Practical Responsibility Questions

Before choosing a service, ask:

Who patches the operating system or runtime?
Who controls scaling and capacity?
Who owns backup and recovery settings?
Who configures network exposure?
Who manages encryption choices and keys?
Who grants access to users, workloads, and automation?
Who monitors health, latency, errors, and cost?
Who responds when something breaks?
Which compliance evidence must the team produce?

These questions are especially useful in architecture conversations because they reveal trade-offs quickly.

Example: The Same App, Different Boundaries

A simple customer portal could be implemented several ways:

Option	Why It Might Fit	Responsibility Trade-Off
EC2-based web servers	The team needs VM-level control or has an existing server-based app.	More control, more patching and host operations.
Containers	The team wants portable packaging and service-level scaling.	Platform responsibility depends on container service choice.
Serverless functions	The workload is event-driven or has spiky demand.	Less server management, but event design and permissions matter more.
Managed application platform or SaaS	The team wants to reduce custom operations.	Less infrastructure ownership, but configuration, integration, and business fit remain.

The right answer depends on team skill, workload shape, compliance, latency, deployment style, operational maturity, and cost behavior.

Common Mistakes

Saying "AWS handles security" without explaining the customer's responsibilities.
Choosing a managed service and forgetting configuration, access, data, and monitoring.
Using EC2 out of habit when a higher-level service would reduce undifferentiated operations.
Using serverless because it sounds simple while ignoring event retries, permissions, and observability.
Treating shared responsibility as a compliance diagram instead of a design tool.

If Someone Asks You

What does shared responsibility mean in AWS?

A good answer is:

AWS is responsible for the security and operation of the cloud infrastructure, while customers are responsible for how they use AWS services: workload design, data, identity, permissions, configuration, application behavior, monitoring, and compliance obligations. The exact boundary changes by service. Managed services shift responsibility, but they do not remove architecture ownership.

What You Should Remember

Every AWS service choice is also a responsibility-boundary choice.

Questions to Check Your Understanding

How does shared responsibility change between EC2 and a more managed service?
Why does serverless still need architecture and operations design?
What customer responsibilities remain even when AWS manages the infrastructure?