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
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:
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 yourparameter_group_family
matches your engine (e.g.,postgres16
for Postgres 16).Logging: Enablelog_connections
andlog_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).
Next Claude Code Workflow: Recovering Productivity After Burnout →
All Replies （0） #
No replies yet — be the first!