Stop 01 · Cloud Computing FoundationsTopics · 6/9

The Shared Responsibility Model

In short

Most cloud data leaks are not hackers breaking AWS. They're customers leaving a storage bucket open or a password in code. This model tells you exactly which part is your job.

The cloud provider secures the underlying infrastructure ('security of the cloud'), while you're responsible for securing what you configure and deploy on top of it ('security in the cloud') — misunderstanding this split is a common source of real breaches.

The blob character locks an apartment door while a watchman guards the building gate.

Think of it like this

Renting a flat

The builder keeps the structure, lift and main gate safe. But if you leave your own door unlocked and the gas on, that's on you. The provider secures the building. You secure your flat.

Watch it happen

Who secures what

Cloud security

Provider: OF

Data centres

Virtualisation

You: IN

Data and access

Firewall rules

VM OS patches

1/4Security is split in two. The line moves depending on the service you use.

The big ideas

What you need to know

Security OF the cloud

Physical buildings, hardware, global network and hypervisors. The provider handles these and you can't touch them.

Security IN the cloud

Your users, permissions, data, network rules and app code. Always yours, whichever service you use.

The line moves

On a VM you patch the OS. On a managed database the provider patches it. On SaaS even less is yours.

Misconfiguration is the big risk

Public buckets, wide-open security groups and leaked keys cause many real incidents. All of these are customer-side.

See it in code

Walk through the code

bash

1# Block all public access on one S3 bucket (your side of the model)2aws s3api put-public-access-block \3  --bucket my-notes-2026-xyz \4  --public-access-block-configuration \5  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

1/2Target one bucket you own. The provider will never change this for you.

New S3 buckets block public access by default, but someone can switch it off. Checking and enforcing this setting is your job.

Save yourself the pain

Common mistakes

Oops

Assuming 'it's on AWS so it's secure'.

Do this instead

AWS secures its infrastructure. If you make a bucket public, AWS will let you, because it's your setting.

Oops

Thinking managed services mean zero security work.

Do this instead

Even on a managed database you still own who can connect, the passwords and whether the network is private.

Your mission

Split a real breach

~20 min

Quick check

A team runs an app on an EC2 VM and gets hacked through an old, unpatched OS package. Whose responsibility was the patch?

Go deeper

1Read your target provider's official shared responsibility model diagram.
2List 3 specific things that remain your responsibility even on a fully managed service.
3Learn why 'the cloud got hacked' is almost always actually a customer misconfiguration.