Hacker News new | ask | show | jobs
by gtsteve 3495 days ago
I use AWS S3, which I put behind a Cloudfront distribution. It's quick to set up, and there are no servers to keep up to date and patched. You also get free SSL for your Cloudfront distribution via AWS certificate manager. For stuff like Contact Us forms, I use AWS Lambda to post the data into my company's CMS. We've had this setup for about a year now and it works quite well.

The cost is almost nothing but we don't have a high traffic website. If you started getting billions of hits from expensive Cloudfront regions such as Australia or India, you might consider something else.

2 comments

A quick note on the S3/Cloudfront option - make sure you enable "Compress Objects Automatically"; it's not enabled by default and wasn't provided for a long time.

https://aws.amazon.com/blogs/aws/new-gzip-compression-suppor...

You'll save a lot on your bandwidth bill.

You can also set your edge usage to "Use Only US, Canada, and Europe" vs. "Use All Edge Locations" to save money, depending on your performance needs in various geographies.
This is probably a better option than storing compressed data in S3 with a hard-coded Content-Encoding header, as it seems some web clients (like the Facebook app) display the raw gzip data.
It's worth noting that SSL only works between the browser and Cloudfront servers. Last time I checked there wasn't an option to use SSL with s3.

It's not a deal breaker, but it was enough to make me look for alternatives.

If I understand what you're saying, if the origin for your Cloudfront distribution is an S3 bucket, the link between S3 and Cloudfront is unencrypted? That seems unimaginable to me.
If the origin is an S3 static website, the link is unencrypted but should run over Amazon's own network. Since Amazon has your S3 and CloudFront data anyway, assuming all CF endpoints are under Amazon's control, you don't lose much by having the S3 origin load over http.
What makes you think that when cloudfront requests objects internally from s3, it's using http?

It could just as easily be connecting with s2n and authenticating both endpoints of the connection.

This article[1] states the following, though it doesn't cite any specific source:

> CloudFront will use encryption when retrieving data from its storage service S3 (Simple Storage Service), so the content is protected all the way from where it is stored to the user's computer, according to Amazon.

1. http://www.computerworld.com/article/2518747/data-center/use...

It says so in the CloudFront distribution setup, when you point it at an s3-website-[region] URL instead of directly at an S3 bucket.
That's just naive with the information we have today. Google thought this too, and the NSA happily used that to eavesdrop.
Eavesdropping on the connection between CF and S3 doesn't say too much about a public static website, though. If you're serving private data, use an S3 bucket directly instead of the S3 static website hosting HTTP server.
Yup. It's fine for most simple sites that don't receive much traffic due to almost nonexistent costs. But I personally don't recommend it when there are many alternatives out there these days. Partly SSL is no SSL imo.
You can use SSL with S3 as the backend, you just have to set the distribution origin to s3.amazonaws.com/bucket-name/
Does that work with s3 static websites though? I recall that a different endpoint was needed, and it's only http.
The method I described doesn't require you to use a S3 static website. We don't have that option enabled, so the bucket name isn't mysite.com, it's "mysite-html", and the S3 website hosting is not enabled.

CloudFront has its own IAM user that is permitted to access the contents of the bucket, which means that it has to use the API. I don't think it's even possible to access the S3 API without using HTTPS. Therefore I think it is highly unlikely that the connection is unencrypted.

Awesome! I'm new to AWS, and when I tried to setup a static website using cloudfront + s3, I was only aware of the static website option on s3. This is what the docs uses, and it led me to the wrong path it seems! Thanks