Security and Performance

Resilient deployment patterns such as Multi-AZ deployments improve availability during infrastructure failures, while read replicas can offload read traffic and support some recovery strategies. Availability architecture does not address unauthorized access, unpatched vulnerabilities, weak recovery practices, or performance issues that go unnoticed. This lesson shifts from RDS availability patterns to the controls that keep an RDS deployment secure, recoverable, and observable. It covers encryption, access control, network isolation, operational maintenance, backup and recovery, and monitoring. These capabilities use several AWS services and RDS features, including AWS KMS for encryption key management, TLS for encrypting connections in transit, IAM for authorizing AWS API actions against RDS, Secrets Manager for storing and rotating database credentials, VPC security groups for controlling inbound and outbound database traffic, CloudWatch for metrics, alarms, and database logs when log exports are enabled, and RDS event notifications for changes such as failovers, backups, maintenance, and configuration updates.

A guiding principle runs through every topic ahead. Many security and resilience choices in RDS are set at creation time and are difficult or impossible to change later. Encryption at rest cannot be toggled on after launch. Backup retention determines the point-in-time recovery window from day one. Subnet group placement defines network boundaries. Upfront planning is not optional; it is the foundation that everything else builds on. The lesson moves from data protection to access control, then to operational safeguards, recovery patterns, and finally monitoring.

Encryption at rest and in transit

Storage encryption with AWS KMS

Amazon RDS encrypts the underlying storage volume, all automated backups, snapshots, and read replicas using a single KMS customer master key (CMK)A cryptographic key managed by AWS Key Management Service that controls encryption and decryption operations for data at rest across AWS services. selected at instance creation. AWS offers two key types. An AWS-managed key is created automatically in your account and requires no configuration, but it provides limited key policy control. A customer-managed CMK gives full control over key policies, rotation schedules, and cross-account grants, which matters when snapshots must be shared or copied across accounts.

Encryption must be enabled when the DB instance is first created. There is no toggle to encrypt an existing unencrypted instance in place. The accepted workaround is to take a snapshot of the unencrypted instance, create an encrypted copy of that snapshot specifying a KMS key, and then restore a new encrypted instance from the copy. This is a frequent exam scenario and a real-world migration step.

Attention: Read replicas inherit the encryption state of their source. You cannot create an encrypted replica from an unencrypted source, so the snapshot-copy-and-restore path must happen first.

TLS for data in transit

RDS supports TLS/SSL connections between the application and ...