-: So let's talk about Amazon Aurora
because the exam is starting to ask you
a lot of question about it.
Now, you don't need deep knowledge on it,
but you need enough high level overview
to understand exactly how it works.
So this is what I'm going to give you in this lecture.
Aurora is going to be a proprietary technology from AWS.
It's not open sourced, but they made it
so it's going to be compatible with Postgres and MySQL.
And basically your Aurora database
will have compatible drivers.
That means that if you connect as if you were connecting
to your Postgres or MySQL database, then it will work.
Aurora is very special
and I won't go too deep into the internals.
But they made it cloud optimized.
And by doing a lot of optimization and smart stuff,
basically they get 5x performance improvements
over MySQL on the RDS, or 3x the performance
of Postgres on RDS.
Not just that, but in many different ways
they also get more performance improvements.
To me, I've watch it, it's really, really smart
but I won't go into the details of it.
Now Aurora storage automatically grows.
And I think this is one of the many features
that is quite awesome.
You start at 10 gigabytes,
but as you put more data into your database
it grows automatically up to 128 terabytes.
Again, this has to do with how to design it.
But the awesome thing is that now as a DB or a (indistinct),
you don't need to worry about monitoring your disc.
You just know it will grow automatically with time.
Also for the read replicas, you can have up to 15 replicas,
while MySQL only has five,
and the replication faster,
the way they made it it's much faster.
So overall it's a win.
Now, if you do fail-over in Aurora,
it was going to be instantaneous.
So it's gonna be much faster than a fail-over
from multi AZ on MySQL or RDS.
And because it's cloud native by default
you get high availability.
Now, although the cost is a little bit more than RDS
about 20% more, it's so much more efficient that at scale,
it makes a lot more sense for savings.
So let's talk about the aspect that are super important
which is high availability and read scaling.
So, Aurora is special because it's going to store six copies
of your data, anytime you write anything across 3 AZ.
And so, Aurora is made such as it's available
so it only needs four copy out of six for writes.
So that means that if one AZ is down, you're fine.
And it only means you have three copy out of six
needed for reads.
So again, that means that it's highly available for reads.
There is some kind of self healing process that happens
which is quite cool.
Which is that if some data is corrupted or bad,
then it does self healing with peer-to-peer replication
in the backend and it's quite cool.
And you don't rely on just one volume,
you rely on hundreds of volumes.
Again, not something for you to manage.
It happens in the back end,
but that means that you just reduced the risk by so much.
So if you look at it from a diagram perspective,
you have 3 AZ and you have a shared storage volume
but it's a logical volume.
And it has replication, self healing, and auto expanding
which is a lot of features.
So if you were to write some data, maybe blue data,
you'll see six copy of it in three different AZ.
Then if you write some orange data
against six copy of it in different AZ,
and then as you write more and more data,
it's basically going to go,
again, six copy of it in three different AZ.
The cool thing is that it goes on different volumes
and it's striped, and it works really, really well.
Now we need to know about storage and that's it.
But you don't actually interface with the storage,
it's just a design that Amazon made
and I want to give it to you as well,
so you understand what Aurora takes.
Now, Aurora is like multi AZ for RDS.
Basically there's only one instance that takes writes.
So there is a master in Aurora
and that's where we'll take writes.
And then if the master doesn't work,
the fail-over will happens
in less than 30 seconds on average.
So it's really, really quick fail-over.
And on top of the master,
you can have up to 15 read replicas, all serving reads.
So you can have a lot of them.
And this is how you scale your read workload.
And so any of these read replicas can become the master
in case the master fails.
So it's quite different from how RDS works
but by default, you only have one master.
The cool thing about these read replicas
is that it supports cross region replication.
So if you look at Aurora on the right hand side of diagram,
this is what you should remember.
One master, multiple read replicas
and the storage is gonna be replicated,
self healing, auto expanding,
little blocks by little blocks.
Now let's have a look at how Aurora is as a cluster.
So this is more around how Aurora works
when you have clients,
how do you interface with all these instances?
So, as we said we have a shared storage volume
and it's auto expanding from 10 gigabytes to 128 terabytes,
really cool feature.
Your master is the only thing that will write
to your storage.
And because the master can change and fail-over,
what Aurora provides you
is what's called a writer endpointS.
So it's a DNS name, a writer endpoint
and it's always pointing to the master.
So even if the master fails-over,
your client still talks to the writer endpoint,
and is automatically redirected to the right instance.
Now, as I said before, you also have a lot of read replicas.
What I didn't say is that they can have auto scaling
on top of these read replicas.
So you can have one up to 15 read replicas
and you can set up auto scaling,
such as you always have the right number of read replicas.
Now, because you have auto scaling,
it can be really, really hard for your applications
to keep track of where are your read replicas,
what's the URL, how do I connect to them?
So for it, you have to remember this
absolutely for going for the exam,
there is something called a reader endpoint.
And a reader endpoint has the exact same feature
as a writer endpoint.
It helps with connection load balancing
and it connects automatically to all the read replicas.
So anytime the client connects to the reader endpoint,
it will get connected to one of the read replicas
and they will be load balancing done this way.
Make sure, just notice that the load balancing
happens at the connection level, not the statement level.
So this is how it works for Aurora.
Remember writer endpoint, reader endpoint,
remember auto scaling,
remember shared storage volume that auto expands.
Remember this diagram, once you get it,
you'll understand how Aurora works.
Now, if we go deep into the feature,
you get a lot of things I already told you,
automatic fail-over, backup and recovery,
isolation and security, industry compliance,
push-button scaling by auto scaling,
automated patching with zero downtime.
So it's kind of cool that or magic they do in the backend.
Advanced monitoring, routine maintenance,
so all these things are handled for you.
And you also get this feature called backtrack,
which is giving you the ability to restore data
at any point of time.
And actually doesn't rely on backups,
it relies on something different.
But you can always say I wanna go back
to yesterday at 4:00 pm.
And you say, "Oh, no, actually
"I wanted to do yesterday's 5:00 pm."
And it will work as well, which is super, super neat.
For security, it is similar to RDS
because it uses the same engine.
We have Postgres and MySQL.
So we get encryption at rest using KMS.
We have automated backup snapshots and replicas
that are also encrypted.
Encryption in flight using SSL,
and this is the exact same process we have
for MySQL and Postgres, if you wanted to enforce it.
And we have also authentication using IAM tokens,
which is the exact same method we have seen for RDS,
thanks to the integration with MySQL and Postgres RDS.
You are responsible still for protecting the instance
with security groups, and you cannot SSH into your instance.
So, Aurora security, all in all
is the exact same as RDS security.
So that's it for Aurora.
And I will see you in the next lecture.