Who Secures What in the Cloud (Shared Responsibility)

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.

References

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