Amazon CloudFront Support for Custom Origins | Hacker News Reader

Amazon CloudFront Support for Custom Origins

aws.typepad.com

54 pointsjeffbarr15 comments

Oh wow. This is big! I've been waiting for this for a long time. It's basically Squid in the cloud, but at a scale you couldn't hope to match with your own implementation. We used CloudFront+S3 to serve all of the static resources for DotSpots and I was really impressed with it.

Some small downsides (not fatal): I'm assuming that it shares the standard Cloudfront minimum TTL of one hour right now. It also won't pass through query strings to your origin servers. You can invalidate items in your cache, but the API is a bit odd (it's designed more for DMCA violations than updating content).

This might also solve some of the issues when trying to serve gzip-compressed content from Cloudfront. You had to jump through some hoops to get this working with S3: the data in the bucket had to be gzip compressed and you had to serve different content to different browsers depending on whether they supported gzipped content or not. Hopefully it respects the Vary: header.

This ups the pressure on entrenched CDNs. I love it. For static object delivery and streaming there is no longer any excuse for usurious bandwidth rates, opaque pricing, utter disinterest in smaller customers, and terrible control and monitoring interfaces.

Now AWS needs to focus on CloudFront geography and performance. These go hand-in-hand to some extent, but CloudFront does not fare well even in single node latency tests. I know Amazon has the knowledge and drive to get there, and when they do, I hope they eat the old CDNs' lunch.

Sounds nice, though this one restriction:

  Do not rely on query string parameters. CloudFront does not 
  preserve query string parameters. (For more information, 
  see Query String Parameters.)

Kinda sucks :(

Makes it a not-quite-standard http reverse proxy. We have been putting cache versioning in our query strings, just because it was easier in our framework than changing the base url... but guess we should just fix that.

You should use an ETag in your HTTP request header to do versioning, and keep the URL static.

No.

The better way is to change the URL -- then you setup your ETags + Cache-Control so that the object never expires, ever.

http://journal.paul.querna.org/articles/2007/06/06/mod_never...

I am going to cope with this using an apache rewrite. E.g.

/resources/screen_ver<any code>.css -> /resources/screen.css

Should be simple to remove any _ver<any> string from the url via apache.

If you contact a Tier 1 CDN directly without a decent commit, you will not even be entertained, but you can always find resellers. Akamai pay as you go pricing was just around 150$/TB pricing with resellers and we have used them for a long time. We gave up on CF after speed issues in Asia. Akamai is the strongest across the globe

What reseller are you using? We were using VPS.net, but they informed us last week that Akamai had terminated their reselling contract and they were migrating users to Level3.

Same here, right now we are using google app engine as a CDN. Not sure I want to use Level3.

  Akamai pay as you go pricing was just around 150$/TB pricing with resellers

Who resells at this rate other than VPS.net? There's a reason Akamai terminated their contract. I haven't found another legitimate reseller that's anywhere close, and Akamai direct is 3x that rate for say a small TB/month commit.

Level3 does not appear to have an Asian CDN presence. [Edit: I'm wrong. They do have CDN nodes in Asia, but man it's hard to find a map.]

EdgeCast is an excellent alternative. ThePlanet resells them at under $0.20 per GB but I've been having trouble getting them to take our business now that the SoftLayer merger has closed. Many other resellers are out there ar less competitive rates, e.g. GoGrid and SpeedyRails.

One area CDNs seem to miss out on is India. Most of the ones I've seen including Level3 have their pops in SG/HK. Only Bitgravity and Akamai have India pops

Thanks for the lead on theplanet. The edgecast pricing is not bad :)

Anyone using CloudFront in production care to share their experience?

Now that they have the ability to invalidate files, there is only one lingering issue. On Mac (Firefox, Chrome and Safari) our image assets aren't delivered 100% of the time. According to the AWS team, it's due to an IPV6 bug.

Great! The article seems to suggest that this only works from amazon origins (e.g. EC2 or load balanced EC2 instances), not arbitrary servers. Can anyone confirm or deny?

You can use any origin, EC2 or otherwise. The diagram shows just one way to use it.

Reply on news.ycombinator.com