RDS Security: Encryption and Parameter Groups

RDS supports encryption at rest using AWS Key Management Service (KMS). When you enable encryption at DB instance creation, all data on the underlying EBS volumes, automated backups, snapshots, and Read Replicas is encrypted using the specified KMS key.

Encryption must be enabled at creation time—you cannot encrypt an existing unencrypted instance in place. The workaround is to take an unencrypted snapshot, copy it with encryption enabled, and restore from the encrypted snapshot. The KMS key can be an AWS-managed key or a Customer-Managed Key (CMK) for additional control and audit.

Since you cannot enable encryption on an existing instance, follow this migration path:

1. Create a manual snapshot of the unencrypted instance
2. Copy the snapshot and enable encryption during the copy, specifying a KMS key
3. Restore a new DB instance from the encrypted snapshot
4. Update your application endpoint to the new instance
5. Delete the old unencrypted instance

This approach incurs some downtime unless you use DMS to keep the new encrypted instance synchronised before cutover.

RDS encrypts data in transit using SSL/TLS. Each engine provides a downloadable CA certificate that your client driver uses to verify the server's identity. To enforce SSL connections, configure the database engine to reject unencrypted connections.

For MySQL, set the parameter require_secure_transport = ON in the parameter group. For PostgreSQL, set ssl = 1 and optionally rds.force_ssl = 1 to reject non-SSL connections entirely. Many Java and Python database drivers also accept a sslmode=require connection string parameter.

Parameter groups are named collections of engine configuration settings that you attach to an RDS instance. They are the RDS equivalent of editing my.cnf on MySQL or postgresql.conf on PostgreSQL, but managed by AWS and versioned per engine family.

AWS provides a default parameter group for each engine version, but its settings cannot be edited. To customise parameters, create a custom parameter group, modify the desired parameters, and associate it with your DB instance. Changes to static parameters require a reboot; dynamic parameters take effect immediately.

After creating a custom parameter group, you modify individual parameters using the modify-db-parameter-group CLI command or the console. Parameters have an apply method: immediate (takes effect without reboot) or pending-reboot (only takes effect after the next instance restart).

Important parameters to know for the exam: max_connections (limit concurrent connections), innodb_buffer_pool_size (MySQL in-memory cache size), log_bin_trust_function_creators (allow stored functions that write to binary log), and rds.force_ssl (force SSL for PostgreSQL).

Option groups are similar to parameter groups but control add-on features for the database engine rather than configuration tuning. They are primarily used with Oracle and SQL Server to enable features like Oracle Application Express (APEX), SQL Server Transparent Data Encryption (TDE), or SQL Server Active Directory authentication.

Each option in an option group may have its own settings. Option groups are versioned per engine family and must be associated with the DB instance. Most open-source engines (MySQL, PostgreSQL, MariaDB) rarely need custom option groups.

RDS supports IAM database authentication for MySQL and PostgreSQL engines. Instead of a static username/password, your application assumes an IAM role and generates a temporary authentication token (valid for 15 minutes) using the generate-db-auth-token AWS CLI command or SDK call.

Benefits include no long-lived database passwords, automatic credential rotation through IAM policies, and centralised access control. The feature requires enabling --enable-iam-database-authentication on the instance and creating a database user mapped to an IAM role.

AWS Secrets Manager can store and automatically rotate your RDS master password and application credentials. When rotation is enabled, Secrets Manager invokes a Lambda function that updates the database password and stores the new value in the secret—your application fetches the latest secret value via the Secrets Manager API, so it always has valid credentials.

When creating an RDS instance in the console, you can opt-in to Secrets Manager management for the master credentials. This eliminates hardcoded passwords in code or environment variables.

RDS instances run inside a VPC and use DB subnet groups to define which subnets (across multiple AZs) the instance can be placed in. Best practice is to place RDS in private subnets with no direct internet access.

Security groups control which IP addresses and other security groups can reach the DB port (e.g., TCP 3306 for MySQL). The application tier's security group should be the only allowed source on the RDS security group, enforcing network-level least privilege. Never configure 0.0.0.0/0 (all traffic) as an inbound rule on an RDS security group.

Enhanced Monitoring publishes OS-level metrics (CPU, memory, file system, disk I/O) to CloudWatch Logs every 1–60 seconds, giving finer granularity than the default 60-second CloudWatch metrics. It uses an agent running on the DB host, available for all engines except SQL Server mirroring mode.

Database audit logs (general query log, slow query log for MySQL; pgaudit for PostgreSQL) can be published to CloudWatch Logs for compliance analysis. Enable these through parameter groups, then configure the log exports in the RDS console under Log exports.

Key RDS security best practices for the SAA-C03 exam:

• Enable encryption at rest with a KMS CMK when creating the instance
• Enforce SSL/TLS in transit via parameter group settings
• Place instances in private subnets with restrictive security groups
• Use IAM database authentication or Secrets Manager to avoid static passwords
• Enable CloudTrail to log RDS API calls and CloudWatch Logs for database audit logs
• Use AWS Config rules (e.g., rds-instance-public-access-check) to detect misconfigurations

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: RDS encryption at rest uses KMS and must be enabled at creation, parameter groups control engine configuration including enforcing SSL/TLS in transit, and IAM database authentication and Secrets Manager eliminate static database passwords. Next up we explore DynamoDB tables, items, and primary key design.