Idle RDS remediation workflow

The opportunity

An RDS instance with low CPU is not necessarily idle. Scheduled jobs, read replicas, failover capacity, and infrequent reporting workloads can all look quiet. A defensible workflow needs multiple signals and enough context to avoid turning a recommendation into an incident.

Evidence to collect

• At least 14 days of CPUUtilization, DatabaseConnections, read/write IOPS, and storage activity from CloudWatch.
• Environment, application, and protection tags, plus recent deployment or incident context.
• Cost and configuration data, including engine, instance class, storage, Multi-AZ state, and reservations.
• A unique match to a Terraform resource, module, repository, root, and accountable team.

OpsTiller would treat Cost Optimization Hub as a supporting signal, not as sufficient authorization to change a database. See the AWS guidance for viewing RDS recommendations.

Proposed review path

The workflow would exclude protected and ambiguous resources, calculate a conservative opportunity, and route the evidence to the service owner. After approval, it could prepare a narrow draft pull request that changes only the agreed instance-class input. Existing CI would produce the Terraform plan; OpsTiller would not merge or apply it.

Immediately before creating that draft, the finding would be revalidated. If connections, utilization, configuration, ownership, or workflow policy changed, the run would stop.

Limitations and risks

Downsizing can increase latency, exhaust memory, or reduce burst capacity. CloudWatch averages can hide short peaks. Savings estimates can also differ from realized billing because of Reserved Instances, Savings Plans, credits, and shared costs. A rollback should restore the prior class through the same Terraform path, and the team should choose an appropriate maintenance window.

Continue with a practical AWS cost optimization workflow or compare the unattached EBS workflow.