Say I have two types of URL requests that must be handled by my REST API:



Only for static images (ie., regex: *.png?.*) do I need to take advantage of CloudFront's caching and the rest of the requests will not get cached data and will need to go to the normal EC2 server (or at least take a speedier indirect route to the normal EC2 server?).

Perhaps the added request time for the misses to CloudFront is irrelevant to worry about?

Or perhaps my situation is not best to use for CloudFront?


You should construct your HTML to use a different URL hostname for static content.

Use firebug to take a look at any big web company's main content.

Facebook (for example) uses http://static.ak.fbcdn.net for static content that I'll assume is using Akamai. (another CDN like Cloudfront) other less static content comes directly from facebook.com.

You can make life a little easier for yourself by using a CNAME.

eg. static.restapi.com --> d1234.cloudfront.net

Then you just need to work on how your pages are presented to use the main hostname for dynamic pages and the static hostname for static content.

You mention 'redirecting' above. I want to make sure you don't try doing HTTP redirects. If your end users has to hit your site to get the redirect, a good portion of the speedup that a CDN provides is already lost. You want one hit for your main page and then have as much content as possible loaded from CDNs that are closer to the end user.

Make sense?

  • 1
    An added benefit to using a different host name for static resources than for dynamic ones is that cookies won't be sent when requesting static resources, which can save some bandwidth, especially if you have lots of cookies and resources. – user83640 May 30 '12 at 23:21

As @JoelK said, you should really be using a different domain for static content. The static domain (e.g. static.restapi.com) would be entirely served by CloudFront, and the dynamic domain (e.g. query.restapi.com) served by your EC2 instance. If you need to restrict access to the static resources, have a look at CloudFront's signed URLs, which allow you to generate URLs which are only valid for a certain time. (Users of the API shouldn't be referring to the static content directly -- the API should provide the location of the static resources.)

If you use an HTTP redirect from your EC2 server to CloudFront you're not going to get any benefit from CloudFront, because clients still need to make that request to EC2 for each static resource.

If for some reason you can't host the static content on a different domain, you could use CloudFront's support for dynamic content. It allows you to configure multiple origins for a CloudFront distribution, so both your static and dynamic content can be served by CloudFront on a single domain.

  • 2
    CloudFront's "support" for dynamic content is a bit misleading; POST requests still return a 403 Forbidden, and there's nothing you can do to avoid that. You can't just drop it in front of a web app like you can with some other CDNs (like some of Akamai's offerings). – user83640 May 30 '12 at 23:23
  • Can you elaborate on this: "you should really be using a different domain for static content" ? Since the current API users are in the habit of using the same API that has the same domain name for static and dynamic content, it is difficult to make two different names. – b_dev May 31 '12 at 6:49
  • @indiehacker The API should provide the URLs of the appropriate static resources when needed -- users of the API should not be hardcoding these locations. If you can't change this however, then using a separate domain isn't an option for you. – mgorven May 31 '12 at 21:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.