🙌

高コスパのインスタンスを探そう

に公開

はじめに

こんにちは。e-dash SREチームの伊藤です。

コスパ厨の私は、新しく環境を構築する際、いつも「どのマシンがコスパがいいのかな」と迷ってしまいます。コア当たりの料金だけを単純に比較するでもいいんですが、本当にコアあたりの性能が同じなのか。安かろう悪かろうだとあまり嬉しくないですよね。

そこで、AWS 及び Google Cloud の中で、開発環境や個人開発などに利用される機会の多い比較的リーズナブルなマシンインスタンスを対象に、実際にどれがどの程度コスパ良いのか?についてベンチマークツールを用いて簡単に評価してみました。

※2025年11月時点の情報です。

前提条件

今回の性能評価を行うにあたり、前提条件を以下のように定義します。

評価環境(リージョン、OS、スペック、料金など)

インスタンスタイプ以外の条件は以下の通りです。

  • すべて 東京リージョン (ap-northeast-1) のインスタンスを利用します。
  • すべてオンデマンドインスタンスの費用で計算します。
  • OSは Debian 13 を使用します。(Amazon Linux でもよかったのですが、Google Cloud と統一した方が適正な評価ができることと、sysbench がインストールしやすかったことから今回は Debian にしています)

インスタンスタイプは、各クラウドで人気の高い安価な汎用インスタンスをいくつかピックアップしました。同じコア数でもメモリサイズによって費用が流動的なので、基本的に2 GiB 以上のインスタンスを基準としています。

AWS (Amazon EC2)

インスタンスタイプ vCPU メモリ (GiB) アーキテクチャ 1時間あたりの料金 (USD)
t4g.small 2 2 Arm (Graviton2) $0.0208
t3.small 2 2 x86 (Intel) $0.0252
t3a.small 2 2 x86 (AMD) $0.0252
t2.small 1 2 x86 (Intel) $0.0276

https://aws.amazon.com/jp/ec2/instance-types/

Google Cloud (Compute Engine)

マシンタイプ vCPU メモリ (GiB) アーキテクチャ 1時間あたりの料金 (USD)
e2-micro 2 1 x86 (Intel) $0.0107
e2-small 2 2 x86 (Intel) $0.0214
e2-medium 2 4 x86 (Intel) $0.0429
e2-standard-2 2 8 x86 (Intel) $0.0859
n2-standard-2 2 8 x86 (Intel) $0.1214
n2-highcpu-2 2 2 x86 (Intel) $0.0920

https://cloud.google.com/compute/vm-instance-pricing

今回の「コストパフォーマンス」の定義

本記事における「コストパフォーマンス」は、単純な料金比較だけでは測れない性能面を考慮し、以下の計算式でスコアを算出することにします。

コストパフォーマンススコア = ベンチマークスコア / 1時間あたりの料金

このスコアが高いほど、「支払う金額に対して得られる性能が高い」マシンであると評価します。

ベンチマークに使用するツール

ベンチマークツールには、Linuxで広く使われている sysbench を利用します。
CPU、メモリ、ディスクI/Oの3つの観点から性能を計測します。具体的なコマンドは以下の通りです。

sysbench 共通設定
Option Desc Default
--threads=N 使用するスレッド数 1
--events=N イベント数の上限 0
--time=N 実行時間の上限(秒) 10
--forced-shutdown=STRING --time の制限時間経過後、強制終了するまでの待機時間(秒)。'off' で無効化 off
--thread-stack-size=SIZE スレッドあたりのスタックサイズ 64K
--rate=N 平均トランザクション率。0で無制限 0
--report-interval=N 指定した間隔(秒)で中間統計を報告。0で無効化 0
--report-checkpoints=[LIST,...] 指定した時点で完全な統計をダンプし、すべてのカウンターをリセット。引数は、テスト開始からの経過時間(秒)のカンマ区切りリスト。デフォルトでは無効 -
--debug[=on|off] より詳細なデバッグ情報を出力 off
--validate[=on|off] 可能な限り検証チェックを実行 off
--help[=on|off] ヘルプを表示して終了 off
--version[=on|off] バージョンを表示して終了 off
--config-file=FILENAME コマンドラインオプションを含むファイル
--tx-rate=N --rate の非推奨エイリアス 0
--max-requests=N --events の非推奨エイリアス 0
--max-time=N --time の非推奨エイリアス 0
--num-threads=N --threads の非推奨エイリアス 1

CPU

素数計算を用いて、CPUの純粋な計算能力を測定します。--threads の値は各インスタンスのvCPU数に合わせて実行します。

実行例

sysbench cpu --cpu-max-prime=20000 --threads=<vCPU数> run
Option Desc Default
--cpu-max-prime=N 生成する素数の数 10000
実行結果例
sysbench 1.0.20 (using system LuaJIT 2.1.1700206165)

Running the test with following options:
Number of threads: 2
Initializing random number generator from current time


Prime numbers limit: 20000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:   687.91

General statistics:
    total time:                          10.0026s
    total number of events:              6882

Latency (ms):
         min:                                    2.49
         avg:                                    2.91
         max:                                    3.44
         95th percentile:                        2.97
         sum:                                20000.46

Threads fairness:
    events (avg/stddev):           3441.0000/4.00
    execution time (avg/stddev):   10.0002/0.00

メモリ

指定した合計サイズのメモリに対して、書き込み処理を連続して行い、スループットを測定します。

実行例

sysbench memory --memory-block-size=1K \
  --memory-scope=global \
  --memory-total-size=10G \
  --memory-oper=write run
Option Desc Default
--memory-block-size=SIZE メモリブロックサイズ 1K
--memory-total-size=SIZE メモリへの送信データサイズ合計 100G
--memory-scope=STRING メモリスコープ {global,local} global
--memory-oper=STRING メモリ操作種別指定 {read, write, none} write
--memory-access-mode=STRING メモリアクセスモード指定 {seq,rnd} seq
実行結果例
sysbench 1.0.20 (using system LuaJIT 2.1.1700206165)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Running memory speed test with the following options:
  block size: 1KiB
  total size: 10240MiB
  operation: write
  scope: global

Initializing worker threads...

Threads started!

Total operations: 10485760 (5476828.79 per second)

10240.00 MiB transferred (5348.47 MiB/sec)


General statistics:
    total time:                          1.9129s
    total number of events:              10485760

Latency (ms):
         min:                                    0.00
         avg:                                    0.00
         max:                                    0.13
         95th percentile:                        0.00
         sum:                                  876.94

Threads fairness:
    events (avg/stddev):           10485760.0000/0.00
    execution time (avg/stddev):   0.8769/0.00

ディスクI/O

ランダムリード/ライトの性能を測定します。事前にテスト用のファイルを作成してから実行します。

実行例

# テストファイルの作成
sysbench fileio --file-total-size=5G prepare

# ベンチマーク実行
sysbench fileio \
  --file-total-size=5G \
  --file-test-mode=rndrw \
  --time=180 \
  --max-requests=0 run
Option Desc Default
--file-num=N 作成するファイル数 128
--file-block-size=N すべてのI/O操作で使用するブロックサイズ 16384
--file-total-size=SIZE 作成するファイルの合計サイズ 2G
--file-test-mode=STRING テストモード {seqwr, seqrewr, seqrd, rndrd, rndwr, rndrw}
--file-io-mode=STRING ファイル操作モード {sync,async,mmap} sync
--file-extra-flags=[LIST,...] ファイルを開く際に使用する追加フラグのリスト {sync,dsync,direct}
--file-fsync-freq=N この数のリクエスト後に fsync() を実行(0で fsync() を使用しない) 100
--file-fsync-all[=on|off] 各書き込み操作後に fsync() を実行 off
--file-fsync-end[=on|off] テスト終了時に fsync() を実行 on
--file-fsync-mode=STRING 同期に使用するメソッド {fsync, fdatasync} fsync
--file-merged-requests=N 可能であれば、最大この数のI/Oリクエストをマージ(0でマージしない) 0
--file-rw-ratio=N 組み合わせテストでの読み取り/書き込み比率 1.5
実行結果例
sysbench 1.0.20 (using system LuaJIT 2.1.1700206165)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Extra file open flags: (none)
128 files, 8KiB each
1MiB total file size
Block size 16KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...

Threads started!


File operations:
    reads/s:                      1875.12
    writes/s:                     1250.08
    fsyncs/s:                     4005.94

Throughput:
    read, MiB/s:                  14.65
    written, MiB/s:               9.77

General statistics:
    total time:                          10.0137s
    total number of events:              71293

Latency (ms):
         min:                                    0.00
         avg:                                    0.14
         max:                                   13.79
         95th percentile:                        0.97
         sum:                                 9960.52

Threads fairness:
    events (avg/stddev):           71293.0000/0.00
    execution time (avg/stddev):   9.9605/0.00

その他留意事項

  • 5回程度試行して、平均を取ります。
  • AZは都度ランダムに選択します。
  • 試行の都度、インスタンスを作成・削除します。
    • 同じインスタンスタイプを指定しても、性能の異なるマシンで起動する可能性があるため(いわゆるインスタンスガチャ)。
  • ローカルディスクは極力条件を揃えるため、以下のディスクタイプをアタッチします。
    • AWS: gp2 (1GB/month/$0.12)
    • Google Cloud: バランス永続ディスク (1GB/month/$0.13)

評価結果

費用だけの比較: vCPU単価ランキング

まずは純粋な費用のみで比較してみます。vCPUが1つあたりの時間単価を計算し、安い順に並べてみました。

# クラウド インスタンスタイプ アーキテクチャ 1時間あたりの料金 (USD) vCPU当たりの料金(USD)
1 Google Cloud e2-micro x86 (Intel) 0.01074572 0.005
2 AWS t4g.small Arm (Graviton2) 0.0208 0.010
3 AWS t3.small x86 (Intel) 0.0252 0.013
3 AWS t3a.small x86 (AMD) 0.0252 0.013
4 AWS t2.small x86 (Intel) 0.0276 0.028
5 Google Cloud e2-small x86 (Intel) 0.0214 0.021
6 Google Cloud e2-medium x86 (Intel) 0.0429 0.021
7 Google Cloud e2-standard-2 x86 (Intel) 0.0859 0.043
8 Google Cloud n2-highcpu-2 x86 (Intel) 0.0920 0.046
9 Google Cloud n2-standard-2 x86 (Intel) 0.1214 0.060
10 Google Cloud n4-standard-2 x86 (Intel) 0.1217062 0.061

Arm ベースであるAWSの t4g.small が頭一つ抜けて安い結果となりました。
しかし、これはあくまで料金だけの比較。実際の性能はどうなのでしょうか。

CPU性能対決

計算回数 (events per second) をスコアとして採用します。

実行コマンド

sysbench cpu --cpu-max-prime=20000 --threads=`nproc --all` run
# クラウド インスタンスタイプ アーキテクチャ スコア
1 AWS t4g.small Arm (Graviton2) 2,112
2 Google Cloud n2-highcpu-2 x86 (Intel) 738
3 Google Cloud n2-standard-2 x86 (Intel) 737
4 AWS t3.small x86 (Intel) 682
5 Google Cloud e2-small x86 (Intel) 593
6 Google Cloud e2-medium x86 (Intel) 592
7 Google Cloud e2-standard-2 x86 (Intel) 588
8 AWS t3a.small x86 (AMD) 503
9 AWS t2.small x86 (Intel) 441
10 Google Cloud e2-micro x86 (Intel) 419

メモリ性能対決

メモリ書き込みのスループット (MiB/sec) をスコアとして採用します。

実行コマンド

sysbench memory \
  --memory-block-size=1K \
  --memory-scope=global \
  --memory-total-size=10G \
  --memory-oper=write run
# クラウド インスタンスタイプ アーキテクチャ スコア
1 Google Cloud n2-standard-2 x86 (Intel) 5,863
2 Google Cloud n2-highcpu-2 x86 (Intel) 5,858
3 AWS t3.small x86 (Intel) 5,352
4 Google Cloud e2-standard-2 x86 (Intel) 4,566
5 Google Cloud e2-small x86 (Intel) 4,386
6 Google Cloud e2-medium x86 (Intel) 4,385
7 AWS t3a.small x86 (AMD) 3,990
8 AWS t4g.small Arm (Graviton2) 3,905
9 Google Cloud e2-micro x86 (Intel) 545
10 AWS t2.small x86 (Intel) 503

ディスクI/O性能対決

reads/s と writes/s の結果をスコアとして採用します。

実行コマンド

# disk_read_benchmark
sysbench fileio --file-total-size=5G --file-test-mode=rndrw --time=60 --max-requests=0 run

# disk_write_benchmark
sysbench fileio --file-total-size=5G --file-test-mode=rndrw --time=60 --max-requests=0 run
# クラウド インスタンスタイプ アーキテクチャ スコア(read) スコア(write)
1 Google Cloud n2-standard-2 x86 (Intel) 48.8 32.3
2 Google Cloud n2-highcpu-2 x86 (Intel) 25.0 16.7
3 Google Cloud e2-standard-2 x86 (Intel) 20.4 13.5
4 Google Cloud e2-medium x86 (Intel) 16.2 10.4
5 Google Cloud e2-small x86 (Intel) 14.4 9.4
6 AWS t3.small x86 (Intel) 14.2 9.4
7 AWS t2.small x86 (Intel) 12.6 8.9
8 AWS t3a.small x86 (AMD) 11.9 8.6
9 AWS t4g.small Arm (Graviton2) 10.3 8.6
10 Google Cloud e2-micro x86 (Intel) 5.7 4.0

【総合結果発表】コストパフォーマンス・ランキング

スコアリング手法

各ベンチマークのコストパフォーマンス(CP)を以下の式で計算し、正規化スコアを用いて総合スコアを算出します。

各項目のコストパフォーマンス = ベンチマークスコア / 1時間あたりの料金(USD)

各項目のCP値を0-100の範囲に正規化します:

正規化スコア_i = (CP_i - 最小値) / (最大値 - 最小値) × 100

正規化した各項目のスコアを重み付き平均で統合します:

総合コストパフォーマンススコア =
正規化CPU_CP × 0.5 + 正規化Memory_CP × 0.3 + 正規化Disk_Read_CP × 0.1 + 正規化Disk_Write_CP × 0.1

今回は汎用ワークロードを想定し、以下の重み付けを採用しました:

  • CPU性能: 50%
  • メモリ性能: 30%
  • ディスクI/O(Read): 10%
  • ディスクI/O(Write): 10%

このスコアが高いほど、総合的なコストパフォーマンスが優れていると評価します。正規化により、各項目の影響度が均等化され、より公平な比較が可能になります。

各インスタンスのコストパフォーマンス詳細

生のCP値

インスタンス CPU_CP Memory_CP Disk_Read_CP Disk_Write_CP
t4g.small 101,538 187,740 495 413
e2-micro 39,159 50,935 533 374
e2-small 27,710 204,953 672 439
t3.small 27,063 212,381 563 373
t3a.small 19,960 158,333 472 341
t2.small 15,978 18,225 457 322
e2-medium 13,800 102,214 378 243
n2-highcpu-2 8,022 63,630 272 182
e2-standard-2 6,852 53,225 238 157
n2-standard-2 6,070 48,280 402 266

正規化スコア(0-100)

インスタンス 正規化CPU_CP 正規化Memory_CP 正規化Disk_Read_CP 正規化Disk_Write_CP
t4g.small 100.00 87.25 59.22 90.78
e2-micro 34.66 16.85 67.97 76.95
e2-small 22.66 96.20 100.00 100.00
t3.small 22.00 100.00 74.88 76.60
t3a.small 14.56 72.19 53.92 65.25
t2.small 10.38 0.00 50.46 58.51
e2-medium 8.09 43.26 32.26 30.50
n2-highcpu-2 2.05 23.40 7.83 8.87
e2-standard-2 0.82 18.02 0.00 0.00
n2-standard-2 0.00 15.48 37.79 38.65

総合ランキング

順位 クラウド インスタンスタイプ アーキテクチャ 総合スコア
🥇 1位 AWS t4g.small Arm (Graviton2) 91.18
🥈 2位 Google Cloud e2-small x86 (Intel) 60.19
🥉 3位 AWS t3.small x86 (Intel) 56.15
4位 AWS t3a.small x86 (AMD) 40.86
5位 Google Cloud e2-micro x86 (Intel) 37.69
6位 Google Cloud e2-medium x86 (Intel) 23.31
7位 AWS t2.small x86 (Intel) 16.09
8位 Google Cloud n2-standard-2 x86 (Intel) 12.29
9位 Google Cloud n2-highcpu-2 x86 (Intel) 9.72
10位 Google Cloud e2-standard-2 x86 (Intel) 5.82

まとめ

今回の評価により、ArmベースのGraviton2インスタンス(t4g.small)が、(今回の前提においては)最も優れたコストパフォーマンスを発揮することを確認しました。今後は積極的に Arm化 していきましょう。
また全体的に Google Cloud よりも AWS の方がコスパが良いという結果になりました。単価は若干高いが vCPU 当たりのパフォーマンスは AWS よりも若干良いのかなと想像していたので、この結果は個人的に意外でした。また Google Cloud は Arm タイプのマシンがあまりないので、こちらも今後のリリースに期待していきたいなと思いました。

一方、Google Cloud はスポットVMという低価格で利用できるVMオプションもあるので、使い方によってはかなりコスパがよくなるケースもあります。

今回はスコープを絞って簡単に評価してみましたが、正しい結論を出すにはまだまだが浅く、もう少し掘り下げていくべきかなと考えています。

  • より上位のインスタンスタイプを評価
  • sysbench におけるテストパターン見直し
  • sysbench 以外のベンチマークツールの採用
  • スコアリング手法の見直し
  • Fargate などのサーバレスインスタンスのコストパフォーマンス評価
  • RDB インスタンスの評価

中でも、サーバレスインスタンスの評価は「開発環境にサーバレスインスタンスを利用することで、パフォーマンスを保ちつつコスト削減したい」のようなニーズを満たすのかを検証確認できるのではないかと思います。

結局「ワークロードによる」という世界かなとは思いますが、クラウドを利用する上では常にコスパ最適なインスタンスを選択したいところです。

Discussion