Menu
Amazon CloudFront
Developer Guide (API Version 2016-09-07)

Format of URLs for CloudFront Objects

When you create a distribution, you receive the CloudFront domain name associated with that distribution. You use that domain name when creating the links to your objects. If you have another domain name that you'd rather use (for example, www.example.com), you can add a CNAME alias. For more information, see Using Alternate Domain Names (CNAMEs).

When you create URLs to give end users access to objects in your CloudFront distribution, the URLs are either public URLs or signed URLs:

Public URLs allow users to access the following objects:

  • Objects on which there are no restrictions.

  • Objects in an Amazon S3 bucket that end users must access through CloudFront but that don't require a signed URL. These objects can't be accessed using an Amazon S3 URL.

Signed URLs are required to access the objects that are specified by a cache behavior that you have configured to require signed URLs. Note that if a request for an object (for example, image.jpg) matches the path patterns for two or more cache behaviors, CloudFront will process the request based on the cache behavior that is listed first in the distribution. If the first cache behavior doesn't require signed URLs and the second cache behavior does require signed URLs, end users will be able to access image.jpg without a signed URL.

For more information about cache behaviors, including path patterns, see Cache Behavior Settings. For more information about signed URLs, see Serving Private Content through CloudFront.

A public URL for an object in an Amazon S3 bucket uses this format:

http://<CloudFront domain name>/<object name in Amazon S3 bucket>

Important

If the distribution serves streaming content, additional characters are required in the path to the file. For more information, see Configuring the Media Player.

For example, suppose you have an Amazon S3 bucket called mybucket. The bucket contains a publicly readable object named /images/image.jpg.

You create a CloudFront distribution and specify mybucket.s3.amazonaws.com as the origin server for this distribution. CloudFront returns d111111abcdef8.cloudfront.net as the domain name for the distribution and EDFDVBD6EXAMPLE as the distribution ID.

The URL you give to end users to access the object in this example is:

http://d111111abcdef8.cloudfront.net/images/image.jpg

For web distributions, if you're storing your content in more than one Amazon S3 bucket, the format of URLs is the same—URLs don't include any information about your Amazon S3 buckets. To route requests to the applicable bucket, you create an origin for each bucket and create one or more cache behaviors that route requests to each origin. The path pattern in a cache behavior specifies which requests are routed to the origin (the Amazon S3 bucket) that is associated with that cache behavior. For more information about the settings for origins and for cache behaviors in a CloudFront distribution, see Values that You Specify When You Create or Update a Web Distribution.

For more information about names and paths for Amazon S3 buckets, see Virtual Hosting of Buckets in the Amazon Simple Storage Service Developer Guide.

Anytime an end user accesses that object, CloudFront serves the object from the appropriate edge location. If the object isn't in that edge location, CloudFront goes to the origin server associated with the EDFDVBD6EXAMPLE distribution (mybucket.s3.amazonaws.com) and gets a copy of the object for the edge location to serve to the end user.

Format of Public URLs for Objects in a Custom Origin

The format of public URLs for objects in a custom origin are much like public URLs for objects in Amazon S3:

http://<CloudFront domain name>/<object name in custom origin>

If your object is in a folder on your origin server, then the CloudFront URL must include the name of the folder. For example, if image.jpg is located in the images folder, then the URL is:

http://d111111abcdef8.cloudfront.net/images/image.jpg

CloudFront gets objects from the domain that you specified when you created the distribution, using the object path and name in the public URL. For example, if the domain for your custom origin is example.com and the object path and name is /images/image.jpg, CloudFront will get the object from the following location:

http://example.com/images/image.jpg

If you're storing your content on more than one custom origin, the format of URLs is the same—URLs don't include any information about the custom origin. To route requests to the applicable custom origin, you add an origin to your distribution for each custom origin and create one or more cache behaviors that route requests to each origin. The path pattern in a cache behavior specifies which requests are routed to the origin that is associated with that cache behavior. For more information about the settings for origins and for cache behaviors in a CloudFront distribution, see Values that You Specify When You Create or Update a Web Distribution.

How Public URLs Affect the Invalidation of Directories

If you use CloudFront URLs that give end users access to directories, we recommend that you always use the same URL format, either with a trailing slash (/) or without, for example:

http://d111111abcdef8.cloudfront.net/images/

http://d111111abcdef8.cloudfront.net/images

Browsers and other web applications will resolve both formats to the same directory. However, CloudFront stores public URLs exactly as they appear in the request. If you want to invalidate a directory, you'll need to specify the exact same directory, including or excluding the slash. If you don't have a standard for how you specify directories, you'll need to invalidate the directory with and without the slash to ensure that CloudFront removes the directory from the edge location. If you've reached the limit for free invalidations for the month, you'll pay for both invalidations even though only one of the directories exists.

Signed URLs allow end users to access objects in a distribution that is configured to serve private content. The URLs include extra information that restricts access to the cached objects. For information about the format of signed URLs, see Serving Private Content through CloudFront.