So, now let's talk about KMS Multi-Region keys.
So, we have KMS and we can actually have a Multi-Region key.
That means that you're going to have your primary key
in one selected Region, such as for example, us-east-1.
And then, that key is going to be replicated
to other Regions.
For example, us-west-2, eu-west-1 and ap-southeast-2.
And so the similarity is that
the key material is going to be replicated.
The same key is going to be in other Regions.
And the key ID is going to be the exact same.
So as you can see the key ID slash mrk and then whatever
is the same across all Regions.
And this is the principle behind the KMS Multi-Region keys.
So, what would you use them?
Well, it's a set of KMS keys
that you can use in different AWS Regions
and they can be used interchangeably.
So that means that you can encrypt in one Region
and then decrypt in another Region.
And Multi-Region keys they're possible
because they have the same key ID, the same key material.
And if you have automatic rotation enabled
for the primary key, and it actually rotates
it's going to be also replicated to the other Regions.
So the idea with that, with the Multi-Region key,
you can encrypt in one Region and decrypt
in another Region, and you don't need therefore
to re-encrypt your data
when moving from one Region to the next;
or to make cross Region API calls.
So something to understand though
is that KMS Multi-Region keys are not global.
Okay? You have your Primary and your Replicas.
And each Multi-Region key
is going to be managed independently
with its own key policy and so on.
So it's not recommended to use Multi-Region key,
except in very specific use cases
because KMS likes to have the fact that
a key is bounded to a single Region.
And so the use cases for using Multi-Region keys
is if you want to have a global client-side encryption.
So to be able to encrypt client-side in one Region
and to decrypt client-side in another Region.
or to do encryption on Global DynamoDB tables
or on Global Aurora.
And we'll see this in a second.
So how does it work when you use
Global Tables in DynamoDB and KMS Multi-Region key
with client side encryption?
So the idea is that you want to encrypt
not just the whole table
because this is just at risk encryption.
You want to encrypt actual attributes on your table.
And so that they're only available to specific clients.
Not even to database administrators.
For this we're going to use
the Amazon DynamoDB Encryption Clients.
So let's take an example where we have us-east-1
and ap-southeast-2.
So the KMS service is having a Multi-Region key
which is replicated to another Region.
The Region ap-southeast-2.
And the client application wants to insert data
into a DynamoDB table.
So first is going to encrypt the attribute
that it needs to be encrypted
with the primary Multi-Region key.
So the idea is that the DynamoDB table,
most of the fields will not be encrypted client-side. Okay.
But then one of them, for example
the Social Security number is going to be encrypted.
So this is great because well,
your database administrators
that have accessed your DynamoDB table,
if they don't have access to the KMS key
that we used to encrypt that one attribute,
the Social Security number.
Then they will not be able to access it.
So it gives you a protection even
against the database administrators.
So if this DynamoDB table happens to be a Global Table
then this data is going to be replicated to another Region.
And so this is now in ap-southeast-2.
And thankfully we've decided to encrypt our data,
the attributes, with a Multi-Region key.
And therefore, a client's application
in the ap-southeast-2 Region can retrieve the row,
see that one attribute is encrypted
and then perform an API call
to actually decrypt the attribute
with the replica Multi-Region key.
And this is why we are doing Multi-Region key this instance.
Is it so that client applications in the ap-southeast-2
can do a local API call to KMS
to decrypt that one attribute.
So using this client-side encryption technique
we can protect specific fields or attributes on our data
and only guarantee decryption when our client has access
to an API key.
And thanks to Global Tables
we can make sure the data and the encryption keys
are also replicated together.
So the same concept can be applied to Global Aurora.
So I will go a bit faster.
And this time we're going to use the AWS Encryption SDK.
So we have two Regions
and we have a Multi-Region key in KMS
replicated across these two Regions.
And so the client application wants to encrypt a column
yet to get it is my SSN column.
And this time we put the data into an Amazon Aurora database
with a table.
And so all the data is unencrypted on this one row,
except that one column, which is the SSN, which is encrypted
actually with the, mrk, the Multi-Region key.
Now this is a Global Database.
So that means that the tables are going to be
replicated globally.
And therefore the same data is going to happen to be
in the ap-southeast-2.
And because we have clients in the ap-southeast-2
they're going to get this encrypted data from your table.
And because we are using a Multi-Region key
they can do a local API call to KMS
to decrypt this attribute.
And therefore we have achieved lower latency.
So we've seen that using client-side encryption,
we can also protect this data
even from database administrators.
So if you have a database admin
that accesses your Amazon Aurora database
and wants to access that one column,
the Social Security number.
Unless they have access to the KMS key
they will not be able to read this data
which is very helpful.
So that's it for KMS Multi-Region keys.
I hope you liked it.
And I will see you in the next lecture.