Okay, so now let's talk about routing policies
and this one is going to be for the failover.
So the idea is that we have route 53 in the middle
and we have EC2 instances,
one is going to be our primary EC2 instance,
and the second one is going to be a secondary,
or disaster recovery, EC2 instance.
In this case, what's going to happen is that we're going
to associate our primary record with a health check,
and this is mandatory.
And if the health check it becomes unhealthy,
then route 53 is going to automatically failover
to the second EC2 instance,
and start sending that result back instead.
And of course the secondary EC2 can also be
associated with the health check as well, if we want it to.
But there can only be one primary and one secondary.
Now the client, when it makes DNS requests,
will automatically get the resource that is deemed healthy.
So if our primary is healthy,
then route 53 will answer with a primary record.
But if the health check is unhealthy, automatically,
we will get the response of the second record,
which really helps us do (indistinct) a failover.
So that's it, let's go in the hands-on
to see how we can practice this.
Okay, so now let's leverage these health checks
and create a failover record.
So in my hosted zone, I'm going to create a record,
and this one's going to be called
failover.stephanetheteacher.com,
and it's the A record,
and the first value is going to be
for my EU-central-1 instance, so the one close to me,
and the routing policy is going to be a failover.
So the TTL will set it something really low,
like 60 seconds.
And the failover record type has two options.
It could be either primary or secondary, just these two.
So this is my primary record, and I will associate it
with a health check, I have to.
So it will associate with my health check
named EU-central-1,
and the record ID is going to be E.
So what this is saying is that this record
should be my primary one,
but this is going to be associated with a health check,
which means that you can failover to a second record.
So let's add a new record, and I will keep the record name
as failover.stephanetheteacher.com,
and the value of which is going to be my instance
in US-east-1.
Okay, we're still going to have to do a failover,
the TTL is 60 seconds,
and the failover record type is going to be secondary.
Now we can optionally associate your health check with it,
okay, of US-East-1, but you don't have to.
And the record ID is going to be US.
Now let's create this record,
and notice it was successfully created.
And so let's go back into our health checks.
And currently these two health checks
I've associated with my records are healthy.
So if I go into the URL,
so if I go to failover.stephanetheteacher.com,
right now, I get an answer from EU-central-1c,
That's perfect.
But what I'm going to do is trigger a failure.
So let's go into the EU-central-1 region,
and I'm going to find my instances, here,
and I'm going to find the security group,
and I'm going to, again, stop some security group roles.
So let's refresh this page.
It does exist, that's perfect.
And for the inbound rule, I'm going to edit it,
and it will remove the rule on port A.
So that will make my instance completely unreachable
from the health checkers.
So what I have to do now is to wait for this health check
to become unhealthy,
and then we'll be able to test the failover.
So let's refresh, and as we can see now,
my EU-central-1 health check is deemed unhealthy,
and we can look into the monitoring tab and see
really when it got a unhealthy, so this is quite cool.
So the health checker was positive,
and then it went to zero,
and then we can see how many percentage
of the health checkers did report healthy,
and again, this went one down to zero.
So what this means,
is that now that this health check is unhealthy
because of the way we set up the failover
that was linked to this health check.
Then next time I refresh this,
I should not be in Eu-central-1c,
I should be in US-east-1.
So let's refresh this (indistinct) page,
and yes, the answer is that we are in US-east-1.
And so the failover did work seamlessly behind the scenes.
And while to fix it, you just go back
into your security group, you would edit the inbound rule,
and then you would add back the HTTP rule,
and then automatically the health check
is going to pass again, and therefore we are going to
failover back to our primary location, okay.
So that's it for this lecture, I hope you liked it,
and I will see you in the next lecture.