CloudFront introduction

Amazon CloudFront is a web service that speeds up distribution of static and dynamic web content, such as .html, .css, .js, and image files, to end users by delivering relevant content through a worldwide network of data centers called edge locations that provide the lowest latency

How CloudFront delivers content to end users

The process is described in details as below:

1. A user accesses the given website or application and requests one or more objects, such as an image file and an HTML file.

2. DNS routes the request to the CloudFront edge location that can best serve the user's request, typically the nearest CloudFront edge location in terms of latency, and routes the request to that edge location.

3. In the edge location, CloudFront checks its cache for the requested files. If the files are in the cache, CloudFront returns them to the user. If the files are not in the cache, it does the following:

   1. CloudFront compares and forwards the request for the files to the applicable origin server for the corresponding file type—for example, to Amazon S3 bucket for image files and to HTTP server for the HTML files.

   2. The origin servers send the files back to the CloudFront edge location.

   3. As soon as the first byte arrives from the origin, CloudFront begins to forward the files to the user. CloudFront also adds the files to the cache in the edge location for the next time someone requests those files.

Image Added

How to configure CloudFront to deliver content

1. We start with configuring origin servers, from which CloudFront gets files for distribution from CloudFront edge locations all over the world.

   An origin server stores the original, definitive version of objects. If we're serving content over HTTP, the origin server is either an Amazon S3 bucket or an HTTP server, such as a web server. The HTTP server can run on an EC2 instance or on an on-premise server that we manage; these servers are also known as custom origins.

   If we distribute media files on demand using the Adobe Media Server RTMP protocol, the origin server is always an Amazon S3 bucket.

2. The we upload files to the origin servers. The files, also known as objects, typically include web pages, images, and media files, but can be anything that can be served over HTTP or a supported version of Adobe RTMP, the protocol used by Adobe Flash Media Server.

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

3. Then we create a CloudFront distribution, which tells CloudFront which origin servers to get the files from when users request the files through our web site or application. At the same time, we specify details such as whether we want CloudFront to log all requests and whether we want the distribution to be enabled as soon as it's created.

4. CloudFront assigns a domain name to our new distribution and displays it in the CloudFront console or returns it in the response to a programmatic request, for example, an API request.

   • We use this domain name for any content we want to serve with CloudFront
   • CloudFront also supports custom domain for distribution

5. CloudFront sends our distribution's configuration (but not our content) to all of its edge locations—collections of servers in geographically dispersed data centers where CloudFront caches copies of our objects.

Image Added

Ideas of integrating Magnolia with CloudFront

How can we support client to use CloudFront?

• Is it an option for client to decide to buy or not when they sign the contract?
• Shall we implement a Magnolia module to let client work with CloudFront configuration? (i.e edit CloudFront distribution configurations)
  • Create CloudFront distribution after client feels OK

Image Added

First proposed workflow:

...

1. Magnolia Cloud user with granted permissions can access author instance for relevant applications
   1. Traditionally, user will work with assets stored in JCR via Assets app
   2. We also support Amazon S3 storage with S3 browser app. With this S3 app, user can create buckets, upload objects, and use them as normal assets 
2. Magnolia Cloud user will then work with CloudFront app to create distribution
   1. For assets stored in tranditional JCR, user will use the either the URL of author or public instance as the Origin domain name (public instance is recommended)
   2. For assets managed with S3, user will use the bucket URL as the Origin domain name (example: <bucket_name>.s3.amazonaws.com)

3. After CloudFront distribution has been created, a generated domain name will be returned (example: d22ze7mvgz7e1v.cloudfront.net). This is the domain name that will replace the normal domain name to take advantage of CDN support

   For Magnolia Cloud user, the URL transformation will be handled transparently within the Magnolia API

   Code Block
   language xml theme RDark
   <img src="${damfn.getAssetLinkWithCDN('s3:/myBucket/myFolder/my-asset.png')}" />

   If user uploads a new version of assets, then this "magical" method will generate an updated link and everything else for invaliadating cache should work like a charm so there will be no user's intervention too!

4. CloudFront also support custom domain if user don't want to go with the default generated domain when creating distribution