Updating Content on CloudFront

References

• Add and access content that CloudFront distributes
• Use file versioning to update or remove content with a CloudFront distribution
• Customize the URL format for files in CloudFront
• Specify a default root object
• Invalidate files to remove content
• Serve compressed files

Notes

Amazon CloudFront is a web service that speed up distribution of your static and dynamic web content, such as .html, .css, and .js and image files, to your users. CloudFront delivers your content through a worldwide network of data centers called edge locations. When a user requests content that you're serving with CloudFront, the request is routed to the edge location that provides the lowest latency (time delay) so that content is delivered with the best possible performance.

• If the content is already in the edge location with the lowest latency, CloudFront delivers it immediately.
• If the content is not in that edge location, CloudFront retrieves it from an origin that you've defined - such as Amazon S3 bucket, a MediaPackage channel, or an HTTP server (for example, a web server) that you have identified as the source for the definitive version of your content.

CloudFront speeds up the distribution of your content by routing each user request through the AWS backbone network to the edge location that can best serve your content. Typically, this is a CloudFront edge server that provides the fastest delivery to the viewer. Using the AWS network dramatically reduces the number of networks that your users' requests must pass through, which improves performance.

CloudFront charges for data transfers out form its edge locations, along with HTTP and HTTPS requests. Pricing varies by usage type, geographic region, and feature selection. The data transfer from your origin to CloudFront is always free when using AWS origins like Amazon S3, Elastic Load Balancing, or Amazon Gateway.

Amazon CloudFront Pricing- provides a table for AWS pricing.

How to configure CloudFront to deliver your content:

1. You specify origin servers, like an Amazon S3 bucket or your own HTTP server, from which CloudFront gets your files which will then be distributed from CloudFront edge locations all over the world.

• • An origin server stores the original, definitive version of your objects. If you're serving content over HTTP, your origin server is either an Amazon S3 bucket or an HTTP server, such as a Web server. Your HTTP server can run on an Amazon Elastic Compute Cloud (Amazon EC2) instance or on a server that you manage; these servers are also known as custom origins.

2. You upload your files to your origin server, you can make the objects in your bucket publicly readable, so that anyone who knows the CloudFront URLs for your objects can access them. You also have the option of keeping objects private and controlling who access them.

• • If you're using an Amazon S3 bucket as an origin server, you can make the objects in your bucket publicly readable, so that anyone who knows the CloudFront URLs for your objects can access them. You also have the option of keeping objects private and controlling who access them.

3. You create a CloudFront distribution, which tells CloudFront which origin servers to get your files from when users request the files through your web site or application. At the same time, you specify details such as whether you want CloudFront to log all requests and whether you want the distribution to be enabled as soon as it's created.
4. CloudFront assigns a domain name to your new distribution that you can see in the CloudFront console, or that is returned in the response to a programmatic request, for example, an API request. If you like, you can add an alternative domain name to use instead.
5. CloudFront sends your distribution's configuration (but not your content) to all of its edge locations or points of presence (POPs) - collections of servers in geographically-dispersed data centers where CloudFront caches copies of your files.

Using CloudFront with an AWS SDK

When you want CloudFront to distribute content (objects), you add files to one of the origins that you specified for the distribution, and you expose a CloudFront link to the files. A CloudFront edge location doesn't fetch the new files from an origin until the edge location receives a viewer request for them.

CloudFront servers don't determine the MIME type for the objects that they serve. When you upload a file to your origin, it is recommended that you set the Content-Type header field for it.

To update existing content that CloudFront is set up to distribute for you, it is recommended that you use a version identifier in file names or folder names. This helps give you control over managing the content that CloudFront serves.

You can remove files from your origin that you no longer want to be included in your CloudFront distribution. However, CloudFront will continue to show viewers content from the edge cache until the files expire. If you want to remove a file right away, you must do one of the following:

• Use file versioning: When you use versioning, different versions of a file have different names that you can se in your CloudFront distribution, to change which file is returned to viewers. For more information, see Update existing files using versioned file names
• Invalidate the file: Invalidate files to remove content

After you set up your origin with the objects (content) that you want CloudFront to serve your viewers, you must use the correct URLS to reference those objects in your website or application code so that CloudFront can serve it. The domain name can either be CloudFront's autogenerated domain name or a custom domain name.

When you specify directories in your CloudFront distribution, choose either to always use a trailing slash or to never use a trailing slash. CloudFront stores URLs exactly as they are defined, including trailing slashes.

https://d111111abcdef8.cloudfront.net/images/ Use

https://d111111abcdef8.cloudfront.net/images

It’s inconvenient to have to invalidate both URL formats, and it can lead to additional costs. That’s because if you must double up invalidations to cover both types of URLs, you might exceed the maximum number of free invalidations allowed for the month. And if that happens, you'll have to pay for all the invalidations, even if only one format for each directory URL exists in CloudFront.

If you have content that you want to restrict access to, you can create signed URLs.

You can configure CloudFront to return a specific object (the default root object) when a user requests the root URL for your distribution instead of requesting an object in your distribution.

How to Define Root Object

If you don't define a default root object, requests for the root of your distribution pass to your origin server. If you are using an Amazon S3 origin, any of the following may be returned:

• A list of the contents of your Amazon S3 bucket - Under any of the following conditions, the contents of your origin are visible to anyone who uses CloudFront to access your distribution:
• • Your bucket is not properly configured
  • The Amazon S3 permissions on the bucket associated with your distribution and on the object sin the bucket grant access to everyone.
  • An end user accesses your origin using your origin root URL.
• A list of the private contents of your origin -
• Error 403 Forbidden
• • CloudFront returns this error if the permissions on the Amazon S3 bucket associated with your distribution or the permissions on the objects in that bucket deny CloudFront and to everyone.

Invalidate files to Remove Content

If you need to remove a file from CloudFront edge caches before it expires, you can do one of the following:

• Invalidate the file from edge caches. The next time a viewer requests the file, CloudFront returns the origin to fetch the latest version of the file.
• User file versioning to serve a different version of the file that has a different name.

If you want to invalidate multiple files such as all of the files in a directory or all files that begin with the same characters, you can include the * wildcard at the end of the invalidation path.

To invalidate files, you can specify either the path for individual files or a path that ends with the * wildcard, which might apply to one file or to many, as shown below:

• /images/image1.png
• /images/image*
• /images/*

When you specify a file to invalidate, remember the following:

• Invalidation paths are case sensitive
• If your CloudFront distribution triggers a Lambda function on viewer request events, and if the function changes the URI of the requested file, it is recommended that you invalidate both URIs to remove the file from CloudFront edge caches:
• • The URI of the viewer request
  • The URI of the function changed it

If you configured CloudFront to forward a list of headers to your origin and to cache based on the values of the headers, CloudFront edge caches might contain several versions of the file. When you invalidate a file, CloudFront invalidates every cached version of the file regardless of the header values. You can’t selectively invalidate some versions and not others based on header values.

• If you configured CloudFront to forward query strings to your origin, you must include the query strings when invalidating files, as shown in the following examples:
• • /images/image.jpg?parameter1=a
  • /images/image.jpg?parameter1=b
• The query string case is where the wildcard can come in handy.
• The path is relative to the distribution. For example, to invalidate the file at https://d111111abcdef8.cloudfront.net/images/image2.jpg, you would specify /images/image2.jpg.
• You can invalidate multiple files simultaneously by using the * wildcard. The *, which replaces 0 or more characters, must be the last character in the invalidation path.
• If you are using signed URLs, invalidate a file by including only the portion of the URL before the question mark ?.

Invalidate Files

You can use the CloudFront console to create and run an invalidation, display a list of the invalidation that you submitted previously, and display information about an invalidation.

To learn about invaliding objects and displaying information about invalidations, see the following topics in the Amazon CloudFront API Reference.

• CreateInvalidation
• ListInvalidations
• GetInvalidation

aws cloudfront create-invalidation --distribution-id distribution_ID --paths "/*"

If you're invalidating files individually, you can have invalidation requests up to 3,000 files per distribution in progress at one time. This can be one invalidation request for up to 3,000 files, up to 3,000 requests for one file each, or other combination that doesn't exceed 3,000 files. If you’re using the * wildcard, you can have requests for up to 15 invalidation paths in progress at one time.

Invalidate Files Cost

The first 1,000 invalidation paths that you submit per month are free; you pay for each invalidation path over 1,000 in a month. An invalidation path can be found for a single file or for multiple files. The maximum of 1,000 free invalidation paths per month applies to the total number of invalidation paths across all of the distribution paths that you can create with one AWS account.

No additional charge for the first 1,000 paths requested for invalidation each month. Thereafter, $0.005 per path requested for invalidation.

Note: A path listed in your invalidation request represents the URL (or multiple URLs if the path contains a wildcard character) of the object(s) you want to invalidate from CloudFront cache. For more information about invalidation, see Invalidating Objects in the Amazon CloudFront Developer Guide.

Reference