AWS RDS Deployment: A Step-by-Step Guide

Pinning the exact engine version in Terraform is the only way to avoid "silent" infrastructure drift. I've seen too many projects break because someone left the version open, and a fresh terraform apply triggered an automatic minor upgrade to 16.4 or 16.5, introducing subtle behavioral changes in the database layer. When building for production, explicit control is non-negotiable.

The Dependency Logic

In a standard AI workflow or application stack, the dependency chain dictates the build order: VPC → IAM → Security Groups → RDS → ALB → EC2 ASG → S3+CDN.

I'm tackling RDS now because it's essentially a leaf node in this tree. It requires a VPC (for subnets) and a security group (for network access), both of which are already live. While the ALB also needs these, the Auto Scaling Group (ASG) depends on the ALB's target group. Getting the database layer out of the way first unblocks the backend deployment.

Module Architecture and Configuration

I've isolated the database logic into a modules/rds directory to keep the root configuration clean. The interface is stripped down to only what's necessary:

variable "security_group" {}
variable "subnet_ids" {}

The core instance configuration uses PostgreSQL 16.3. I'm using 20GB of allocated storage for this dev environment, but the critical part is the version pinning:

identifier       = "postgres-db-dev"
db_name          = "notetaker"
engine           = "postgres"
engine_version   = "16.3" 
allocated_storage = 20
username         = "postgres"
port             = 5432

Solving the Parameter Group Conflict

One major pain point when using the terraform-aws-modules/rds/aws community module is that it often defaults to MySQL settings. If you don't audit your parameter groups, you'll end up trying to apply MySQL configurations to a PostgreSQL instance, which will either fail or be ignored.

I had to strip out the MySQL defaults and implement PostgreSQL-specific logging to help diagnose connection pool exhaustion and leaked connections.

The Fix: Replacing MySQL defaults with Postgres logging

# Remove MySQL character set parameters and replace with:
parameters = [
 { name = "log_connections", value = "1" },
 { name = "log_disconnections", value = "1" },
]

These two parameters are essential for real-world debugging. Without them, tracking down why an LLM agent or a backend API is suddenly hitting max_connections becomes a guessing game.

Cleaning Up Option Groups

The same module often ships with MariaDB audit plugins enabled by default. For anyone using PostgreSQL, these are dead weight and can cause configuration errors.

The Bug: The module tried to apply the MARIADB_AUDIT_PLUGIN to a Postgres instance:

# DELETE THIS for PostgreSQL builds
options = [
 {
 option_name = "MARIADB_AUDIT_PLUGIN"
 option_settings = [
 { name = "SERVER_AUDIT_EVENTS", value = "CONNECT" },
 { name = "SERVER_AUDIT_FILE_ROTATIONS", value = "37" },
 ]
 },
]

Since PostgreSQL handles auditing via extensions like pgaudit (which requires shared_preload_libraries in the parameter group rather than a separate option group), I removed this block entirely.

Summary of RDS Best Practices

• Version Pinning: Always specify the minor version (e.g., 16.3) to prevent unexpected upgrades.
• Parameter Validation: Ensure your parameter_group_family matches your engine (e.g., postgres16 for Postgres 16).
• Logging: Enable log_connections and log_disconnections immediately; you'll need them the moment your app starts scaling.
• Clean Modules: Don't trust community module defaults—always check for engine-specific "leakage" (like MariaDB plugins in a Postgres build).