Amazon CloudFront Support for Custom Origins

http://aws.typepad.com/aws/2010/11/amazon-cloudfront-support-for-custom-origins.html

by jeffbarr • 16 years ago

54 15 16 years ago

aws.typepad.com

mmastrac• 16 years ago

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.

jbyers2• 16 years ago

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.

pquerna2• 16 years ago

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.

chunkbot• 16 years ago

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

pquerna2• 16 years ago

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...

al_james2• 16 years ago

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.

maverhick3• 16 years ago

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

jread• 16 years ago

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.

maverhick3• 16 years ago

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

jbyers2• 16 years ago

  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.

Derferman• 16 years ago

Anyone using CloudFront in production care to share their experience?

jreposa• 16 years ago

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.

al_james2• 16 years ago

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?

jeffbarr• 16 years ago

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

Amazon CloudFront Support for Custom Origins

Related Stories