RDS Security

RDS Security covers protecting relational databases managed by AWS. RDS supports MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Aurora.

Network Isolation

• Deploy in private subnets: never place RDS in public subnets
• Use security groups to restrict access to application servers only
• No Public Accessibility: set PubliclyAccessible to false

Encryption

• At Rest: AES-256 encryption using KMS keys; must be enabled at creation (cannot encrypt existing unencrypted instance in-place)
• In Transit: enforce SSL/TLS connections; use rds.force_ssl parameter
• Snapshots: encrypted instances produce encrypted snapshots

Authentication

• IAM Database Authentication: use IAM instead of database passwords (MariaDB, MySQL, PostgreSQL, and Aurora)
• Secrets Manager: automatic rotation of database credentials

Monitoring

• Enable Enhanced Monitoring and Performance Insights
• Enable database audit logging (CloudWatch Logs)
• Use Event Subscriptions for security-relevant notifications

How It Goes Wrong in Practice

The headline pattern is the publicly accessible database. It takes two mistakes stacked together: PubliclyAccessible set to true (often to let a developer connect from home during setup) plus a security group rule opening the database port to 0.0.0.0/0. The result is a database endpoint resolvable and reachable from the internet, and internet-wide scanners find open database ports as a matter of routine, then start credential stuffing. Neither mistake alone is fatal; together they are an exposed database. Keep instances in private subnets, keep public accessibility off, and treat any world-open rule on ports 3306, 5432, or 1433 as an incident.

The quieter pattern is the snapshot leak. RDS lets you share manual snapshots with other AWS accounts, and unencrypted manual snapshots can even be made public, restorable by any AWS account, with a single attribute change. A snapshot shared publicly by accident is a full copy of your database handed to the world, and it bypasses every network control you configured on the instance. Two defenses: encrypt everything at creation, because encrypted snapshots cannot be shared publicly at all, and periodically audit snapshot share attributes. Note the sharing quirks: a shared encrypted snapshot cannot be restored directly, the recipient copies it first, and snapshots encrypted with the default KMS key cannot be shared cross-account.

A Practical Check

One command surfaces the three highest-value security attributes across all instances in a region:

aws rds describe-db-instances --query "DBInstances[*].[DBInstanceIdentifier,PubliclyAccessible,StorageEncrypted,IAMDatabaseAuthenticationEnabled]" --output table

You want to see PubliclyAccessible false and StorageEncrypted true on every row. Anything else needs a documented justification or a remediation ticket. To audit snapshot exposure, list which accounts are authorized to restore a given snapshot with aws rds describe-db-snapshot-attributes, and alert on ModifyDBSnapshotAttribute calls in CloudTrail, since that is the API through which sharing, including public sharing, happens.

Frequently Asked Questions

Which engines support IAM database authentication, and how does it work? IAM database authentication works with MariaDB, MySQL, and PostgreSQL on RDS, and Aurora supports it as well. Instead of a password, your application requests an authentication token, a string RDS generates using AWS Signature Version 4. Each token lives 15 minutes and is used only at connection time; the established session is unaffected when it expires. Connections must use SSL/TLS, and you stop storing database passwords in application configuration at all.

Are there gotchas with IAM database authentication? A few worth planning for. It consumes resources on the instance: AWS states you must have between 300 and 1,000 MiB of extra memory on the database for reliable connectivity, which matters on burstable instance classes. CloudTrail does not log generate-db-auth-token calls, so do not expect token issuance in your audit trail. For PostgreSQL, once the rds_iam role is granted to a user, IAM authentication takes precedence over the password, and IAM authentication cannot be combined with Kerberos or used for replication connections. Tokens are also around 1 KB, so verify your drivers do not truncate the password field.

Can someone really expose my data through a snapshot? Yes, and it is one API call: sharing a manual snapshot with the all value makes it restorable by every AWS account. Only unencrypted snapshots can be made public; sharing with up to 20 specific accounts works for encrypted ones too (with a customer managed key the recipient can use). Automated snapshots cannot be shared directly, you copy them to a manual snapshot first, which means an attacker with snapshot permissions in your account can follow that same path. Restrict rds:ModifyDBSnapshotAttribute accordingly.