Hacker News Reader

Comment by notaddicted | Hacker News Reader

It is very easy to set up S3 to provide the files to cloudfront ... have you seen any issues with that?

I believe not: I'm pretty certain putting CloudFront in front of your bucket is fine (it handles the HTTP layering correctly); this problem is one of attempting to directly host static content from S3 only.

(That said, I have very little personal experience with CloudFront, as in my experience it is more expensive for fewer features with less POPs than using a "real CDN" like CDNetworks, or even Akamai.)

(edit:)

For this specific circumstance, I'm not certain at all what CloudFront's behavior will be; it seems like the "redirect" concept is a property of the "static website hosting" feature of S3, not part of the underlying bucket, and CloudFront "normally" (in quotes, as I just mean the default origin options it provides) directly accesses the bucket.

I thereby imagine that if I simply set a custom origin to the ___.s3-website-us-east-1.amazonaws.com URL provided by the S3 static hosting feature I will get the right behavior (where CloudFront forwards and caches the 301 responses), but then I have no clue if it will correctly retry the 500 error responses.

That said, I will point out that I am not even certain if CloudFront retries the 500 requests anyway: it occurred to me that with a small error rate combined with a cache, if you (as I somewhat did at least) expect the potential fix to be S3-specific, you might simply never really "catch" an actual failing request in a test scenario.

It could then be that CloudFront retries all 50x failures (in which case if I set it up with a custom origin to the S3 static hosting URL you'd still get the retry behavior), but I somehow doubt that it does that (and just earlier I saw two requests in a row to S3 fail for these 301 redirects, so it might not even help).

CloudFront doesn't retry on 500s. Besides, you can't alias to a CloudFront distribution from x.com apex, so I don't think it would work for you even if that were the case.

CloudFront, when used with Route 53 as your DNS provider, can be used for zone apex hosting, as you can place an "ALIAS" record (as opposed to a real DNS CNAME) to the other hostname; this is the same procedure you use to get S3's static hosting feature working with a zone apex and these new instructions today. (That said, I have never done this personally with CloudFront, as again: I do not use CloudFront.)

Nope. Route 53 has to ALIAS to another RR in your own hosted zone. There's no way for Route 53 to return the A records/IP address RDATA that CloudFront uses to direct clients to the fastest site.

Other "ALIAS" providers can't do real CloudFront apex support either. Their intermediate resolvers end up caching the CloudFront records without varying per client subnet.

Interesting! I was reading something in one of the FAQ's earlier that seemed to indicate that that works, but now digging further and reading through the forums, I see that you are totally right: you simply couldn't do build this use-case with pure-AWS (non-EC2) tools without having this new S3 static hosting redirection feature.

(As for non-Amazon DNS with server-side aliasing support, it wouldn't be that bad, for this kind of use case: you are already taking a latency hit by returning the 301, and direct links will never target these URLs as they will have the canonical www. hostname, so if you just end up with an edge node near a geo-ip DNS server near the original user, it will be approximately good enough.)

Route53 now supports at least S3 buckets and EC2 Elastic Load Balancers as alias targets. So it does more than just another RR.

Not using amazon's method, but combining S3 + Cloudfront w/ DNSMadeeasy's Aname record, you can this works (example):

http://www.customer.io

http://customer.io

No redirect, 1 s3 bucket, and they both serve up the same assets from cloudfront. And HTTPS works too on cloudfront.

Shouldn't be a huge issue, but for search I think it's best practices to have one redirect to the other.

I spent some time over the past weekend migrating my static-generated blog over to S3+CF and the only problems that I ran into were invalidation and permissions on the bucket. It is likely a result of my lack of knowledge of S3 bucket/CF utilities, but I've been using s3cmd for sync.

Definitely impressed with how quickly it went. I muddled through setting up AWS DNS, S3 and CF through a bunch of blog articles. But it was well worth the time investment.

Ran in to similar issues. Not sure if you saw my article, but the forked version of s3cmd I mention handles invalidation excellently.

http://iamnotaprogrammer.com/Jekyll-S3-Cloudfront-Aname-Root...

I'll definitely take a look.

Likely I'll just wrote a post on my experiences as well once everything is said and done. I haven't had the time over the holiday to figure out the AWS bucket policy. But my overall plan is to have node-webkit shim that has a markdown editor for editing posts.

It should be relatively easy and would be a complete win for me blog post wise. Especially since my "drafts" would be in S3 themselves.

Reply on news.ycombinator.com