Shared Responsibility and the AWS Value Proposition Review

Review of the AWS Shared Responsibility Model and the AWS value proposition including global infrastructure concepts.

15 min

Introductory

Learning outcomes

By the end of this lesson, the learner can:

Explain the AWS shared responsibility model and how it divides ownership.
Distinguish between what AWS manages and what the customer manages.
Explain why cloud value is more than "renting servers."
Connect shared responsibility to services with different management levels.
Relate AWS's global infrastructure to reliability and resilience thinking. AWS says each Region is isolated from other Regions, and each Region has multiple independent Availability Zones. (AWS Documentation)

What this review covers

This lesson answers two big questions:

Why do people use AWS?
Who is responsible for what once they do?

A simple summary is:

AWS value proposition = faster access to infrastructure, more flexibility, easier scaling, and the ability to design for resilience across Regions and Availability Zones. AWS says Regions are separate geographic areas, Regions are isolated from each other, and each Region has multiple independent Availability Zones connected with low-latency, highly redundant networking. AWS also currently states the AWS Cloud spans 39 launched Regions and 123 Availability Zones. (AWS Documentation)
Shared responsibility = AWS manages the cloud infrastructure, while the customer still manages what they build and configure on top of it. This is the idea learners must keep in mind every time they choose a service.

1) The AWS value proposition in practical terms

At a high level, AWS gives you access to infrastructure without needing to buy and operate physical hardware first. The value is not only compute. It also includes storage, databases, networking, scaling, and geographic deployment options across Regions and Availability Zones. AWS's infrastructure docs emphasize that Regions are separate geographic areas and that Availability Zones are isolated locations within a Region. (AWS Documentation)

That means the cloud value proposition includes:

launching resources faster
changing capacity more easily
choosing where workloads run
designing for higher availability by using multiple Availability Zones
using managed services so you do less undifferentiated operational work

Key takeaway:

cloud value is speed, flexibility, and resilience
not just "someone else owns the servers"

2) What "shared responsibility" means

The shared responsibility idea is simple:

AWS is responsible for the cloud
the customer is responsible for what they put in the cloud

At a high level, that means AWS handles the underlying physical facilities, core infrastructure, and service platform operations, while the customer still has to make good choices about:

identities and permissions
network exposure
data handling
application configuration
how resources are used together

This lesson builds directly on what you already saw in Unit 4:

security groups still had to be configured correctly
CloudFormation stacks still needed good templates
DynamoDB still needed good key design
ECS services still needed the right container/service setup
S3 classes still needed correct storage choices

Key takeaway:

managed service does not mean zero responsibility
it means the responsibility line moves

3) The responsibility line changes by service type

One of the most important review ideas is that the amount AWS manages depends on the service.

More customer responsibility

With EC2, you manage much more:

the OS
patching approach
many configuration decisions
installed software
more network and access details

More AWS responsibility

With services like DynamoDB, ElastiCache Serverless, Lightsail managed databases, or Fargate, AWS manages more of the underlying infrastructure layer.

Still your responsibility

Even with heavily managed services, you still own:

what data you store
who can access it
whether your app design is secure
whether your architecture makes sense for the workload

Key takeaway:

the shared responsibility model is not identical across all services
moving from EC2 to more managed services usually reduces infrastructure responsibility, but not application or data responsibility

4) Shared responsibility examples from Unit 4

Example A: EC2

AWS gives you the virtual server platform, but you still decide:

what to install
how open the security group should be
whether you patch and maintain it properly
whether you deploy across one or multiple AZs

That is why EC2 felt like "more control, more responsibility."

Example B: RDS/Aurora

AWS manages more of the database infrastructure and operational tasks, but you still own:

schema design
query design
data access choices
whether your app uses the database correctly

Example C: DynamoDB

AWS manages the infrastructure and scaling model, but you still own:

table design
primary key strategy
how the app reads and writes data

Example D: ECS on Fargate

AWS manages the underlying server layer for running the containers, but you still own:

the containerized app
task/service design
permissions
networking choices
how the service is exposed

Key takeaway:

the more managed the service, the more AWS handles underneath
but the customer still owns architecture, data, access, and app behavior

5) Why this matters for security

A common source of confusion comes from thinking: "Because AWS is secure, my app is secure."

That is not how shared responsibility works.

For example:

putting data in S3 does not automatically mean your access model is correct
using EC2 does not automatically mean your ports are safe
using RDS does not automatically mean your schema or credentials strategy is safe
using ECS does not automatically mean your services are exposed correctly

Key takeaway:

AWS provides secure-capable services
you still have to configure and use them responsibly

6) AWS global infrastructure and value

AWS's infrastructure pages reinforce part of the value proposition by showing how AWS gives you geographic and zonal choices. AWS says:

a Region is a separate geographic area
Availability Zones are isolated locations within a Region
each Region has multiple independent Availability Zones
deploying across multiple AZs is a best practice for availability
AWS currently has 39 launched Regions and 123 Availability Zones. (AWS Documentation)

This matters because resilience is part of the AWS value proposition:

one server in one place is riskier
multiple AZs in one Region improve high availability
multiple Regions can support broader geographic or disaster recovery strategies

Key takeaway:

AWS value includes infrastructure design choices that help availability, not just raw compute

7) Shared responsibility and service selection

A strong habit is to ask two questions whenever choosing an AWS service:

What job does this service do best?
What responsibility still stays with me if I choose it?

Examples:

EC2: best for server control, but you own much more operational work
Lightsail: easier bundled platform, but you still own app configuration and access decisions
RDS/Aurora: managed relational database, but you still own schema and query design
DynamoDB: managed NoSQL, but you still own key design
CloudFormation: repeatable infrastructure, but you still own the correctness of the template
ECS/Fargate: managed container execution, but you still own service/container design

This is the thinking that starts turning service recognition into real cloud reasoning.

Quick comparison table

Concept	Mental model
AWS responsibility	The cloud infrastructure and foundational managed-service operations
Customer responsibility	Data, access, app configuration, architecture choices, and how services are used
More customer-managed path	EC2
More managed path	DynamoDB, Fargate, managed database services, serverless-style services
Value proposition	Speed, flexibility, scaling, and resilience options

CSV version:

Concept,Mental model
AWS responsibility,The cloud infrastructure and foundational managed-service operations
Customer responsibility,"Data, access, app configuration, architecture choices, and how services are used"
More customer-managed path,EC2
More managed path,"DynamoDB, Fargate, managed database services, serverless-style services"
Value proposition,"Speed, flexibility, scaling, and resilience options"

Micro-activity 1

Think about it

For each statement, write AWS, Customer, or Both:

Choosing whether SSH should be open to the world on an EC2 instance
Running the physical data centers and core infrastructure
Designing a DynamoDB primary key that matches app access patterns
Deciding whether to deploy an app across multiple Availability Zones
Managing the underlying infrastructure for a serverless service

Use the Shared Responsibility Model guidance. (AWS Documentation)

Micro-activity 2

Think about it

Answer in one or two sentences each:

Why does moving from EC2 to a more managed service usually reduce responsibility but not eliminate it?
Why is the AWS value proposition about more than just virtual machines?
Why does deploying across multiple Availability Zones improve resilience?

Use AWS's Region and Availability Zone guidance in your explanation. (AWS Documentation)

Summary

The AWS value proposition is about faster access to infrastructure, flexible scaling, and stronger resilience options through AWS's global infrastructure. AWS says Regions are separate geographic areas, Regions are isolated from each other, and each Region contains multiple independent Availability Zones. AWS also currently reports 39 launched Regions and 123 Availability Zones. (AWS Documentation)

The shared responsibility model is the principle that keeps learners from making the wrong assumption about managed services. AWS handles the cloud infrastructure, but customers still own the way they configure, secure, and use services. The exact responsibility line shifts by service, but it never disappears completely.

The simplest memory rule is:

AWS secures and runs the cloud
you secure and design what you build in it

Quiz 5.2

Knowledge Check

1 / 6

What is the simplest statement of the shared responsibility model?

Reflection questions

Think about it

Give one example of something AWS manages and one example of something the customer manages.

Think about it

Why is deploying across multiple AZs usually better than only one?

Think about it

A team uses RDS and assumes AWS now owns schema design and query design. What is wrong with that assumption?

Think about it

What is the simplest memory rule for the shared responsibility model?

Answer key

A1: C. AWS handles the cloud, while the customer still owns what they build and configure on top of it.

A2: A. EC2. EC2 leaves more OS, software, and configuration responsibility with the customer than more managed services do.

A3: B. Managed services reduce infrastructure responsibility, but customers still own things like data, access, configuration, and architecture decisions.

A4: Example: AWS manages the physical infrastructure; the customer manages things like permissions, app configuration, or table/schema design.

A5: B. AWS says a Region is a separate geographic area. (AWS Documentation)

A6: A. AWS says Availability Zones are isolated locations within each Region. (AWS Documentation)

A7: Because AWS says deploying across multiple Availability Zones helps an application remain available even if one Availability Zone fails. (AWS Documentation)

A8: C. AWS says each Region is designed to be isolated from the other Regions. (AWS Documentation)

A9: RDS is managed relational infrastructure, but the customer still owns schema design, query design, and how the application uses the database.

A10: AWS secures and runs the cloud; you secure and design what you build in it.

Next lesson

Lesson 5.3: Deployment Models, Service Models, and Cloud Characteristics Review