Making an s3 bucket private is simple, it's a single copy paste command using the AWS CLI that you can find below, but a fair warning, you need to understand the impact this could have.
I can name almost zero good reasons why an S3 bucket should be public, and even less reasons to have a bucket be semi private. Most of the time this is done out of laziness or lack of knowledge on the part of whomever created it. AWS has made some significant changes in the way S3 buckets have been created over the years, with the most restrictive defaults being the current goto. This doesn't stop developers from creating applications that work by just cracking open the security holes to read what they want out of S3, or even worse public write access. The proper solution is to use IAM roles along with the AWS SDK in the application to read/write the files you need safely and securely.
What will break when I make this bucket private?
S3 Website Hosting
The most common and only semi valid use case for a public s3 bucket is hosting a static webpage, but even this isn't a good solution when you can use CloudFront. "Amazon CloudFront is a fast content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency, high transfer speeds..." CloudFront can possibly host your static website for cheaper depending on the traffic you get, along with the ability to use the free public certs AWS provides free of charge. Data transferred out of S3 to CloudFront is actually free, so you don't need to worry about Bezos double dipping.
For instructions on hosting your static s3 website with CloudFront, see here.
And for instruction on making that bucket private again, check here.
Applications that use S3
If you have applications that are using these public or "can be public" buckets you need to double and triple check that they are accessing them through the AWS SDK and not externally through the internet. Adding a public access block when your core application depends on reading/writing to it unconventionally could be a disaster. This is a decision worth talking to your entire dev team about to try to find out why the bucket is the way it is, and the next steps forward in securing it. Running the access block command on the CLI is just the final step in possibly multiple code changes to set things right.
Locking down the bucket
For more information about installing and configuring the AWS CLI, see here.
To lock down the bucket, all you need to do is substitute your own bucket name and run the following:
- Navigate to the S3 console: https://s3.console.aws.amazon.com/s3/home
- Find the bucket you want to change in the list, and click on it.
- Navigate to the permissions tab and click 'Edit' on block all public access:
- Check the 'Block all public access' box, and hit save
- You will be asked to confirm
If something broke when you made this change, you can always roll back these changes. Objects in the bucket do not actually change their access to private when a block is set on the entire bucket, so removing the block will make anything that was public previously, public again. Just revert the bucket access block the same as it was using the steps above. You may also need to make the bucket public again so applications can list the objects.
Monitoring your S3 buckets going forwards
Having a hard time using the AWS Console to keep track of all the buckets your team is using and creating? Take a look at the free minimalistic tool we created at Reconfig . We provide transparency into who has access, security issues, and cost estimations per bucket when you want to find what's really driving that s3 bill up.