I actually measured the performance of t8i.medium and t3.medium with Next.js build and OpenSSL
This page has been translated by machine translation. View original
Introduction
The low-cost burstable instance T8i has reached GA, and a breaking news article on September 18, 2026 introduced its CPU information and pricing.
In this article, to determine whether the performance of t8i.medium justifies its 20% higher on-demand price, I launched t3.medium and t8i.medium under identical conditions and present the measured results of a Next.js production build, OpenSSL cryptographic processing, and a 1GiB write using dd on both instances.
Test Environment
Both instances were launched with the same AMI, the same GP3 volume configuration, and the same credit mode. The main differences are the CPU and Nitro generation.
| Item | t3.medium | t8i.medium |
|---|---|---|
| CPU | Intel Xeon Platinum 8259CL (Cascade Lake) | Intel Xeon 6975P-C (Granite Rapids) |
| Nitro Generation | v2 | v6 |
Everything else is common to both instances.
| Common Specs | Value |
|---|---|
| vCPU | 2 |
| Baseline Performance | 20% per vCPU |
| Credit Accrual | 12 credits/hour per vCPU |
| Credit Mode | Unlimited |
| AMI | Amazon Linux 2023.12.20260918 |
| Root Volume | GP3 30GiB (3,000 IOPS, 125 MiB/s) |
Excerpts from lscpu and /etc/os-release (both instances)
t3.medium:
PRETTY_NAME="Amazon Linux 2023.12.20260918"
Model name: Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
CPU(s): 2
Key items from the t3.medium Flags line related to cryptographic processing and the basic AVX-512 set:
aes pclmulqdq avx512f avx512dq avx512cd avx512bw avx512vl
t8i.medium:
PRETTY_NAME="Amazon Linux 2023.12.20260918"
Model name: Intel(R) Xeon(R) 6975P-C
CPU(s): 2
Cryptographic processing instructions in the t8i.medium Flags line that are not present in t3.medium:
sha_ni vaes vpclmulqdq gfni
Next.js Production Build Time
I used Node.js v18.20.8 installed via dnf and a project created with create-next-app@15.5.4 left as the initial template. After running one unmeasured warm-up build, I measured the process of deleting .next and running next build three times each.
| Instance | Median | Range of 3 Runs |
|---|---|---|
| t3.medium | ~35.9 seconds | 35.0–36.7 seconds |
| t8i.medium | ~17.2 seconds | 17.1–17.2 seconds |
By median, t8i.medium finished approximately 2.1x faster. This measurement showed a larger difference than the official blog's claim of "up to 70% improved compute performance compared to T3."
Raw build times and execution script
t3.medium:
build_run_1_seconds: 35.916960492
build_run_2_seconds: 36.735701815
build_run_3_seconds: 34.962224565
t8i.medium:
build_run_1_seconds: 17.204068148
build_run_2_seconds: 17.155242872
build_run_3_seconds: 17.089165206
nextjs-bench.sh:
#!/bin/bash
# Next.js production build time benchmark.
# Installs Node.js via dnf, creates a fixed create-next-app project,
# then measures `next build` wall-clock time over 3 clean runs.
set -e
export HOME=/root
echo "### install Node.js"
dnf install -y nodejs npm >/dev/null 2>&1
node -v
npm -v
echo
WORK=/root/nextbench
rm -rf "$WORK"
mkdir -p "$WORK"
cd "$WORK"
echo "### create-next-app (fixed version, non-interactive)"
# Pin Next.js version for reproducibility across both instances.
npx --yes create-next-app@15.5.4 app \
--ts --eslint --app --src-dir --no-tailwind --no-turbopack \
--import-alias "@/*" --use-npm >/tmp/cna.log 2>&1 || { echo "create-next-app FAILED"; tail -40 /tmp/cna.log; exit 1; }
cd app
echo "next version:"; node -e "console.log(require('next/package.json').version)"
echo
# Warm-up install already done by create-next-app. Do a warm-up build first (not measured).
echo "### warm-up build (not measured)"
npx next build >/tmp/warmup.log 2>&1 || { echo "warmup build FAILED"; tail -40 /tmp/warmup.log; exit 1; }
for i in 1 2 3; do
echo "===== next build run $i ====="
rm -rf .next
START=$(date +%s.%N)
npx next build >/tmp/build$i.log 2>&1 || { echo "build run $i FAILED"; tail -40 /tmp/build$i.log; exit 1; }
END=$(date +%s.%N)
echo "build_run_${i}_seconds: $(echo "$END - $START" | bc)"
done
echo "ALL BUILDS DONE"
OpenSSL Cryptographic Processing
I used openssl speed with OpenSSL 3.5.8 to measure RSA2048 signing/verification, AES-256-GCM, and SHA-256. I added -multi 2 to use both vCPUs, and measured each operation for 5 seconds. Since AES-256-GCM and SHA-256 produce results by block size, I compare the smallest (16 bytes) and largest (16KiB).
| Operation | Block Size | t3.medium | t8i.medium | t8i/t3 |
|---|---|---|---|---|
| RSA2048 Sign | — | 1,545.1 ops/sec | 4,132.2 ops/sec | ~2.7x |
| RSA2048 Verify | — | 53,795.6 ops/sec | 82,052.2 ops/sec | ~1.5x |
| AES-256-GCM | 16 bytes | 59.4 MB/s | 167.6 MB/s | ~2.8x |
| AES-256-GCM | 16KiB | 3,404.4 MB/s | 15,250.8 MB/s | ~4.5x |
| SHA-256 | 16 bytes | 43.7 MB/s | 197.8 MB/s | ~4.5x |
| SHA-256 | 16KiB | 426.3 MB/s | 2,452.5 MB/s | ~5.8x |
MB/s values are converted from the output of openssl speed, which reports in units of 1,000 bytes/second (trailing k).
The gap in AES-256-GCM widened with larger block sizes. SHA-256 was approximately 5.8–5.9x faster for block sizes of 256 bytes and above, remaining relatively flat. Comparing the Flags lines in lscpu, t3.medium also has AES-NI (aes) and the basic AVX-512 set. t8i.medium additionally has SHA-NI, VAES, VPCLMULQDQ, and GFNI instructions for cryptographic processing.
Raw OpenSSL measurements and execution script
t3.medium (OpenSSL 3.5.8):
rsa 2048 bits 0.000647s 0.000019s 0.000020s 0.000662s 1545.1 53795.6 49818.4 1510.6
AES-256-GCM 59424.37k 235917.18k 813323.88k 1903725.98k 3281336.73k 3404388.76k
sha256 43733.45k 116845.53k 263877.38k 370632.09k 421629.13k 426301.85k
t8i.medium (OpenSSL 3.5.8):
rsa 2048 bits 0.000242s 0.000012s 0.000013s 0.000244s 4132.2 82052.2 79818.4 4092.2
AES-256-GCM 167606.91k 668037.06k 2376013.11k 5916431.97k 13797631.59k 15250849.79k
sha256 197812.30k 653563.71k 1553203.46k 2174417.31k 2431724.75k 2452491.47k
The columns for AES-256-GCM and sha256 represent block sizes of 16, 64, 256, 1024, 8192, and 16384 bytes from left to right.
openssl-bench.sh:
#!/bin/bash
# OpenSSL benchmark: 3 representative workloads.
# Uses openssl speed with fixed measurement seconds so each run is ~short.
set -e
echo "### openssl version"
openssl version
echo
echo "### CPU model"
grep -m1 'model name' /proc/cpuinfo
# 1) RSA 2048 sign/verify (public-key, multi=2)
echo
echo "===== RSA2048 (multi=2) ====="
openssl speed -multi 2 -seconds 5 rsa2048 2>/dev/null
# 2) AES-256-GCM (symmetric cipher, AES-NI path)
echo
echo "===== AES-256-GCM (evp, multi=2) ====="
openssl speed -multi 2 -seconds 5 -evp aes-256-gcm 2>/dev/null
# 3) SHA-256 (hash)
echo
echo "===== SHA256 (evp, multi=2) ====="
openssl speed -multi 2 -seconds 5 -evp sha256 2>/dev/null
1GiB Write Using dd
I ran the process of sequentially writing 1GiB to /var/tmp on the root volume three times each, specifying bs=1M count=1024, oflag=direct, and conv=fdatasync.
| Run | t3.medium | t8i.medium |
|---|---|---|
| Run 1 | 149 MB/s | 149 MB/s |
| Run 2 | 132 MB/s | 131 MB/s |
| Run 3 | 132 MB/s | 131 MB/s |
The values for runs 2 and 3 closely matched the GP3 default throughput of 125 MiB/s (approximately 131 MB/s). In this measurement running a single sequential dd with the default GP3 configuration, there was no difference between instances.
Raw dd measurements and execution script
t3.medium:
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.18673 s, 149 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 8.14685 s, 132 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 8.1561 s, 132 MB/s
t8i.medium:
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.19115 s, 149 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 8.16967 s, 131 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 8.16802 s, 131 MB/s
dd-bench.sh:
#!/bin/bash
# dd 1GiB write benchmark. 3 runs, each syncs to disk (conv=fdatasync).
set -e
echo "### mount / fs of test dir"
df -T /var/tmp | tail -1
echo "### EBS volume from lsblk"
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
echo
for i in 1 2 3; do
echo "===== dd run $i : 1GiB (bs=1M count=1024) conv=fdatasync ====="
sync
dd if=/dev/zero of=/var/tmp/ddtest.bin bs=1M count=1024 conv=fdatasync oflag=direct 2>&1 || \
dd if=/dev/zero of=/var/tmp/ddtest.bin bs=1M count=1024 conv=fdatasync 2>&1
rm -f /var/tmp/ddtest.bin
echo
done
Summary
Within the scope of this measurement, the new T8i instance was approximately 2.1x faster than t3.medium for Next.js builds, and approximately 1.5x to 5.8x faster for OpenSSL cryptographic processing.
T3 was released in 2018. In addition to the CPU generation, T8i also updates the Nitro System from T3's v2 to v6. While the on-demand price is 20% higher, it can lead to cost savings in use cases where reduced processing times are expected from improved CPU performance. It can also be expected to improve situations where long wait times were caused by insufficient performance in existing execution environments.
As of September 2026, t8i is available up to nano, micro, small, and medium (4GiB memory). If you have workloads that fit within 4GiB of memory and t3 performance has been a bottleneck, please give it a try.
However, the AMI must be compatible with the newer Nitro generation. Linux on Nitro v5 and later requires ENA driver 2.2.9 or later, so if you are running on an older AMI in particular, it is recommended to evaluate this beforehand.
