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  

 

Comments

Post a Comment

Popular posts from this blog

AWS Storage Gateway File Gateway with S3 and FSx For Lustre with S3

Image
Cloud data storage is widely used not just by cloud native compute environments but also on-premises computer systems and applications. It has been so as there are tremendous benefits that cloud data storage brings, most of which are difficult or impossible for non-cloud data solutions. These include but not limited to: • Virtually unlimited capacity • The ease of provisioning • Being on-demand • Data durability (through the distribution and replication powered by the cloud) • Cost efficiency • Reduced or eliminated maintenance overhead AWS Storage Gateway is a common storage service for on-premises and AWS cloud hybrid environments – whether it is being in the transition phase of a migration from on-premises to the cloud or that both on-premises and cloud environments will continue to work together and coexist for the times to come. AWS Storage Gateway provides local caching for on-premises application’s latency-improved access to the cloud data storage.   Various protocol
Read more

Fairness Evaluation and Model Explainability In AI

Image
Artificial Intelligence (AI) relies on machine learning and its modelling to provide outcomes. Imagine a credit card company receives hundreds of thousands of applications each year and would like to use AI to do the first round of application filtering. If it is not developed properly, the AI decisions will be skewed with unfairness – such as rejecting a lot more applications from a certain age group, from a certain gender, or from a certain employment history pattern – UNFAIRLY. Please note unfairness is the key issue here – in other words, AI and machine learning inference that is not reflecting the due course in actual situations. This is typically called bias in AI and machine learning. Biases can come from various stages of a machine learning life cycle: • Biases may exist in the pre-training data -  e.g., the dataset to be used in machine learning training has biases in it • Biases may be introduced by the machine learning exercise  Below is a machine learning lifecycle char
Read more

AWS and Generative AI

Image
 Generative Artificial Intelligence, or Generative AI, GenAI, is one of the hottest topics in the recent months. You would ‘have to be living under a rock to not notice this massive topic’.  ‘Generative AI is a branch of AI that focuses on creating new data. It is a subset of machine learning. The goal of generative AI is to create new data that is similar to the data that was used to train the model.’ – texts generated by an AI tool.  Recently I experimented a couple of random text-to-image GenAI tools to observe how generative AI can create contents and how the data generated by different GenAI tools trained by different models is different. My experiment was straightforward: text-to-image GenAI tools ask you to provide some texts as a prompt, and then use this input to generate an image. So that was what I did. The prompt I supplied was: ‘female student graduation photo in front of a white building with flowers in hand in Paris’. Both GenAI tools I tested could output an image withi
Read more