Amazon RDS – Consider Using Graviton Instances

The Amazon RDS Graviton policy flags Amazon RDS instances on x86 classes, such as db.m5, and recommends the AWS Graviton equivalent, such as db.m6g. In US East, a Graviton class costs about 10 to 11% less per hour than its x86 equivalent. Apply this policy to any aws_db_instance running RDS for MySQL, MariaDB, or PostgreSQL on an x86 class that has a Graviton equivalent.

Why This Policy Matters

How It Helps Reduce Cloud Costs

Amazon RDS bills each DB instance by the hour for as long as it runs. Production databases run around the clock, so the hourly instance rate becomes a fixed monthly cost.

AWS Graviton processors are Arm-based CPUs designed by AWS. Amazon RDS added Graviton2 classes, db.m6g and db.r6g, in October 2020 for RDS for MySQL, MariaDB, and PostgreSQL.

AWS has since added db.t4g (Graviton2), db.m7g and db.r7g (Graviton3), and db.m8g and db.r8g (Graviton4). Each Graviton class can be selected with the same instance modification used for any other class change.

At the same size, a Graviton class matches the x86 class on vCPU count and memory. A db.m6g.xlarge and a db.m5.xlarge both have 4 vCPUs and 16 GiB of memory.

At the Graviton2 launch, AWS reported up to 52% better price/performance than db.m5 and db.r5 for open-source engines, based on its own testing. Results depend on engine, version, and workload.

The Amazon RDS Graviton switch changes the hourly rate without changing the engine, the endpoint, or the data. That makes it one of the lowest-effort cost changes available for a relational database tier.

Potential Savings

The Amazon RDS Graviton policy saves money because the Graviton class costs less per hour than the x86 class it replaces.

Monthly figures assume 730 hours at US East (N. Virginia) on-demand rates for Single-AZ deployments. Prices vary by region, engine, and purchase option, and Multi-AZ deployments cost roughly double.

Moving one db.m5.xlarge to db.m6g.xlarge saves about $28 per month on MySQL, or roughly $340 per year. A Multi-AZ deployment doubles that saving, because the standby instance changes class too.

Graviton3 classes are priced differently. For RDS for MySQL in US East, a db.m7g.xlarge costs about $246 per month, more than db.m6g.xlarge but less than db.m5.xlarge. Teams choosing db.m7g trade part of the rate saving for a faster processor.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show an Amazon RDS for PostgreSQL DB instance on an x86 class, and the corrected configuration on Graviton.

Non-compliant configuration: Amazon RDS DB instance on db.m5

resource "aws_db_instance" "orders" {
  identifier              = "orders-db"
  engine                  = "postgres"
  engine_version          = "16"
  instance_class          = "db.m5.xlarge"
  allocated_storage       = 200
  storage_type            = "gp3"
  db_subnet_group_name    = aws_db_subnet_group.private.name
  vpc_security_group_ids  = [aws_security_group.db.id]
  multi_az                = true
  backup_retention_period = 7
  username                = var.db_username
  password                = var.db_password
}

resource "aws_db_instance" "orders" {
  identifier              = "orders-db"
  engine                  = "postgres"
  engine_version          = "16"
  instance_class          = "db.m5.xlarge"
  allocated_storage       = 200
  storage_type            = "gp3"
  db_subnet_group_name    = aws_db_subnet_group.private.name
  vpc_security_group_ids  = [aws_security_group.db.id]
  multi_az                = true
  backup_retention_period = 7
  username                = var.db_username
  password                = var.db_password
}

resource "aws_db_instance" "orders" {
  identifier              = "orders-db"
  engine                  = "postgres"
  engine_version          = "16"
  instance_class          = "db.m5.xlarge"
  allocated_storage       = 200
  storage_type            = "gp3"
  db_subnet_group_name    = aws_db_subnet_group.private.name
  vpc_security_group_ids  = [aws_security_group.db.id]
  multi_az                = true
  backup_retention_period = 7
  username                = var.db_username
  password                = var.db_password
}

This configuration pays the x86 hourly rate on both the primary and the Multi-AZ standby. This is a common source of wasted spend in databases created from module defaults that predate Graviton classes.

Compliant configuration: Amazon RDS DB instance on db.m6g

resource "aws_db_instance" "orders" {
  identifier              = "orders-db"
  engine                  = "postgres"
  engine_version          = "16"
  instance_class          = "db.m6g.xlarge"
  allocated_storage       = 200
  storage_type            = "gp3"
  db_subnet_group_name    = aws_db_subnet_group.private.name
  vpc_security_group_ids  = [aws_security_group.db.id]
  multi_az                = true
  backup_retention_period = 7
  username                = var.db_username
  password                = var.db_password
  apply_immediately       = false
}

resource "aws_db_instance" "orders" {
  identifier              = "orders-db"
  engine                  = "postgres"
  engine_version          = "16"
  instance_class          = "db.m6g.xlarge"
  allocated_storage       = 200
  storage_type            = "gp3"
  db_subnet_group_name    = aws_db_subnet_group.private.name
  vpc_security_group_ids  = [aws_security_group.db.id]
  multi_az                = true
  backup_retention_period = 7
  username                = var.db_username
  password                = var.db_password
  apply_immediately       = false
}

resource "aws_db_instance" "orders" {
  identifier              = "orders-db"
  engine                  = "postgres"
  engine_version          = "16"
  instance_class          = "db.m6g.xlarge"
  allocated_storage       = 200
  storage_type            = "gp3"
  db_subnet_group_name    = aws_db_subnet_group.private.name
  vpc_security_group_ids  = [aws_security_group.db.id]
  multi_az                = true
  backup_retention_period = 7
  username                = var.db_username
  password                = var.db_password
  apply_immediately       = false
}

The instance_class value is the only functional change. Setting apply_immediately = false defers the class change to the next preferred maintenance window instead of restarting the database on apply.

Terraform updates the existing Amazon RDS DB instance in place. The data, endpoint, and identifier stay the same.

Step-by-Step Fix Instructions

1. Search Terraform code for instance_class values on aws_db_instance resources that use x86 families such as db.m5, db.r5, db.m6i, db.r6i, or db.t3.

2. Check shared modules, .tfvars files, and variable defaults. The instance class often sits in a variable "instance_class" default rather than the resource block.

3. Confirm the engine is RDS for MySQL, MariaDB, or PostgreSQL. RDS for SQL Server, Oracle, and Db2 do not offer Graviton classes.

4. Confirm the engine version supports the target class with aws rds describe-orderable-db-instance-options --engine postgres --engine-version 16.4 --db-instance-class db.m6g.xlarge. An empty result means the combination is not available.

5. Pick the Graviton class with the same size suffix, for example db.m5.xlarge to db.m6g.xlarge, or db.r5.large to db.r6g.large.

6. Change instance_class, and set apply_immediately = false if the change should wait for the maintenance window.

7. Run terraform plan and confirm it shows an in-place update to instance_class, not a replacement of the Amazon RDS DB instance.

8. Apply the change to non-production databases first. Watch CPUUtilization, ReadLatency, and WriteLatency in Amazon CloudWatch before moving production.

9. Add Infracost to CI/CD so new x86 Amazon RDS instance classes are flagged in pull requests before they merge.

Best Practices

• Default new Amazon RDS databases to Graviton classes in shared Terraform modules, and require a stated reason to use an x86 class.

• Migrate non-production databases and read replicas first. These carry the least risk if a performance difference appears.

• Review Reserved Instances before migrating. An Amazon RDS Reserved Instance covers one instance family, so a db.m5 reservation does not apply to db.m6g usage.

• Upgrade old engine versions before or alongside the class change, since Graviton classes have minimum engine versions.

• This policy targets processor architecture only. Right-sizing an over-provisioned database is a separate decision that often saves more.

An example validation block that limits a shared module to Graviton classes:

variable "instance_class" {
  type    = string
  default = "db.m6g.large"

  validation {
    condition     = can(regex("^db\\.[mrtx][0-9]+gd?\\.", var.instance_class))
    error_message = "Use an AWS Graviton instance class such as db.m6g, db.r6g, or db.t4g."
  }
}

variable "instance_class" {
  type    = string
  default = "db.m6g.large"

  validation {
    condition     = can(regex("^db\\.[mrtx][0-9]+gd?\\.", var.instance_class))
    error_message = "Use an AWS Graviton instance class such as db.m6g, db.r6g, or db.t4g."
  }
}

variable "instance_class" {
  type    = string
  default = "db.m6g.large"

  validation {
    condition     = can(regex("^db\\.[mrtx][0-9]+gd?\\.", var.instance_class))
    error_message = "Use an AWS Graviton instance class such as db.m6g, db.r6g, or db.t4g."
  }
}

Tools and Scripts

How does Infracost detect x86 Amazon RDS instance classes automatically?

The Amazon RDS Graviton policy is available in Infracost, including in the free trial. When Infracost runs in CI/CD, it checks Amazon RDS resources in each pull request. x86 classes with a Graviton equivalent are flagged in the PR comment, with the file and line to change.

The same Infracost pull request comment shows the estimated monthly cost of the change. Reviewers see what a db.m5.xlarge database costs before it merges, not on next month's AWS bill.

Infracost also scans connected repositories for x86 Amazon RDS instance classes already in code. FinOps and platform teams can burn down that backlog over time, tracking issues prevented in pull requests separately from existing issues fixed.

Teams can set the policy to warn engineers or block pull requests. Limiting it to new resources keeps an unrelated pull request from forcing a database restart.

To find x86 Amazon RDS instance classes in a Terraform codebase:

grep -rnE '"db\.(m5|m5d|m6i|r5|r5b|r6i|t3)\.[0-9]*x?(large|medium|small|micro)"' --include="*.tf" --include="*.tfvars"

grep -rnE '"db\.(m5|m5d|m6i|r5|r5b|r6i|t3)\.[0-9]*x?(large|medium|small|micro)"' --include="*.tf" --include="*.tfvars"

grep -rnE '"db\.(m5|m5d|m6i|r5|r5b|r6i|t3)\.[0-9]*x?(large|medium|small|micro)"' --include="*.tf" --include="*.tfvars"

To list running Amazon RDS DB instances with their class, engine, and version using the AWS CLI:

aws rds describe-db-instances \
  --query "DBInstances[].{id:DBInstanceIdentifier,class:DBInstanceClass,engine:Engine,version:EngineVersion,multiAz:MultiAZ}" \
  --output

aws rds describe-db-instances \
  --query "DBInstances[].{id:DBInstanceIdentifier,class:DBInstanceClass,engine:Engine,version:EngineVersion,multiAz:MultiAZ}" \
  --output

aws rds describe-db-instances \
  --query "DBInstances[].{id:DBInstanceIdentifier,class:DBInstanceClass,engine:Engine,version:EngineVersion,multiAz:MultiAZ}" \
  --output

If the database is managed by Terraform, change instance_class in code rather than in the AWS console. Otherwise the next terraform apply sets the old class again.

Examples of Impact

Savings from the Amazon RDS Graviton policy scale with instance count, because the code change per database is one attribute.

Illustrative example: a fleet of service databases. A platform team runs ten Multi-AZ PostgreSQL databases on db.m5.xlarge from an old module default. Changing the module default to db.m6g.xlarge saves about $560 per month at US East on-demand rates, with no application changes.

Illustrative example: non-production databases. A team runs 20 MySQL databases on db.r5.large across development and staging. Switching them to db.r6g.large saves about $360 per month and gives the team a low-risk first step before production.

(These are illustrative scenarios, not specific customer accounts.)

Considerations and Caveats

The Amazon RDS Graviton switch is low risk for open-source engines, but engine support and reservations are where it goes wrong.

• Engine support. Graviton classes are available for RDS for MySQL 8.0 and 8.4, MariaDB 10.4 and later, and PostgreSQL. PostgreSQL needs 12.7 or later for db.m6g and db.r6g. RDS for SQL Server, Oracle, and Db2 do not support them.

• Restart required. Changing instance_class restarts the Amazon RDS DB instance. Single-AZ databases are unavailable during the change, and Multi-AZ databases fail over.

• Reservations do not transfer. Amazon RDS Reserved Instances are tied to an instance family. A db.m5 reservation keeps billing until it expires.

• Modest per-instance saving. At US East on-demand rates, db.m6g and db.r6g cost about 10 to 11% less than db.m5 and db.r5. Larger savings come from fleet size.

• Provider-specific. This policy targets Amazon RDS through the aws Terraform provider. Azure and Google Cloud managed databases do not offer AWS Graviton processors.

Related Policies and Concepts

• Amazon RDS - consider using latest generation instances for m family instances: the generation upgrade for general-purpose Amazon RDS classes, which often precedes or pairs with a Graviton move.

• Amazon RDS - consider using latest generation instances for r family instances: the same generation upgrade for memory-optimized Amazon RDS classes such as db.r4.

• RDS - consider upgrading gp2 storage type to gp3: a companion Amazon RDS policy that lowers storage cost on the same aws_db_instance resource.

• Amazon ElastiCache - consider using Graviton instances: the same Graviton cost change applied to cache nodes such as cache.m6g.

• Amazon OpenSearch - consider using Graviton instances: the Graviton cost change applied to OpenSearch Service data and master nodes.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Amazon RDS Graviton policy is supported in Infracost and available in the free trial. Infracost flags x86 Amazon RDS instance classes, such as db.m5.xlarge, in the pull request comment. The comment includes the file and line to change.

Can this policy be customized?

Yes. Teams can set the Amazon RDS Graviton policy in Infracost to warn engineers or block the pull request. The policy can also be limited to new resources, so an unrelated change does not force a database restart.

Does Infracost automatically fix violations?

No. Infracost reports each Amazon RDS DB instance on an x86 instance class and shows the estimated cost in the pull request. The team picks the Graviton class, tests the workload, and applies the change during a maintenance window.

Is this policy cloud-agnostic?

No. The Amazon RDS Graviton policy targets Amazon RDS through the aws Terraform provider. Azure Database for PostgreSQL and Google Cloud SQL use different machine types and resource names, and neither offers AWS Graviton processors.

Which Amazon RDS engines support Graviton instance classes?

Amazon RDS for MySQL, MariaDB, and PostgreSQL support Graviton instance classes. AWS lists MySQL 8.0 and 8.4, MariaDB 10.4 and later, and PostgreSQL 12.7 and later for db.m6g and db.r6g. Amazon RDS for SQL Server, Oracle, and Db2 do not support Graviton classes.

Does switching an Amazon RDS DB instance to Graviton cause downtime?

Yes, usually a short interruption. Changing the instance class restarts the Amazon RDS DB instance. Multi-AZ deployments reduce the interruption to a failover, which typically takes one to two minutes.

Do applications need code changes to use Amazon RDS Graviton instances?

Usually not. Applications connect to Amazon RDS over the network with the same endpoint and database engine, so client code does not change. The Amazon RDS engine version must still support the Graviton instance class.