Block unapproved RDS instance families

Use a Service Control Policy (SCP) to prevent creation of RDS instances that don't match your approved families.

Why it matters

Without basic guardrails, teams can launch any RDS instance class that looks convenient in the console—often larger, older, or non-standard families that quietly drive up costs and fragment your standards. Service Control Policies (SCPs) let you enforce a small set of approved families and sizes across accounts so that “doing the right thing” is the default, not an exception.

For cost optimization, this is a guardrail, not a tuning knob: it doesn’t save money by itself, but it prevents drift away from your chosen families (for example, Graviton-first, gp3 storage) and reduces the number of outliers you have to chase down later.

When it helps

This kind of SCP is most useful when:

  • You operate multiple accounts/OUs and want consistent RDS standards across teams.
  • You have already defined approved instance families and sizes (for example, “Graviton where supported; dev/test max db.t4g.large”).
  • Cost reviews keep finding random, expensive instance classes that were created ad hoc (for example, older x86 families or oversized test databases).

Practical approach: enforce approved families with an SCP

Attach a Service Control Policy like the following to the OU/Account that you want. It blocks rds:CreateDBInstance whenever the requested instance class isn’t one of the approved families, in this case a single db.t4g.medium class.

This example is intentionally strict to keep the policy easy to read; in real environments you will typically expand the condition to cover a small, approved set of families and sizes (for example, db.t4g.*, db.m7g.* for production, and a narrower set for dev/test) that match your organization’s RDS standards.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNotT4g",
      "Effect": "Deny",
      "Action": [
        "rds:CreateDBInstance"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
            "rds:DatabaseClass": "db.t4g.medium"
        }
      }
    }
  ]
}

In a broader governance story, pair this control with:

  • Tagging standards – Require tags like Environment, Owner, and CostCenter on RDS instances so you can attribute and review spend for each family.
  • Budget alerts and anomaly detection – Configure AWS Budgets or Cost Anomaly Detection for RDS so that unexpected spikes (for example, from new, unapproved instance families) are surfaced quickly and can be tied back to policy gaps.

Resources