Hello and welcome to the final lecture of this course which will summarize the key points taken from the previous lectures which covered RDS, DynamoB, and ElastiCache.

During the lecture which focused on RDS, we learned that for encryption at rest:

• You must specify the encryption option during the database creation
• Enabling encryption at rest encrypts your storage, snapshots, read replicas, and your back-ups
• It is not possible to enable encryption on a database instance after it has been provisioned
• You must specify a CMK, either a Customer managed CMKs or AWS Managed CMK (AWS/RDS)
• If you selected a customer-managed CMK and then that key was disabled, you would not be able to read or write to your database and RDS will move your database instances into a terminal state where it can no longer be accessed
• You must reinstate the KMS key and then recover your database from a previous back-up. The previous RDS instance in a terminal state will still not be accessible
• Encryption is available across all DB engines offered by RDS
• Encryption is not supported across all instance types
• Transparent Data Encryption (TDE) is supported by SQL Server Enterprise Edition and Oracle Enterprise Edition
• Cryptographic operations are transparent to the end-user
• It is recommended you separate your unencrypted and encrypted databases on different instances 

When it came to encryption in transit on RDS, the following points were discussed:

• MySQL, MariaDB, SQL Server, Oracle, and PostgreSQL database engines all support SSL/TLS when communicating between your application and RDS
• RDS will create an SSL certificate and is signed by a certificate authority and the certificates are then installed on the RDS DB instance
• To help prevent and reduce spoofing attacks, the SSL certificate uses the database endpoint as the common name 
• Depending on the DB engine type used, the implementation of SSL/TLS is different and varies between configurations

In the next lecture, I focused on encryption options available for Amazon DynamoDB. During this lecture, I discussed the following.

• By default, DynamoDB tables are automatically encrypted with NO option to disable encryption at rest
• Encryption is provided by integrating with AWS KMS
• Default encryption uses the AWS owned KMS Key
• You can alternatively specify an AWS Managed or Customer managed CMK
• The AWS managed key is defined by its alias of AWS/DynamoDB
• Encryption at rest applies to all data in your table, including your primary key, both your local and global secondary indexes, your global tables, and DynamoDB streams, in addition to your backups
• Cryptographic operations happen transparently to the end-user
• You can change the CMK type at any point of a running database
• There is no charge for the encryption services if the default encryption option is used

When it comes to encryption in transit for DynamoDB, we learned that:

• Normally when your applications communicate with Amazon DynamoDB, they do so using HTTPS
• The DynamoDB encryption client provides the ability to encrypt your table data before you send it to DynamoDB across the network
• The encryption client works by encrypting attribute values which are protected by a signature 
• The client has been designed specifically to work with your applications that are interacting with DynamoDB
• It provides a transparent level of encryption and decryption to your table items
• Key materials can be sourced from your own key material, or by using AWS KMS, or CloudHSM
• Both Java and Python are supported by the encryption client
• The client is not compatible with the Amazon S3 Encryption Client  or the AWS Encryption SDK
• Key components of the client include the:
• Cryptographic Materials Provider (CMP):
• Item Encryptors
• Attribute Actions
• Material Description

In the final lecture, I looked at the ElastiCache service, and the key points to note from this lecture are:

• ElastiCache for Memcached does NOT support encryption

The following points apply to Redis only:

• For both encryption at rest and in transit, you will need to ensure your cluster or replication group are running at least Redis 3.2.6, 4.0.10, or later
• In-transit encryption protects data when it moves between nodes in your cluster or between your application and your cluster
• Encryption at-rest encrypts your data on disk and during both sync and backup operations on your replication groups
• Encryption at-rest can be disabled or enabled
• Enabling encryption at rest allows you to select a default encryption key or you can select a customer-managed CMK 
• Encryption in-transit can be enabled or disabled 
• When enabled data is protected using TLS as it moves between your ElastiCache cluster components
• When in-transit encryption is enabled, Redis AUTH can be selected as an access control option 
• An alternative to using Redis AUTH you can use the ‘User Group Access Control List’ as the Access Control Option 

That now brings me to the end of this lecture and to the end of this course, and so you should now have a greater understanding of the different encryption options available to you when using Amazon RDS, Amazon DynamoDB, and Amazon ElastiCache databases.

Feedback on our courses here at Cloud Academy is valuable to both us as trainers and any students looking to take the same course in the future. If you have any feedback, positive or negative, it would be greatly appreciated if you could contact support@cloudacademy.com.

Thank you for your time and good luck with your continued learning of cloud computing. Thank you.