Amazon Cloudfront

Working with Distributions    To deliver content through Amazon CloudFront, you create a distribution. This distribution identifies the Amazon S3 bucket or other origin server that holds the original version of your content. Each distribution has a unique domain name that you can use in your web page or application. An example of an Amazon CloudFront domain name is abc123.cloudfront.net. To work with a distribution:

1. You place the original version of your objects in your Amazon S3 bucket or other origin server.
2. You call the CreateDistribution API, which will return your distribution’s domain name.
3. You create links to your objects in your web site or web application using the domain name.

When a client requests a page using that domain name, Amazon CloudFront determines the best edge location to serve your content. If an edge location doesn’t have a copy of the file that the end user requests, Amazon CloudFront will get a copy from the origin server and hold it at the edge location so it’s available for future requests. You can also specify a default file (e.g., index.html) that will be served for requests made for the root of your distribution without an object name specified – for instance, requests made to alone, without a file name.

    By default, files delivered through Amazon CloudFront are publicly readable by anyone on the Internet. However, if you require greater control over who can download or stream your files, you can use Amazon CloudFront’s private content feature. When this option is enabled, Amazon CloudFront will only deliver files or stream media when you say it is okay to do so by securely signing your requests. There is no additional charge for using the private content feature.

     Amazon CloudFront uses the expiration period you set on your files (through cache control headers) to determine whether it needs to check the origin for an updated version of the file. If you expect that your files will change frequently, the best practice is to use object versioning to manage these changes. To implement object versioning, you create a unique filename in your origin server for each version of your file and use the file name corresponding to the correct version in your web pages or applications. With this technique, Amazon CloudFront caches the version of the object that you want without needing to wait for an object to expire before you can serve a newer version.

    You can also remove copies of a file from all Amazon CloudFront edge locations at any time by calling the Invalidation API. This feature removes the file from every Amazon CloudFront edge location regardless of the expiration period you set for that file on your origin server. If you need to remove multiple files at once, you may send a list of files (up to 1,000) in an XML document. The invalidation feature is designed to be used in unexpected circumstances, e.g., to correct an encoding error on a video you uploaded or an unanticipated update to your website’s css file. However, if you know beforehand that your files will change frequently, it is recommended that you use object versioning to manage updates to your files. This technique gives you more control over when your changes take effect and also lets you avoid potential charges for invalidating objects.

    If you wish, you can also choose to receive more information about the traffic delivered or streamed by your Amazon CloudFront distribution by enabling access logs. Access logs are activity records that show you detailed information about each request made for your content. To use this feature, you must be signed up for Amazon Simple Storage Service (S3) – you can do so . You simply create or specify an Amazon S3 bucket you would like to use to store access logs. There are no additional Amazon CloudFront charges for this feature, though normal Amazon S3 charges apply to write, store and retrieve access logs using that service.

    By default, your distributions support peak data transfer speeds of 1,000 megabits per second and peak request rates of 1,000 requests per second. If you expect more than this amount of traffic, please . We will add more capacity to your distributions within 2 business days.

Object Expiration:   

     An object stays in an edge location until it expires. After the object expires, CloudFront must go back to the origin server the next time that edge location needs to serve that object. By default, all objects automatically expire after 24 hours.

     You can specify a longer expiration time by using the Cache-Control, Pragma, or Expires header on the object in the origin server. How you set the headers depends on the particular tool you're using to work with objects in Amazon S3. Consult the tool's documentation for help. For more information about the headers themselves, go to  the RFC 2616 specification.The RFC 2616 specification might recommend maximum values for the headers; however, CloudFront does not restrict their maximum values.
     The minimum expiration time you can specify is one hour. If you specify a minimum time of less than one hour, CloudFront uses one hour.
     When CloudFront serves an object to an end user, the headers and your settings get passed along with the object to the end user.

     The end user cannot use the HTTP Cache-Control, Pragma, If-Modified-Since, or Expires
headers in the GET request to force CloudFront to go back to the origin server for the object. CloudFront  ignores those headers from the end user.

Object Invalidation:

    Invalidation is one way to remove a distribution object from an edge server cache before the expiration setting on the object's header. Invalidation clears the object from the edge server cache, and a subsequent request for the object will cause CloudFront to return to the origin to fetch the latest version of the object.
    However, unlike object expiration, you can use invalidation for any object whenever it is needed.With object expiration, if you want to stop serving an object version prior to the specified expiration time, you must use object versioning to serve a different version.
Cache Invalidation or Object Expiration with Versioning?
To control the versions of objects served from your distribution, you can use either invalidation or object versioning. If you expect that your objects will change frequently, we recommend that you primarily use object versioning. Versioning has these advantages:
• Versioning enables you to control which object a request returns even when the viewer has a version cached locally, or has a version cached behind a corporate caching proxy.
• Because the file name is included in the access logs, versioning makes it easier to analyze the results of object changes.
• Versioning provides a way to serve different versions of objects to different viewers.
• Versioning enables easily rolling forward and backward between object revisions.

Creating Invalidation Requests

 An invalidation request looks like this:

POST /2010-11-01/distribution/[distribution ID]/invalidation HTTP/1.0
Host: cloudfront.amazonaws.com
Authorization: [AWS authentication string]
Content-Type: text/xml
[Other required headers]
<InvalidationBatch>
   <Path>/image1.jpg</Path>
   <Path>/image2.jpg</Path>
   <Path>/videos/movie.flv</Path>
  
<Path>/sound%20track.mp3</Path>
   <CallerReference>my-batch</CallerReference>
</InvalidationBatch>

  Creating an invalidation request involves specifying the distribution containing the object(s) (the Distribution ID), specifying the objects to invalidate (the objects in the Path tags), and specifying the Caller Reference for the invalidation batch request.

Invalidation Limits
   You can make any number of invalidation requests, but you can have only three invalidation requests in progress at one time. Each request can contain up to 1,000 objects to invalidate. If you exceed these limits, you get an error message.
Note
   It usually takes 10 to 15 minutes to complete your invalidation request, depending on the size of your request.
Paying for Object Invalidation
   The first 1,000 object invalidations you request per month are free. After your object invalidation requests exceed 1,000 requests in a month, you pay for each invalidation request on a per-request basis. For specific information about invalidation pricing, go to Amazon CloudFront Pricing.

CloudFront Object Invalidation:
A ture cloud platform for Amazon S3