CODEWITHSUNDEEP
amazon-web-servicesamazon-s3
joe1531
joe1531

Reputation: 514

Protecting S3 assets without CloudFront

I am beginner in using AWS and currently I am hosting the assets for a web application using a microservices-based architecture on a S3 bucket. I want to allow the browsers using the application to access the assets. But all over the internet, it is always stated that it's highly recommended to prevent public access to the S3 bucket. How can I do that without CloudFront, which I won't be using since all of the users are in the same region ?

Upvotes: 1

Views: 947

Answers (1)

MisterSmith
MisterSmith

Reputation: 3654

You cant use S3 for static hosting and follow AWS' best practice around S3 buckets being private - you need to pick one.

The recommended structure is a private S3 bucket, with a public CloudFront distribution in front, and an origin access identity to control access to the origin bucket. Honestly, if you do configure your bucket with just GET access and enable static web hosting its not terrible, but CloudFront offers a couple of significant benefits over S3 static website hosting:-

  1. Private S3, public CloudFront is a better default security stance and your less likely to make several common mistakes - hence why you see this guidance all over the internet.
  2. Hosting files over S3+CloudFront will on average reduce latency and increase download speed compared to just S3 alone even in the same region. There are many edge locations interconnected by super high speed connections all over the world. End users connecting via edge locations effectively take a shorter route to the origin S3 bucket than going directly to the regional S3 bucket over the public internet.
  3. Using CloudFront will probably work out cheaper than S3 alone.
  4. Flexability - CloudFront can access mutiple buckets (or load balencers) and serve different paths from different origins.

If you do go down the CF route (i recomend you do), for the extra effort you get many benefits.

Bare in mind CF respects any caching headers associated with your objects in S3, or uses defaults set on the CF distribution. Be careful setting long cache times on files - you can clear the cache (called an invalidation) in CF - but end users browsers that have downloaded the file will also likely respect the cache headers (this is where you can use "cache busting" query strings...).

Upvotes: 1

Related Questions