t8i.medium と t3.medium の性能を Next.js ビルド・OpenSSL で実測してみた
はじめに
低コストのバースト可能インスタンスである T8i が GA になり、2026年9月18日の速報記事で CPU 情報と料金を紹介しました。
この記事では、20% 高額な t8i.medium のオンデマンド単価に見合う性能が得られるか、t3.medium と t8i.medium を同一条件で起動し、Next.js の本番ビルド、OpenSSL の暗号処理、dd による 1GiB 書き込みを両インスタンスで実測した結果を紹介します。
検証環境
両インスタンスは同じ AMI、同じ設定の GP3 ボリューム、同じクレジットモードで起動しました。主な差は CPU と Nitro の世代です。
| 項目 | t3.medium | t8i.medium |
|---|---|---|
| CPU | Intel Xeon Platinum 8259CL（Cascade Lake） | Intel Xeon 6975P-C（Granite Rapids） |
| Nitro 世代 | v2 | v6 |
それ以外は両インスタンスで共通です。
| 共通スペック | 値 |
|---|---|
| vCPU | 2 |
| ベースライン性能 | vCPU あたり 20% |
| クレジット付与量 | vCPU あたり 12 クレジット/時 |
| クレジットモード | Unlimited |
| AMI | Amazon Linux 2023.12.20260918 |
| ルートボリューム | GP3 30GiB（3,000 IOPS、125 MiB/s） |
lscpu と /etc/os-release の抜粋（両インスタンス）
t3.medium:
PRETTY_NAME="Amazon Linux 2023.12.20260918"
Model name: Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
CPU(s): 2
t3.medium の Flags 行のうち、暗号処理に関わる主なものと AVX-512 の基本セット:
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
t8i.medium の Flags 行のうち、t3.medium にない暗号処理向け命令:
sha_ni vaes vpclmulqdq gfni
Next.js 本番ビルド時間
dnf でインストールした Node.js v18.20.8 と、create-next-app@15.5.4 で作成した初期テンプレートのままのプロジェクトを使いました。計測しないウォームアップビルドを1回実行したあと、.next を消して next build を実行する処理を3回ずつ測りました。
| インスタンス | 中央値 | 3回の範囲 |
|---|---|---|
| t3.medium | 約35.9秒 | 35.0〜36.7秒 |
| t8i.medium | 約17.2秒 | 17.1〜17.2秒 |
中央値では t8i.medium が約2.1倍速く終わりました。この測定では、公式ブログの「T3 比でコンピュート性能最大70%向上」より大きい差が出ました。
ビルド時間の原文と実行スクリプト
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 の暗号処理
OpenSSL 3.5.8 の openssl speed で、RSA2048 の署名・検証、AES-256-GCM、SHA-256 を測りました。2 vCPU を両方使うために -multi 2 を付け、各処理 5 秒ずつ計測しました。AES-256-GCM と SHA-256 はブロックサイズ別に結果が出るため、最小の16バイトと最大の16KiB を比べます。
| 処理 | ブロックサイズ | t3.medium | t8i.medium | t8i/t3 |
|---|---|---|---|---|
| RSA2048 署名 | — | 1,545.1 回/秒 | 4,132.2 回/秒 | 約2.7倍 |
| RSA2048 検証 | — | 53,795.6 回/秒 | 82,052.2 回/秒 | 約1.5倍 |
| AES-256-GCM | 16バイト | 59.4 MB/s | 167.6 MB/s | 約2.8倍 |
| AES-256-GCM | 16KiB | 3,404.4 MB/s | 15,250.8 MB/s | 約4.5倍 |
| SHA-256 | 16バイト | 43.7 MB/s | 197.8 MB/s | 約4.5倍 |
| SHA-256 | 16KiB | 426.3 MB/s | 2,452.5 MB/s | 約5.8倍 |
MB/s は、openssl speed が 1,000 バイト/秒単位（末尾 k）で出力する値を換算したものです。
AES-256-GCM はブロックが大きいほど差が開きました。SHA-256 は256バイト以上で約5.8〜5.9倍と、ほぼ横ばいでした。lscpu の Flags 行を比べると、t3.medium も AES-NI（aes）や AVX-512 の基本セットを持っています。t8i.medium はそれに加えて SHA-NI、VAES、VPCLMULQDQ、GFNI という暗号処理向けの命令を持っています。
OpenSSL 実測の原文と実行スクリプト
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
AES-256-GCM と sha256 の列は、左から 16、64、256、1024、8192、16384 バイトのブロックサイズです。
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
dd による 1GiB 書き込み
ルートボリューム上の /var/tmp に、bs=1M count=1024、oflag=direct、conv=fdatasync を指定して、1GiB を逐次書き込む処理を3回ずつ実行しました。
| 回 | t3.medium | t8i.medium |
|---|---|---|
| 1回目 | 149 MB/s | 149 MB/s |
| 2回目 | 132 MB/s | 131 MB/s |
| 3回目 | 132 MB/s | 131 MB/s |
2・3回目の値は、GP3 の既定スループットである 125 MiB/s（約 131 MB/s）にほぼ一致しました。GP3 既定設定で単一の逐次 dd を実行したこの測定では、インスタンスを替えても差は出ませんでした。
dd 実測の原文と実行スクリプト
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
まとめ
新しい T8i インスタンスは、今回の測定範囲では t3.medium と比べて、Next.js のビルドは約2.1倍、OpenSSL の暗号処理は約1.5〜5.8倍速くなりました。
T3 は2018年のリリースです。T8i は CPU の世代に加えて、Nitro System も T3 の v2 から v6 へ更新されています。オンデマンド価格は20%高くなりますが、CPU 性能などの向上で処理時間の短縮が期待できる用途ではコスト削減につながります。従来の実行環境の性能不足で待ち時間が長くなっていた場合も、改善が期待できます。
2026年9月時点で、t8i の提供は nano、micro、small、medium（メモリ 4GiB）までです。メモリ 4GiB に収まるワークロードで、t3 の性能不足が課題になっている場合は、ぜひお試しください。
ただし、AMI が新しい Nitro 世代に対応している必要があります。Nitro v5 以降の Linux では ENA ドライバー 2.2.9 以降が必要なため、特に古い AMI で稼働している場合は、事前に評価することをおすすめします。
