AWS Shared Responsibility: Who Secures an S3 Bucket?
A beginner’s look at what AWS manages and what customers must configure when storing application files in Amazon S3.
When I first heard that AWS manages cloud infrastructure, I wondered how much security AWS handles for an application. Amazon S3 is a useful example because the answer depends on which part of the system we mean.
AWS is responsible for security of the cloud: the infrastructure that runs its services. The customer is responsible for security in the cloud, including how they configure access to their data. This is the shared responsibility model.
Imagine an application that stores users’ uploaded documents in an S3 bucket. AWS operates the underlying infrastructure, but the application team still needs to decide who can read or upload each document. An S3 bucket does not become appropriate for sensitive data simply because it runs on AWS.
I would start by asking three questions:
- Should these files be public? If the answer is no, keep S3 Block Public Access enabled and review bucket access settings.
- Which workload needs access? Give the application only the permissions it needs. AWS recommends temporary credentials through IAM roles for workloads instead of embedding long-term access keys in code.
- How will we check access later? Review permissions as the application changes, especially before adding new users or services.
The distinction I’m taking away is simple: choosing a managed cloud service reduces the infrastructure a team operates, but it does not remove the need to configure that service securely. I’m learning AWS by looking at one service at a time and asking where AWS’s responsibility ends and mine begins.
What other AWS service helped you understand the shared responsibility model?
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article