Shared responsibility model

Why this matters

The single biggest source of cloud breaches is teams thinking the cloud provider secures something the provider explicitly does not. AWS secures the hypervisor; you secure the S3 bucket policy. Azure secures the physical datacenter; you secure the NSG rules. Knowing where the line sits on each service before you turn it on is the difference between 'we got hacked' and 'we got audited and passed.'

Demo

Inspect a default S3 bucket and a default Azure storage account to see the exact knobs you own vs what the provider hardens by default.

Try it yourself

1. Create the S3 bucket, then run get-public-access-block and confirm BlockPublicAcls is true by default — that is AWS hardening on your behalf since 2023.
2. On the same bucket, run get-bucket-encryption and verify SSE is on by default — note the algorithm and decide if SSE-S3 is enough or you want SSE-KMS.
3. Pick one item from your bucket audit (versioning, MFA-delete, access logs) that is OFF by default and write a one-sentence justification for whether you would turn it on for production.

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

In one paragraph, explain the shared responsibility model like I'm new to it, with a concrete S3 example of where AWS's job ends and mine begins.

2. Why it works (the mechanism)

Walk me through how a misconfigured S3 bucket actually leaks data step by step — from the bucket policy evaluation to the public ACL to the listing — and which of those layers AWS controls.

3. Advanced — application & what's next

Given an e-commerce app on Azure storing payment tokens in Blob Storage, what is the responsibility split for PCI-DSS compliance and which controls do I have to prove I configured?

References

• AWS Shared Responsibility Model
• Microsoft — Shared responsibility in the cloud