Our company's experts conducted several performance tests on medium-sized RDS instances (xlarge) running on Intel Xeon and AMD EPYC™ processors.
These were the latest available versions of processors from selected manufacturers (r8i / r8a and m8i/m8a). The goal was to verify the advantage AMD had touted for its 8th-generation CPUs over competing solutions available on the market (in reality, the only one available) by using it as a processor running MS SQL Server.
What AMD EPYC Brings to Microsoft SQL Server
R8a instances are designed for memory-intensive workloads, including SQL and NoSQL.
The 5th-generation AMD EPYC™ runs at frequencies of up to 4.5 GHz, which is beneficial for SQL Server, which places a high priority on single-core performance for short transactions, memory bandwidth for scans and aggregations, and thread scaling for parallel queries. architectural designs.
A tangible benefit—which was AMD’s goal —is cost savings: when the license depends on the number of vCPUs: more work performed on a single core may allow for a smaller number of licensed vCPUs.
AMD Data on MS SQL Server also describe processor variants with high clock speeds (up to 5 GHz), a large number of cores, and high memory bandwidth.
Description of the Experience
We selected in pairs the r8a/r8i and m8a/m8i instances supported by RDS for SQL Server, always in the xlarge size.
The instances have 4 vCPUs and 32 GB of RAM in the R family, and 16 GB in the M family, respectively. The R8a and M8a are based on 5th-generation AMD EPYC™ processors, while the R8i and M8i are based on Intel Xeon 6; all four classes are currently available for RDS for SQL Server (though not in all regions). It’s worth checking out the the RDS engine compatibility table.
The HammerDB TPROC-C workload, which is modeled after TPC-C, was used . For each instance type, a single five-minute run was executed for 5, 10, 25, 50, 100, and 200 virtual users (VUs), with a two-minute ramp-up.
NOPM (New Orders Per Minute) is the number of new orders per minute, and TPM (Transactions Per Minute) is the number of transactions per minute. The graph shows NOPM because it more closely reflects the actual performance of TPROC-C and is easier to compare across runs.
The results for NOPM are as follows:
What exactly can we make of this?
It’s clear that the EPYC™-based instance (the one optimized for memory-intensive workloads) begins to gain an advantage when “it has room to shine”—that is, when the number of users increases.
In the M8, differences up to 100 VU are minor and fall within the typical variability of a single measurement; at 200 VU, both results are nearly identical.
Ten kontrast (R8 <-> M8) jest ważniejszy od jednej liczby „% szybciej”: pokazuje, że charakterystyka całej rodziny i konkretnej konfiguracji RDS-a ma duży wpływ na jakość pracy bazy dla danego scenariuszu. Niewolno przenosić przewagi obserwowanej w R8 na M8 ani z testu syntetycznego bezpośrednio na aplikację produkcyjną.
The TPM chart confirms the same trend: R8a pulls ahead of R8i as the number of VUs increases, while M8a and M8i finish the test nearly tied. TPM should be interpreted as a measure of the benchmark’s overall activity, not as an independent measure of the business order volume—which is why NOPM remains the primary metric.
However, one thing that cannot be said is
An experienced eye will quickly spot a certain degree of sloppiness in the measurements taken…
We ran a default benchmark test using a 100 GB RDS gp3 instance without custom IOPS or throughput settings.
For RDS with MS SQL Server, this means a default 3,000 IOPS and 125 MiB/s. In practice, write performance hovers around 3,000 IOPS, so storage is a real candidate to be the bottleneck for the databases in both tests.
In the measurements obtained, average CPU utilization does not exceed 30%, but the average write latency read from CloudWatch is several hundred milliseconds at many data points. On the R8i, it rises to approximately 577–627 ms at 25–200 VU, while the R8a maintains approximately 176–284 ms.
This correlates with the drop in the R8i's NOPM and is a stronger indicator of log/I/O bottlenecks than CPU saturation.
Microsoft considers consistently high execution times for such operations—exceeding approximately 10–15 ms—to be an indication of an I/O bottleneck (I/O diagnostics in SQL Server).
To summarize the above—it is possible to optimize the RDS database parameters to allow the CPU to deliver higher performance and, in theory, perform better on the tests described above. However, this does not prove that Intel would be weaker or stronger once the I/O limitation is eliminated.
For SQL Server, you can increase both IOPS and throughput on gp3, and for scenarios requiring predictably low latency, consider io2. A sound next step is to replicate the entire array with storage parameters optimized for log writing and based on SQL Server wait stats.
Equally important is the other side of the result: in this minimal, common configuration , the AMD R8a maintained better throughput and lower write latency than the R8i.
This is a practical benefit for a team that starts with a simple and cost-effective infrastructure profile—not a one-size-fits-all decision regarding CPUs.
A simple example of potential savings with the same bandwidth
The following comparison table applies only to the R8 pair and the 14,497 NOPM, achieved by a single db.r8a.xlarge at 200 VU.
db.r8i.xlarge reached a maximum of 8,970 NOPM, so to handle such a volume, we would need to assume two Intel instances—and that’s only in a hypothetical architecture that allows OLTP to be split between two independent primary/shards. This is not an automatic scaling mechanism for a single SQL Server database, nor is it a recommendation to replace a larger instance with a read-only replica.
KEY VARIABLES:
Financial Assumptions: On-Demand, Single-AZ, eu-central-1 (Frankfurt), SQL Server Standard License
Included: 730 h/month, excluding storage, data transfer, backups, Multi-AZ, and taxes.
The current AWS pricing for the new instance types separates infrastructure costs (per CPU-h) from licensing costs (per vCPU-h). For xlarge instances, at least 4 vCPUs are licensed per instance; thus, one AMD instance equals 4 licensed vCPUs, and two Intel instances equal 8 vCPUs (RDS for SQL Server pricing)
In this model, the licensing difference is just as important as the infrastructure difference: twice as many instances means twice as many minimum, four-processor licensing packages. In the "License Included" model, AWS does not purchase a separate Microsoft license—it is included in the RDS billing; for new families, AWS shows it as a separate billing component (the "License Included" and "Optimize CPU" policies).
And where is Graviton?
AWS Graviton are ARM processors, not x86.
They offer excellent price-performance for engines and applications available on ARM/Linux—such as RDS PostgreSQL, MySQL, and MariaDB—but the current Graviton-based RDS instances do not support Microsoft SQL Server.
For SQL Server, x86— AMD or Intel—remains the practical choice . Graviton makes sense as part of a separate modernization path, when the engine, extensions, and application are ready for ARM; it is not a “swap-out” replacement for this test (RDS class support, AWS results for RDS on Graviton4).
Summary
The figures above do not mean that AMD will always be cheaper.
For the M8, the test results are similar, so there is no basis for claiming similar power savings for these processor types:
(M-series—general-purpose). The R8 ratio may also change after increasing the IOPS or throughput.
This model also shows significant potential for achieving real-world benefits through the use of R8a-type processors. However, before making a production decision, you should run the numbers through the AWS Pricing Calculator for the selected instance type, HA, and storage, and conduct load tests that more closely resemble real-world production scenarios than the default TPC-C benchmark.
db.r8a.xlarge is a reasonable candidate for pilot deployment in "memory-intensive" RDS for SQL Server environments, especially when the current profile indicates higher per-core workload or planned scaling. db.m8a.xlarge did not show a clear advantage over db.m8i.xlargein this test; therefore, the decision between them should be based primarily on price, required memory, and repeatable application testing.