Welcome back, and in this video,
I want to step through how DynamoDB handles encryption.
Now, this is something you'll need to understand
at a high level for all of the AWS study streams
and in the real world.
If you're studying for the AWS security specialty,
it's especially important.
So let's jump in and get started.
Now, to help you understand how DynamoDB protects your data,
consider this architecture.
We have a table here in the middle,
and let's assume that it's storing sensitive animal data
for the Animals for Life organization,.
To the left of that, we have the DynamoDB endpoint,
and this is the API endpoint
where all accesses to this table move through.
Then on the left, at the top, we have a DynamoDB user
using either the CLI, the console UI, or the API.
At the bottom left,
we have an instance of the DynamoDB encryption client.
And don't worry, if you don't know what that is,
I'll talk about it in a second.
Now, the first thing that I want to step through
is that regardless of how DynamoDB is being accessed,
the communication between whatever is using the product
and the DynamoDB endpoint is using HTTPS.
This means that whatever the data is,
it's wrapped in a layer of encryption, a HTTPS tunnel.
From the perspective of the outside world,
whatever is inside the tunnel is not visible.
If you're connecting to DynamoDB
using the console, the CLI, or API,
you're generally going to have plain text inside the tunnel.
So in this example, plain text data about animals.
Now, the DynamoDB encryption client is a software library
that enables you to include client side encryption
in your applications.
This is different to DynamoDB encryption,
which I'll be covering next.
This encryption client is something you include
in your applications.
It means that your plain text data is encrypted
into cipher text before transit.
This means AWS have no exposure at any point
to your actual data.
It's encrypted before transit.
So even inside the tunnel, there's only cipher text.
Now, why this matters is that between the DynamoDB endpoint
and the table itself, the HTTPS tunnel is stripped away,
leaving only what's inside of it,
which means either plain text,
if you use the CLI console or API,
or cipher text, if you use the DynamoDB encryption client.
Now, this is true,
regardless of how you configure DynamoDB encryption.
Now, in terms of DynamoDB encryption itself,
let's get one thing out of the way.
All DynamoDB tables are encrypted at rest.
There's no longer an option to not use encryption at rest.
The only configuration that's required
is to optionally customize how this encryption is done.
Now, you have three main choices to make
when it comes to configuring encryption within DynamoDB.
The first is to just accept the defaults.
And if you do this,
encryption happens using an AWS-owned KMS key.
You don't see this within your account
and you can't configure it,
but also, you're not charged for it.
So that's it, nice and simple.
You can also choose to customize this
and choose to use an AWS-managed KMS key.
Now, you can see this within your account.
It will be prefixed with AWS forward slash
and then the service name.
You can audit its usage within CloudTrail,
but as it's AWS-managed,
you won't be able to customize the key policy.
Finally, you can choose to use a customer-managed KMS key.
Now, this is visible within your account.
You can also audit its usage,
and you can customize the key policy,
something that's needed for things like cross account usage
or if you have specific organizational requirements.
Now, whatever you decide,
because a DynamoDB table is encrypted,
then this means any indexes of that table, any streams,
any backups, and any global tables are also encrypted.
So that's the encryption architecture.
Now, let's review some considerations.
Firstly, you cannot use a customer-managed key
with DynamoDB accelerator.
Next, any local or global secondary indexes
use the same key as the table.
Backups also use that same key
and any restores require that same key to be initiated.
But restored tables can use different encryption settings.
If you use DynamoDB tables with transactions,
then customer-managed keys do work,
but a temporary copy is stored using an AWS-owned key.
Data in stream still have a 24-hour lifetime
even when a key is disabled.
If you do use customer-managed keys,
and if they're disabled or inaccessible for seven days,
then a table is backed up and archived,
and you'll need to reactivate that key
in order to restore it.
So that's everything that I wanted to cover at a high level
about DynamoDB encryption.
At this point, though, go ahead and complete the video.
And when you're ready,
I look forward to you joining me in the next.