Amazon CloudFront and Its Primary and Secondary Origins

Nowadays most of the online contents are web service based. A user accesses a specific content, for example a web page, by connecting their client end application (like a web browser) running on their desktop or mobile computing device to the server that hosts the web page. There are billions of websites and webpages. DNS services, online search engines and links on well known ‘portal’ websites help people to find and locate the contents they would like to visit. 

A user’s web client device and the server it visits can be worldly apart: for example, let’s think of a user in Tasmania, Australia that uses its smart phone to visit a website hosted on a server that locates in a data centre in Montreal, Canada, which is more than sixteen thousand kilometres away. They are connected by the Internet. The Internet comprises of millions of inter-connected networks. Traffic on the Internet is routed between the users and the servers through those inter-connected networks in-between. Using the above Tasmania and Montreal example, the data communication between these two far away locations will need to be routed through many network ‘hops’. 

Going through many hops on the public Internet involves increasing delays. Such delays may be problematic for latency sensitive data communication. What can be worse is that the more hops the data communication goes through, the more likely that it will experience delay variations, or jitter, due to the data traffic congestions that may occur dynamically, along the way. Imagine, not only the website you are visiting is not so responsive to load, but the video clips on that website also play with random pauses. It would not be a good experience at all. 

Content delivery technologies have been developed over many years to combat such issues. There are a number of content delivery network services. Among them is Amazon CloudFront. 

Amazon CloudFront is a web service that helps to speed up the distribution of web contents, static and dynamic. CloudFront is made up of a worldwide network of edge locations (data centres for the purpose of content distribution). When the being requested content is served with CloudFront, the content request is routed to the edge location that provides the lowest latency to the user, so that the content is delivered with the best possible performance. Using the above example, when the Montreal web server uses CloudFront to deliver contents, the Tasmania user’s request will be routed to the closest edge location in the Amazon Global Edge Network, in this case Melbourne Australia, to fetch the content. 

If the Melbourne edge location has the content already, been known as the content being cached at the edge location, it will be served directly to this Tasmania user. If the Melbourne edge location does not have the content, CloudFront will fetch the content from the Origin – in this case the web server in Montreal, using AWS (Amazon Web Services) global backbone network – which is faster and more reliable than the public Internet. 

The Origins in CloudFront are the sources holding the definitive version of the contents that are configured in CloudFront. 

CloudFront allows configurations to specify how long the contents stay in a CloudFront cache, before CloudFront asks the Origin of this content about any updated version again. For dynamic contents (contents that tend to change often), a shorter duration would be suitable. This will mean CloudFront asks the Origin more frequently. For static contents, increasing the duration is the way to go, as the users would get faster performance - the contents are more likely to be served directly from the edge cache, and the Origin would be less stressed, as it would receive less requests from CloudFront. 

The other benefit that CloudFront can provide is high availability, or fail-over functionality. CloudFront enables the concept of the Origin Group in which a Primary Origin and a Secondary Origin are defined. 

The Primary Origin will always be attempted first. In following scenarios, CloudFront automatically tries the Secondary Origin:

• The Primary Origin is unavailable, or
• The Primary Origin returns specific HTTP response status codes (that suggest a failure)

It is important to note, that the failover behaviour is per request based. Even if the previous request resulted in visiting the Secondary Origin, CloudFront would still try the Primary Origin first this time.       

Let’s examine the CloudFront behaviours with Origin fail-over configured:

• When the content is cached in the closest edge location and is within the defined caching duration, CloudFront returns the requested content directly to the user.
• When the content is either not cached in that edge location, or that the duration has elapsed, CloudFront forwards the request to the Primary Origin.
• If the Primary Origin returns a status code that is not configured for failover, such as one in the Success class (a code in 2xx) or the Redirection class (a code in 3xx), CloudFront serves the requested content to the viewer (and updated the cache where applicable).
• If the Primary Origin returns an HTTP status code that has been configured as triggers for failover, then the CloudFront routes the request to the Secondary Origin
• If CloudFront can not connect to the Primary Origin, or that the response from the Primary Origin takes longer than the defined timeout value in the defined number of attempts, then the CloudFront routes the request to the Secondary Origin

By default, CloudFront attempts to connect to the Primary Origin three (3) times, each with a ten (10) second timeout. This means it only tries the Secondary Origin after about 30 seconds. If it is desired to reduce the failover time, one should consider reducing one or more of these parameters: Origin connection timeout, Origin connection attempts, and Origin response timeout (this one is only applicable to custom origins).

If the Secondary Origin also fails, CloudFront can be configured to return to the user a custom error page. 

Only several web request types are supported in Origin failovers. Following HTTP method types are supported:

• GET

• HEAD

• OPTIONS

These are the ‘requesting’ or ‘reading’ method types. They do not change the Origin contents. 

Requests with other HTTP method types (such as POST, PUT) will not trigger origin failover. This is likely due to the logic that modifying the contents at the Secondary Origin but not the Primary Origin is worse than advising the user that the content is not available. 

Amazon CloudFront and other modern content delivery network services also provide data security enhancements, such as web application firewalls and the defence to DDoS (Distributed Denial-of-Service) attacks. This will be a topic for another day.    

                                 -- Simon Wang