6.68 RDS AWS Encryption and Security

This lesson focuses on RDS security. For encryption at rest, RDS can encrypt the primary instance and its replicas using AWS KMS with AES-256. Encryption must be enabled at instance creation: if the master is not encrypted, replicas cannot be encrypted either. Transparent Data Encryption (TDE) is also available for Oracle and SQL Server. For encryption in transit, RDS uses SSL/TLS certificates between the client and the database. With PostgreSQL you can enforce SSL by editing the RDS parameter group and setting rds.force_ssl to 1; in MySQL you grant the user only over REQUIRE SSL.

Backup, network and IAM

  • Snapshots inherit the encryption of the source database: an unencrypted DB produces unencrypted snapshots.
  • To encrypt a previously unencrypted DB: snapshot it, copy the snapshot with encryption enabled, then restore a new encrypted DB from it.
  • RDS databases live inside a VPC, in private subnets — security groups control which clients (EC2, Lambda, on-prem via VPN) can connect.
  • IAM policies control who can manage RDS itself (create, modify, delete).
  • Login can use username/password, IAM-based authentication, or Kerberos (Active Directory).

IAM-based authentication is supported on MySQL and PostgreSQL: instead of a password, the client requests a short-lived auth token (15 minutes) via an AWS API call signed with IAM credentials, then uses that token to log in. Benefits: traffic is forced over SSL, IAM centralizes user management, EC2 instance roles can connect without storing secrets.

Responsibility split: AWS manages the underlying instance, OS patches, the engine, and disk encryption mechanics. You as the architect remain responsible for security group rules, public-vs-private accessibility, IAM users and roles, database-level user creation, parameter groups, and SSL enforcement. RDS provides the building blocks; secure architecture is still your job.

Summary

This lesson covers comprehensive RDS security practices in AWS, including encryption mechanisms for data at rest (AWS KMS with AES-256, transparent data encryption) and in transit (SSL/TLS certificates). It explains authentication methods ranging from traditional username/password to IAM-based authentication with temporary tokens, plus network security controls using security groups and IAM policies. The lesson also clarifies the shared responsibility model between AWS and customers for maintaining database security.

Key points

  • At-rest encryption must be enabled during RDS instance creation using AWS KMS with AES-256 standard; unencrypted existing databases require snapshot-based encryption workflow
  • In-transit encryption uses SSL/TLS certificates; enforce this in parameter groups (e.g., rds.force_ssl for PostgreSQL) and grant users SSL-required permissions
  • IAM database authentication (supported on MySQL and PostgreSQL) provides temporary 15-minute tokens via AWS API, eliminating password storage and enabling centralized user management without SSH access
  • Security groups control network-level access with inbound/outbound rules; IAM policies govern who can manage RDS through AWS APIs and what actions they can perform
  • Shared responsibility model: AWS manages infrastructure and patches; customers control security group rules, parameter group settings, user creation, and public access configuration

FAQ

Can I enable encryption on an existing RDS database that wasn't encrypted at creation?

No, encryption must be enabled at instance creation time. To encrypt an unencrypted database, create a snapshot, copy that snapshot and enable encryption during the copy process, then restore a new database instance from the encrypted snapshot. Update your connection strings to point to the new instance.

What are the advantages of using IAM database authentication over traditional username/password?

IAM authentication provides network traffic encryption via SSL (all I/O is encrypted), centralized user and permission management through IAM roles, temporary 15-minute tokens instead of permanent passwords, and simplified integration with AWS services. This reduces the attack surface by eliminating password management overhead.

Who is responsible for database security—AWS or the customer?

AWS is responsible for infrastructure security, at-rest encryption, and OS/database patching. Customers must configure security groups, inbound/outbound rules, parameter group settings, database user creation, IAM policies for API access, and control whether databases are publicly accessible. You cannot access via SSH or manually patch the OS.