Amazon’s global content delivery network (CDN)
Accelerates delivery of your websites, APIs, video content, or other web assets
Integrates with other AWS products
Pay-per-use, with no long-term commitments or minimum fees required
Offers a multi-tier cache by default
Uses regional edge caches to improve latency and lower the load on your origin servers
Provides an additional layer of security for your architectures
Supports real-time, bidirectional communication over the WebSocket protocol
Step 1: Origin Server
You specify an origin server, like an Amazon S3 bucket or your own HTTP server, from which CloudFront gets your files. These will 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 EC2 instance or on servers you manage on premises. These servers are also known as custom origins.
Step 2: Create the distribution
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.
Step 3: Domain name
CloudFront assigns a domain name to your new distribution.
Step 4: CloudFront sends configuration to edge
CloudFront sends your distribution’s configuration, but not the content, to all of its edge locations. Edge locations are collections of servers in geographically dispersed data centers where CloudFront caches copies of your objects.
Source: CloudFront setup
1. Time to Live (TTL)
If you set the TTL for a particular origin to 0, CloudFront will still cache the content from that origin. CloudFront will then make a GET request with an If-Modified-Since header, which gives the origin a chance to signal that CloudFront can continue to use the cached content if it hasn’t changed at the origin.
2. Change object name
The second way requires more effort but is immediate (some CMS systems support this). Although you can update existing objects in a CloudFront distribution and use the same object names, it is not recommended. CloudFront distributes objects to edge locations only when the objects are requested, not when you put new or updated objects in your origin. If you update an existing object in your origin with a newer version that has the same name, an edge location won’t get that new version from your origin until both of the listed events occur.
3. Invalidate object
The third method should only be used sparingly for individual objects: it is a bad solution (the system must forcibly interact with all edge locations).