How AWS Cloudfront works for both static website and dynamic website when website is externally hosted (not hosted on AWS or S3)?

Viewed 605

I am trying to understand how Cloudfront works. Assume static website is static.com and dynamic website is dynamic.com. static.com has thousands of html files containing img tags referencing images coming from static.com.

dynamic.com is Java based dynamically generating HTML and img tags and images comes from dynamic.com

Assume images are not manually copied to s3. No modifications are made in both sites in regards to Cloudfront other than DNS settings.

Assume Cloudfront url setup for static.com is mystaticxyzz.cloudfront.net and for dynamic.com it is mydynamicxyz.cloudfront.net

2 Answers

CloudFront works as a CDN sitting in front of what are called Origins.

These origins are the endpoints that CloudFront forwards traffic to, to retrieve the response and content. This could be a single server, a load balancer or any other resolvable hostname that is publicly accessible.

If you want to split between static and dynamic content you would create an origin for each type of content within the same distribution. One would be the default origin whilst the other would be matched based on a file path (/css or /images).

Each of these origins can include their own cache behaviours which enable you to define whether they should be cached and how long.

When a user accesses the CloudFront domain dependant on the path it will route to the appropriate origin or retrieve a response from the edge cache where possible.

I know this is rather late, but I am just going to add this here for those struggling to cache dynamic and static content.

Firstly, you need to understand your application your application.

Client Side Rendering

if you have a reactjs you don't need to worry too much about your caching behavior as you will be rendering , the data which will be fetched from an api client side.

none of the static files/content will be changing which are being delivered to the end user.

Since the APIs requests will be coming from a different domain , that data won't be cached by the cdn . Moreover, the data being rendered will update the html via javascript. If your javascript files are continously updating then you can use invalidations for them.

If you have content that is not stored on the origin and your CSR app is fetching the content from using a separate domain from your website domain, you will need to set up a separate cdn and point the domain name to that cdn. You wont need to make any changes to your application as the domain name stays the same for that.

However, if you static content that exists in the same origin (e.g. s3) then you would just request the content using the domain name of the cdn from which the request will come from client to cdn to origin (if not cached / expired)

lastly, assume we have separate origins like an s3 bucket for react app and s3 bucket for images . We can set up a single cdn with multiple origins . This means we can use cloudfront as an aggregator , you will then be able to cache content from different origins by using special paths.

This means , where ever you make calls to those origins previously. i.e. using the the s3 domain names, you would need to update them to that single domain name as the caching behaviors will handle the requests to the respective domains

example: www.example.com(react-app react s3 bucket) www.example.com/images (some s3 image bucket)

<img source={{url:"www.example.com/images/example.jpg"}} />

cloud front will make a request to that server based on that origin for the behavior configured on "/images"

Server Side Rendered

for serverside rendered apps , ideally the default cahcing behavior on the origin should allow all the different http methods , because you will have post and put http requests which you will want cloudfront to forward to the origin .

Make sure that you forward all query strings and cookies to the origin using a request policy. You can fine tune it with white listing query strings or cookies but this will make life easier. Also, the default caching behavior should use a caching policy that disables cache i.e. min,default,max ttls = 0secs . this is because the content is dynamic in nature and gets rendered on the server and not client side thus you will encounter unexpected behaviors in your application depending on how it is set up.

if you have static content on different paths like "/img", "/css" , or "/web/pages/information" cache those independently from the default behavior the respective ttls on them.

you could do some cool stuff using the cache-control header which can by pass the cache if you dont want to configure a 101 behaviors. https://aws.amazon.com/blogs/networking-and-content-delivery/improve-your-website-performance-with-amazon-cloudfront/

Just understand your application and you will be able to leverage cdn properly

if you have a webserver that does a mixture of server side and client side rendering

just identify which paths are client-side rendered and cache those static files.

Any thing that is dynamic in nature that requires the application to make requests to the origin , make use of the caching disabled policy within a behavior.

Moreover, any of those patterns(of using a single cdn with a single/multiple origins or multiple cdns with differing origins ) mentioned earlier is applicable to serverside rendering if some content gets rendered clients side such as images

Related