I have some older S3 buckets where the 'block all public access' setting is turned off, and I want to make sure no data can be accessed publicly. We currently grant access to our buckets through cross-account roles and specific bucket policies. Before I change the setting to block public access, what should I check to ensure there won't be any disruptions?
5 Answers
It might be a good idea to create a test bucket first to verify that your connections are still working as expected. However, I understand that you want to avoid altering permissions on a production bucket.
You could check the S3 access logs or use CloudTrail if you have those set up, as they may give you hints about any public access issues. Generally, toggling the public access setting should be quick—if your operational setup allows, testing it live could work, and then you can implement it as Infrastructure as Code later.
The quickest method might be to do a 'scream test' in a lower environment to see how everything reacts. Just be cautious because public access is a serious concern—better to address it sooner rather than later.
That seems like a fun approach! However, I'm not sure we have lower environments available. Is it really urgent to fix public access?
I'm using the IAM Access Analyzer for external access, and everything shows no public access, so I feel safe making this update.
One thing to keep in mind is whether you're accessing the bucket through CloudFront. Older setups needed the bucket to be public, but now you can use origin access control. Make sure your distributions are updated to reflect that.
True, making changes on a live bucket can be risky. Migrating to a new bucket might shift the burden to other teams, which can be problematic.