# AWS RDS Deployment: A Step-by-Step Guide

> Source: <https://promptcube3.com/en/threads/2831/>
> Published: 2026-07-24 17:05:11+00:00

# AWS RDS Deployment: A Step-by-Step Guide

`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).

[Next Claude Code Workflow: Recovering Productivity After Burnout →](/en/threads/2819/)

## All Replies （0）

No replies yet — be the first!