Hi, Adrian, and welcome back.
Now, in today's video, we are going to discuss about achieving high availability with the cloud front
Origin failover.
Now, one of the things that we need to note is that if the cloud for Origin is down, then it overall
impacts the production environment.
So in this example, I have a simple, easy to instance as a origin to the cloud front.
So if this EC two instance goes down, then all of the users will be affected here.
Now this origin can be a S3 bucket, it can be an application load, balancers, etc. So in order to
overcome this, cloud front has a specific feature which allows us to achieve high availability, considering
there are multiple set of origins.
So in this revised set of architecture, you see that there are two origins here.
One is the EC, two instance in region one, and second one is a backup PC, two instance in Region
two, in case if cloud friend is not able to connect to the primary EC two instance in the region,
one cloud front can automatically failover and send all the requests to this backup PC two in Region
two.
So this is what is referred to as the overall origin failover.
Now, before we proceed further and understand things in more detail, let's have a quick demo to understand
the overall workflow.
Now for today's demo, I have a cloud distribution.
Let's quickly open this up.
Now within here, let's open up the origins.
You see, there are two origins available.
In fact, both of them are easy.
To instance, if you look into the origin domain name, you have a EC to instance, number one and easy
to instance number two.
So the easy two instance number one is in the North Virginia region and the backup PC two is in the
Singapore region.
So first Cloud friend will always send a request to the primary EC two in North Virginia.
If primary EC two fails, then it will send a request to the second receipt.
So let's go ahead and quickly try it out.
First, let's go ahead and open up the URL.
So this is associated with a primary AC two.
So if I'll add it here, you get the default.
Welcome to Engine ICS page.
Let's open up the URL associated with a backup PC two.
Let's add it.
And this time the title has changed from Welcome to Engine X to welcome to backup server.
So from here we can easily identify which server is what.
Now, from cloud front, let's go back.
Let's open the domain name in the browser.
When I enter the domain name as expected, we are seeing Welcome to engine ICS page.
So now let's do one thing.
Let's go ahead and stop this EC two instance.
So let's stop this EC two instance.
So in case if things are working well, the repeated request to cloud front should go to this specific
backup server.
So let's wait for the instance to stop.
So currently it is in the stopping state.
That is fine.
So in case if we copy the URL of the EC two that we just stopped, send a request to that URL.
Again, this is a cache.
That's the reason why it's coming.
Let's do a control for.
And this time, you see, no request is being served.
You can also verify from the ClA if you do a call on this specific URL, you will not really get any
response back, primarily because the instance and the web server are no longer running.
So after a moment here, it basically states connection timed out.
So this time let's send a girl request to the cloud for distribution to see what is the response that
we receive.
And this time you see in the ClA we are getting welcome to back up server.
All right.
So I hope with this at a high level overview, you understood the basics of Origin failover.
Now, before we conclude, there are certain important pointers that you need to note.
First pointer is that if a request has a cache hit, then the cloud friend will straight away return
the requested object.
This is simple to understand.
Second pointer is that if there is a cache miss, then the cloud front routes the request to the primary
origin in the origin group.
Now you have a primary origin and you have the secondary or the backup origin.
The first priority is always the primary origin.
Now, from the primary origin, if cloud front is not able to connect or the primary origin is sending
some kind of a response like Phi X, X or others, then Cloud Friend can go ahead and send a request
to the secondary origin, which is part of the Origin group.
So all of the origins that you configure as primary or secondary, you can configure it as part of the
Origin group.
For example, here we have two origins that are configured along with this.
We also have an origin group that is created.
Now if you look into this Origin group, you have one Origin referred to as a primary origin and one
Origin referred to as a backup origin.
So you can control which one of them you want to be primary or backup.
Apart from that, you can also configure the failover criteria.
So if there is a 500 internal server error that has been returned from the primary origin or bad gateway
that has been returned from the primary origin, etc., or the primary origin fails to respond to the
cloud friend, then the cloud front will send a request to the secondary origin.
Now I also attached a diagram directly from the documentation, which also explains the same thing,
and it becomes easier to revise.
So here the request goes to the cloud front.
If there is a cache hit, then the cloud front will return the response back.
This is something that we have seen.
However, if there is a cache miss, then send a request to the origin.
So this is the primary origin here.
Now, in case if the origin is response with an error, then the request will go to the origin B and
from the Origin B, the data will be returned back to the viewer.
So this is the origin group where you have the primary and the secondary origin.
So that's a high level overview and with this will conclude today's video.