Publicly accessible S3 buckets make the news often. It seems every week there's a new case of an improperly configured S3 bucket leaking data. There are a number of reasons for this, but the end result is never good.
One reason this happens is the complex permission structure for S3. Buckets and Objects can have different permissions. Both can be subject to IAM permissions, Bucket policies, different owners (for objects), and ACLs. The following is the flow chart for whether a request should be allowed or denied for an Object.
AWS released a new security mechanism for S3 to block public access, imaginatively named 'AWS S3 Block Public Access' . Adding this to an S3 bucket overrides any bucket policy or ACL that might allow public access. It provides a simple, at-a-glance, way to understand the permissions of a bucket.
The Cloud Team has enabled the S3 Block Public Access on all S3 Buckets. The S3 developer guide has information on enabling Block Public Access  as does the S3 CloudFormation documentation .
The most common use case for public S3 buckets is to serve a static web content. Indeed, S3 acts as a scalable, cost-effective, nearly-configuration-free web server. Using only S3, though, leaves a few gaps. The largest is the lack of TLS . It's easy to fix this, though, by adding Amazon CloudFront . CloudFront can be set up to serve the content of an S3 bucket and serve the traffic via https. This can be in the form of a generic CloudFront provided domain name, or with a UI provided TLS certificate and a custom, "vanity", domain name (ex: https://xxx.yyy.uiowa.edu).
While there is a wealth of documentation and tutorials on the topic, the Cloud Team is available to help you configure S3, CloudFront, or answer questions on any other topic. You can email us, sign up for Office Hours, or attend an AWS User Group meeting. 
Do you have a use case we didn't consider? We have an exception process! Start by filling out the form here.
 Please reach out to the Cloud Team to get added to our LISTSERV