Amazon Aurora / RDS now supports db.r8a with AMD EPYC processors
This page has been translated by machine translation. View original
Introduction
Amazon Aurora and Amazon RDS now support the db.r8a instance class, featuring 5th generation AMD EPYC processors. The supported engines are MySQL and PostgreSQL-compatible engines.
This article introduces the features of db.r8a and the results obtained by actually launching Aurora PostgreSQL 17.4 on a db.r8a.large instance and checking it via the Data API.
Comparing DB Instance Families
Comparing the large size across r7i / r8a / r8g, the results are as follows. Pricing was retrieved using the AWS Price List API (aws pricing get-products) for the Tokyo region, Aurora PostgreSQL, standard storage, on-demand pricing (as of 2026-10-01).
| Instance | vCPU | Physical Cores | Memory | Processor | Price ($/hr) |
|---|---|---|---|---|---|
| db.r7i.large | 2 | 1 | 16 GiB | Intel Xeon Scalable (Sapphire Rapids) | $0.35 |
| db.r8a.large | 2 | 2 | 16 GiB | AMD EPYC 5th Gen | $0.4226 |
| db.r8g.large | 2 | 2 | 16 GiB | AWS Graviton4 | $0.333 |
The r7i has SMT (Hyper-Threading) enabled, providing 1 physical core as 2 vCPUs. In contrast, r8a and r8g have SMT disabled, meaning 1 vCPU = 1 physical core. While r8a is approximately 20% more expensive than r7i, its key feature is that it doubles the number of physical cores for the same vCPU count while remaining on x86.
The db.r8a sizes range from large to 48xlarge, with pricing proportional to the number of vCPUs.
| Instance | vCPU | Memory | Price ($/hr) |
|---|---|---|---|
| db.r8a.large | 2 | 16 GiB | $0.4226 |
| db.r8a.xlarge | 4 | 32 GiB | $0.8452 |
| db.r8a.2xlarge | 8 | 64 GiB | $1.6904 |
| db.r8a.4xlarge | 16 | 128 GiB | $3.3808 |
| db.r8a.8xlarge | 32 | 256 GiB | $6.7616 |
| db.r8a.12xlarge | 48 | 384 GiB | $10.1424 |
| db.r8a.16xlarge | 64 | 512 GiB | $13.5232 |
| db.r8a.24xlarge | 96 | 768 GiB | $20.2848 |
| db.r8a.48xlarge | 192 | 1536 GiB | $40.5696 |
Launching Aurora PostgreSQL
The versions of Aurora PostgreSQL that support db.r8a are 14.17 / 15.10 / 16.8 / 17.4 / 18.3 and later.
In CloudFormation, specify db.r8a.large for the DBInstanceClass in AWS::RDS::DBInstance. Additionally, to use the Data API, specify EnableHttpEndpoint: true in AWS::RDS::DBCluster (both are excerpts).
DBCluster:
Type: AWS::RDS::DBCluster
Properties:
Engine: aurora-postgresql
EngineVersion: "17.4"
EnableHttpEndpoint: true
DBInstance:
Type: AWS::RDS::DBInstance
Properties:
DBClusterIdentifier: !Ref DBCluster
DBInstanceClass: db.r8a.large
Engine: aurora-postgresql
Checking via the Data API
Some default parameters for Aurora PostgreSQL are determined based on the number of vCPUs in the instance. To verify whether the difference in physical core count is reflected in these values, I retrieved 4 worker-related parameters via the Data API. The cluster ARN and secret ARN are used for the connection.
aws rds-data execute-statement \
--resource-arn "$CLUSTER_ARN" \
--secret-arn "$SECRET_ARN" \
--database postgres \
--sql "SELECT name, setting FROM pg_settings WHERE name IN ('max_worker_processes','max_parallel_workers','max_parallel_workers_per_gather','max_parallel_maintenance_workers') ORDER BY name" \
--region ap-northeast-1
| name | setting |
|---|---|
| max_parallel_maintenance_workers | 2 |
| max_parallel_workers | 8 |
| max_parallel_workers_per_gather | 2 |
| max_worker_processes | 8 |
In the default parameter group for Aurora PostgreSQL 17, the formula GREATEST(vCPU×2, 8) is applied to max_worker_processes. With 2 vCPUs, this results in the lower bound of 8.
Since this formula is determined by the number of vCPUs rather than physical cores, instances with the same vCPU count will have the same value regardless of the instance family. Even for r8a, which has twice the physical cores, the default value is the same as r7i.
In other words, if you use the default parameter group as-is, migrating from r7i will not change the default worker-related values. On the other hand, if you had manually adjusted the worker count to match the physical core count on SMT-enabled instances like r7i, that setting may become insufficient on r8a since the physical core count doubles. It is recommended to review the parameters when migrating.
I also checked version(), which confirmed that it was running as an x86_64 build.
PostgreSQL 17.4 on x86_64-pc-linux-gnu, compiled by x86_64-pc-linux-gnu-gcc (GCC) 10.5.0, 64-bit
Summary
The db.r8a instance class, the first to feature AMD EPYC processors, is now available in Amazon RDS and Amazon Aurora.
For workloads that require the x86 architecture and are currently using r7i or earlier, migrating to db.r8a doubles the number of physical cores for the same vCPU count. However, r8a is approximately 20% more expensive than r7i, and depending on the engine version, an upgrade to a supported version may be required. It is recommended to verify whether the performance gain justifies the price difference, including the differences in CPU characteristics.
This support is limited to MySQL and PostgreSQL-compatible engines. Going forward, it would also be worth looking forward to support for commercial engines where license costs are determined by the number of CPU cores.
