Aurora I/O 料金の見積もり方｜実測で出す手順

本記事にはプロモーション（広告）が含まれています。

オンプレミスのデータベースをAurora PostgreSQLに移行するとき、インスタンス料金とストレージ料金はスペックが決まれば計算できます。困るのはAurora Standardの「I/Oリクエスト」料金です。移行前の段階で数字が出せず、見積もり作業がそこで止まります。

Auroraのi/O料金は、既存環境のIOPS統計から換算できません。検証環境で代表的なワークロードを流し、CloudWatchメトリクスを実測する必要があります。なぜ換算が成立しないのか、どのメトリクスをどの統計で取るのか、月額に落とし込む計算式、そしてAurora I/O-Optimizedに切り替えるべきかの判断基準までを順に整理します。

結論：Aurora の I/O 料金は「換算」ではなく検証環境の実測から出す

Aurora Standardの料金は「インスタンス時間」「ストレージ容量」「I/Oリクエスト」の3つで構成されます。前の2つはサイジングが決まれば机上で計算できますが、I/Oリクエストはワークロード依存です。しかもAuroraのI/Oリクエストは、SQLの発行本数でも取得行数でもありません。Auroraのストレージレイヤーに対して実際に発生したI/Oオペレーションの数を数えます。

ここを押さえずに「既存システムのディスクIOPSが平均2,000だから、Auroraでも2,000 IOPS相当だろう」と計算すると、桁が合わないことがあります。多すぎれば過剰な見積もりで稟議が通らず、少なすぎれば本番稼働後に請求書を見て慌てます。

見積もりに必要なのは2つの数字だけ

必要なメトリクスは2つです。クラスターボリュームからの読み取りI/O数を示すVolumeReadIOPsと、書き込みI/O数を示すVolumeWriteIOPsです。

どちらもDBインスタンスではなくクラスターレベルのメトリクスで、ディメンションはDBClusterIdentifierです。Auroraはストレージをクラスター内で共有するため、I/O課金もクラスターボリューム単位で発生します。この2つを月間合計に換算し、公式料金ページのI/O単価（100万リクエストあたりの価格）を掛ければ月額が出ます。

見積もり作業の実体は「この2つの数字を、本番に近いワークロードでどう取るか」という段取りの問題です。計算式そのものは難しくありません。

オンプレミスの IOPS 統計から換算してはいけない理由

既存環境でiostatやOracleのV$SYSSTAT、PostgreSQLのpg_stat_databaseから取ったI/O統計をAuroraのI/Oリクエスト数へ換算したくなりますが、成立しません。ストレージアーキテクチャが根本的に違います。

オンプレミスの一般的な構成では、DBプロセスがデータファイルへブロック単位の読み書きを行い、その手前にOSのページキャッシュとストレージ側のキャッシュが挟まります。チェックポイントのたびにダーティバッファがデータファイルへ書き戻され、同じブロックが何度も書かれます。計測したIOPSにOSキャッシュで吸収された分やストレージ側で結合された分がどう反映されるかも、環境によって異なります。

一方のAuroraはコンピュートとストレージが分離され、DBインスタンスはデータページの書き戻しをしません。永続化のためにストレージレイヤーへ送るのはredoログだけで、ページの再構成はストレージノード側が担います。「チェックポイントでまとめてデータファイルに書く」というI/Oパターンが存在しないわけです。読み取り側も、DBインスタンスのバッファキャッシュでヒットすればストレージには問い合わせが飛びません。

この違いは、RDS・Aurora 運用・トラブル解決ガイドでも触れているストレージ分離の設計から来ています。同じSQLを流してもストレージレイヤーに届くI/Oの形が変わるため、既存のIOPS値に係数を掛けてAuroraの請求額を当てる発想そのものに無理があります。

Aurora の「I/O リクエスト」は何をカウントしているのか

カウントの仕組みを理解しておかないと、実測した数字が妥当かどうかも判断できません。読み取りと書き込みで単位が違う点が最初の関門です。

読み取り：ストレージから読んだ 8KB ページが1リクエスト

読み取りI/Oは、クラスターボリュームから読み出したデータベースページ1ページ（8KB）が1読み取りI/Oリクエストです。Aurora PostgreSQLのデータページサイズは8KBなので、「ストレージから1ページ読んだら1リクエスト」と覚えればよい。

ここから導かれる実務的な示唆は2つあります。

ひとつは、1本のSQLが何リクエストになるかは実行計画で決まる点です。主キー検索でインデックスを3段たどってヒープを1ページ読むなら数リクエストで済みますが、同じテーブルへのSeq Scanはテーブルのページ数ぶんだけ読み取りが発生し得ます。統計情報が古くてプランがIndex ScanからSeq Scanへ切り替わった時点でI/Oコストが急増する、という事故はこの構造から起こります。

もうひとつは、取得行数とI/O数が比例しないことです。1ページに数十から数百行が格納されるので、同じ1万行を返すクエリでも、行が物理的に固まっているか散らばっているかで読み取りページ数が大きく変わります。相関が低いテーブルへの範囲検索は、行数のわりにページ数が膨らみます。

書き込み：redo ログを 4KB 単位でカウントする

書き込みI/Oは単位が違います。書き込みを永続化するためにトランザクションログ（redo）をストレージレイヤーへ送るときに発生し、4KB単位でカウントされます。Aurora PostgreSQLのデータページは8KBですが、書き込みはページ単位ではありません。

ここがAuroraの書き込みI/O見積もりで最も誤解されやすい部分です。「10ページ更新したから書き込みI/Oは10」ではなく、「その更新で生成されたredoレコードの総量を4KB単位で区切った数」になります。書き込みI/O量を左右するのは更新したページ数ではなく、redoの生成量とその送出のまとまり方です。

運用上の判断材料としては次のように考えます。

1行ずつCOMMITするループ処理は、トランザクションごとにログの送出が発生するため、バルクでまとめた場合よりも4KB単位の切れ端が増えやすい
更新対象カラムが広い（TOASTを伴う、インデックスが多数ある）テーブルのUPDATEは、1行の更新でもredo量が膨らむ
PostgreSQLのMVCCではUPDATEが新しい行バージョンの追記として実装されるため、更新の多いテーブルではインデックスエントリの追加ぶんまでredoに乗る

なお、Auroraはコミュニティ版PostgreSQLのようにローカルディスクへWALを書いてからチェックポイントでデータファイルを書く、という二重の書き込みをしません。データページの書き戻しが課金対象のI/Oとして現れないのは、この設計のためです。

バッファキャッシュにヒットした読み取りは課金対象にならない

読み取り対象のページがDBインスタンスのバッファキャッシュ（Aurora PostgreSQLではshared_buffers）に存在する場合、ストレージからの読み取りは発生せず、I/Oリクエストとしてカウントされません。

これは見積もりで大きな意味を持ちます。同じワークロードを流しても、インスタンスクラスを変えてメモリ量が変わるだけで読み取りI/Oリクエスト数が動き、請求額も変わります。

Aurora PostgreSQLのshared_buffersは、デフォルトでインスタンスクラスのメモリに連動した値（DBInstanceClassMemoryを元にした式）が設定されます。インスタンスクラスを1段上げればキャッシュできるページ数も増え、「インスタンス料金は上がるがI/O料金は下がる」というトレードオフが生まれます。検証環境のインスタンスクラスを本番想定と揃えておかないと、読み取りI/Oの実測値は意味をなしません。

逆に、ワーキングセットがメモリに収まっているシステムでは、読み取りI/Oが想像よりずっと小さい値になることもあります。これも「オンプレのIOPSからの換算」が外れる典型的な理由です。

レプリカ・バックアップ・Aurora Serverless で数え方は変わるのか

リーダーインスタンス（Auroraレプリカ）を追加した場合、ライターと同じクラスターボリュームを参照しますが、バッファキャッシュはインスタンスごとに独立しています。レプリカ上で実行した参照クエリがそのインスタンスのキャッシュにヒットしなければ、ストレージからの読み取りが発生します。読み取りをレプリカへ振り分けるとライター側のI/Oは減りますが、クラスター全体の読み取りI/Oが自動的に減るわけではありません。レプリカ構成特有の挙動はAuroraレプリカラグ監視｜AuroraReplicaLagも合わせて確認してください。

バックアップ、スナップショット、バックトラック、Global Databaseのリージョン間レプリケーションなどは、I/Oリクエストとは別の課金項目として整理されているものがあります。Aurora Serverless v2ではACU（キャパシティ）ベースの課金が加わります。構成によって課金の内訳が変わるため、自分の構成でどの項目が立つのかは公式の料金ページと料金計算ツールで突き合わせてください。この記事で扱うのは、Aurora Standardにおける「I/Oリクエスト」項目の見積もり方です。

見積もりでつまずく「よくある誤解」3つ

実測に入る前に、見積もりレビューで指摘されがちな誤解を3つ解消しておきます。

誤解1：SQL の実行回数や取得行数から I/O リクエスト数を出せる

「1日あたりのトランザクション件数が分かっているので、そこからI/Oを出せるはず」という発想は自然ですが、1つのSQLが複数ページを読むこともあり、バッファキャッシュにヒットしてI/Oが1件も発生しないこともあります。実行回数から一意には決まりません。

さらに読み取りは実行計画に依存します。同じSQLでも、統計情報・パラメータ値・インデックスの有無でIndex ScanとSeq Scanが切り替わり、読み取りページ数が桁で変わります。「アプリの仕様書からトランザクション数を拾って掛け算する」方式は、偶然の一致を期待しているだけです。

誤解2：オンプレミスの IOPS をそのまま置き換えればよい

既存環境のIOPS値には、OSページキャッシュで吸収された分、ストレージ装置が結合・先読みした分、チェックポイントによるデータファイル書き戻しなどが混ざります。Auroraは共有ストレージとログ構造化された書き込みを前提にしており、データページの書き戻しI/Oが課金対象として現れません。書き込みは4KB単位のredoでカウントされ、読み取りは8KBページ単位です。

単位も発生契機も違うものを係数で結ぶことはできません。既存のIOPS統計は「読み取り主体か書き込み主体か」「ピークはいつか」といったワークロードの性格を知るために使い、金額の算出根拠にはしないのが正しい使い方です。

誤解3：I/O-Optimized にすれば必ず安くなる

Aurora I/O-Optimizedはストレージ構成の選択肢で、I/Oリクエストの課金がなくなる代わりにインスタンス料金とストレージ料金が上乗せされます。I/O量が多いワークロードでは総額が下がる場合がありますが、I/Oが少なければ上乗せぶんだけ高くなります。

どちらが安いかはワークロードのI/Oパターンに依存するため、「I/O課金が怖いからI/O-Optimizedにしておく」という判断は見積もりの放棄です。StandardでのI/Oリクエスト数を実測しないと比較もできません。

CloudWatch で月間 I/O リクエスト数を実測する手順

段取りは「検証環境を本番想定の構成で作る → 代表ワークロードを流す → メトリクスを取る → 月間に伸ばす」の4段階です。

検証環境を作る際のポイントは2点あります。

インスタンスクラスを本番想定と揃える（バッファキャッシュサイズが変わると読み取りI/Oが変わるため）
データ量を本番に近づける（テーブルが小さいと全部キャッシュに乗り、読み取りI/Oがほぼゼロになる）

テストデータが本番の10分の1しかない検証環境で測った読み取りI/Oは役に立ちません。少なくともワーキングセットとバッファキャッシュの大小関係を本番と同じに寄せます。

VolumeReadIOPs / VolumeWriteIOPs を正しい統計で取得する

マネジメントコンソールのCloudWatchでグラフを見るのが手軽ですが、見積もり計算に使うならCLIで数値を落とすほうが確実です。

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name VolumeReadIOPs \
  --dimensions Name=DBClusterIdentifier,Value=<クラスター識別子> \
  --start-time 2026-09-01T00:00:00Z \
  --end-time 2026-10-01T00:00:00Z \
  --period 3600 \
  --statistics Average Maximum Sum \
  --output table

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name VolumeWriteIOPs \
  --dimensions Name=DBClusterIdentifier,Value=<クラスター識別子> \
  --start-time 2026-09-01T00:00:00Z \
  --end-time 2026-10-01T00:00:00Z \
  --period 3600 \
  --statistics Average Maximum Sum \
  --output table

落とし穴は単位です。VolumeReadIOPs／VolumeWriteIOPsの値が「1秒あたりのI/O数」なのか「報告間隔あたりの合計数」なのかを確認してください。AuroraのVolume系メトリクスは一定間隔でまとめて報告される仕様で、取得したAverageが秒単位か間隔単位かを間違えると月額の計算結果が二桁以上ずれます。

対処は2つです。使うメトリクスの単位と報告間隔を公式ドキュメント（Amazon AuroraのCloudWatchメトリクス一覧）で確認し、別の情報源でクロスチェックします。

クロスチェックには、Cost Explorerや請求の使用量レポートで該当期間のI/Oリクエスト使用量を確認する方法が確実です。検証環境を数日動かし、実請求上のI/Oリクエスト数とCloudWatchから計算した推計値を突き合わせれば、単位の解釈が正しいかどうかが分かります。一度やっておけば、以降の見積もりはCloudWatchベースで回せます。

BufferCacheHitRatio で読み取り I/O の妥当性を確認する

読み取りI/Oの実測値が妥当かどうかは、BufferCacheHitRatio（バッファキャッシュヒット率）と合わせて見ます。ヒット率が高ければストレージへの読み取りI/Oは少なく、低ければ増えます。ヒット率が高いのに読み取りI/Oが多いなど整合しない場合は、測定期間の取り方やワークロードの流し方を疑ってください。

PostgreSQL側からも同じ観点で裏を取れます。

SELECT datname,
       blks_read,
       blks_hit,
       round(blks_hit * 100.0 / nullif(blks_read + blks_hit, 0), 2) AS hit_ratio
  FROM pg_stat_database
 WHERE datname = '<データベース名>';

blks_readは共有バッファで見つからずに読み出されたブロック数、blks_hitはバッファ内で見つかったブロック数です。ワークロード実行の前後でpg_stat_reset()を挟んで差分を取れば、そのワークロードがどれだけバッファミスを起こしたか分かります。Auroraのストレージ読み取りI/Oと一致する保証はありませんが、「読み取りI/Oの主因となっているデータベースやクエリはどれか」を特定する目安には十分使えます。

pg_stat_statementsを有効にしておけば、shared_blks_readの大きいクエリを上位から並べて、I/Oリクエストを消費しているSQLを特定できます。見積もりと同時にチューニング候補が洗い出せるので、検証フェーズでは入れておきたい拡張です。

1秒あたりの値から月間リクエスト数と月額を計算する

単位の確認が済んだら月間に伸ばします。メトリクスが「1秒あたりのI/O数」である場合の計算は次のとおりです。

月間読み取りリクエスト数 = VolumeReadIOPs の平均値 × 86,400 × 30
月間書き込みリクエスト数 = VolumeWriteIOPs の平均値 × 86,400 × 30
月間 I/O リクエスト数   = 上記2つの合計

月額 I/O 料金 = (月間 I/O リクエスト数 ÷ 1,000,000) × 100万リクエストあたりの単価

単価はリージョンによって異なり改定もあるため、Auroraの料金ページまたはAWS Pricing Calculatorで最新値を確認してください。単価を調べる前に、「月間リクエスト数」という自分の環境固有の数字を確定させておきます。この数字がなければ料金計算ツールのI/O欄は埋められません。

メトリクスが報告間隔あたりの合計値であれば、期間内のデータポイントの合計を取って月間へスケールします。どちらの解釈で計算したのかを見積もり資料に明記しておけば、レビュー時の指摘にも答えられます。

ピーク時間帯とバッチ処理を見積もりに織り込む

平均値だけで計算すると過小見積もりになります。業務システムのI/Oは時間帯で大きく偏るからです。日中のオンライン処理は参照主体でキャッシュヒット率が高く、夜間バッチでは全件スキャンや大量のUPDATE／INSERTが走って読み取りと書き込みの両方が急増します。月末・年度末処理は回数こそ少ないものの、1回のI/O量が突出します。

見積もりは次のように積み上げます。

時間単位（--period 3600）でメトリクスを取り、24時間分のプロファイルを作る
「平日日中」「夜間バッチ」「休日」など、パターンごとのI/O量を分けて集計する
月末処理や四半期処理のような低頻度・高負荷のジョブは、1回あたりのI/O量を別途測って回数を掛ける
それらを合計して月間値とし、将来のデータ増加・ユーザー増加に対する余裕を乗せる

手順3を忘れると、稼働初月は想定どおりでも月末締め処理で請求が跳ね上がり、「見積もりが外れた」という話になります。バッチのI/Oは時間帯が特定できるぶん、測るのも抑えるのも比較的やりやすい領域です。

この記事のテーマをさらに学べる本

EC2・IAM・RDSなどの運用やバックアップを体系的に扱い、Aurora運用の土台を固められます。

AWS運用入門佐竹陽一/山崎翔平/小倉大/峯侑資

楽天ブックスで詳しく見る Yahoo!ショッピングで見る

I/O コストを下げる打ち手と、Standard / I/O-Optimized の選び分け

実測値が出たら、次は「このI/Oは減らせないのか」を検討します。順番が大事で、まずI/O自体を減らし、それでも多いならI/O-Optimizedを検討します。課金方式を切り替える前に無駄なI/Oを減らしたほうが、インスタンスサイズもストレージも含めて全体が軽くなります。

まずアプリ側・SQL 側で I/O を減らせないか確認する

読み取りI/Oを増やす典型的な原因は、不要なページを読んでいることです。確認する順番は次のとおりです。

EXPLAIN (ANALYZE, BUFFERS)で実際に読んだブロック数を見る。shared readが大きいノードがI/Oリクエストの発生源です。Buffers: shared hit=... read=...のreadが課金対象に近い部分だと考えると、改善の効果を金額で捉えやすくなります
Seq Scanが意図したものか確認する。件数の少ない検索でSeq Scanが選ばれているなら、インデックス不足か統計情報の鮮度、あるいは推定行数のずれを疑います
オーバーフェッチをやめる。SELECT *でアプリ側が捨てている列があるなら、必要列だけにすることでTOASTの読み取りが消えることもあります。カバリングインデックス（Index Only Scan）に持ち込めれば、ヒープへのアクセスを丸ごと削れます
テーブル・インデックスの肥大化（bloat）を確認する。デッドタプルで膨らんだテーブルは、同じ行数を読むために余計なページを読みます。autovacuumが追いついていないテーブルは、I/Oコストと性能の両方で損をします

書き込みI/O側はredo生成量で決まります。1行ずつコミットするループをbulk化する、同じ行を何度もUPDATEしている処理を1回にまとめる、更新不要なカラムを含むUPDATE文を見直す、不要なインデックスを削除する（インデックスが多いほど更新時のredoが増える）。このあたりが定番の打ち手です。

メモリとバッファキャッシュを見直して読み取り I/O を削る

読み取りI/Oはバッファキャッシュにヒットすればカウントされないので、メモリを増やすことが読み取りI/Oの削減に直結します。インスタンスクラスを1段上げるとshared_buffersも連動して増えるため、「インスタンス料金の増加分 < I/O料金の削減分」であれば、スケールアップのほうが総額で得になります。実測ベースで両方を計算して比較してください。

ただし注意点があります。フェイルオーバーやインスタンスクラス変更でインスタンスが入れ替わると、新しいインスタンスのバッファキャッシュは空の状態から始まります。直後は読み取りI/Oが一時的に急増し、レスポンスも悪化します。Aurora PostgreSQLにはCluster Cache Managementでリーダー側のキャッシュを温めておく機能があり、インスタンスクラス変更の手順と併せて検討する価値があります。詳しくはAurora インスタンスクラス変更のダウンタイム最小化手順にまとめています。

I/O-Optimized に切り替える損益分岐の考え方

アプリ側・メモリ側の打ち手を打ったうえで、それでもI/O料金が重いならI/O-Optimizedを検討します。判断は次の比較で行います。

【Standard】
  インスタンス料金 + ストレージ料金 + I/O リクエスト料金

【I/O-Optimized】
  インスタンス料金(上乗せあり) + ストレージ料金(上乗せあり) + I/O リクエスト料金なし

実測した月間I/Oリクエスト数をもとに両方の月額を計算し、安いほうを選びます。傾向としては、月額総額に対してI/O料金の割合が大きいI/O集約型のワークロードではI/O-Optimizedが有利で、I/Oが少なくインスタンス費用が支配的ならStandardが有利です。具体的な分岐点は単価設定とインスタンス構成で変わるので、最新の料金で計算してください。

金額以外の判断軸として「コストの予測可能性」もあります。I/O-OptimizedはI/O量の変動が請求額に影響しないため、月額が読みやすくなります。SQLの実行計画が変わっただけでコストが急増するリスクを嫌う運用方針であれば、多少の割高を許容してI/O-Optimizedを選ぶのも合理的です。

本番稼働後に I/O コストが跳ねないための監視設計

I/Oリクエスト数はワークロードの変化やデータ量の増加で動きます。見積もりは一度やって終わりではなく、稼働後も継続して追ってください。

継続的に見るメトリクスとアラームのしきい値

最低限、次の3つは常時監視に入れます。

メトリクス	見る目的
VolumeReadIOPs	読み取り I/O の傾向。急増は実行計画の変化やキャッシュミスの増加を示す
VolumeWriteIOPs	書き込み I/O の傾向。急増はバッチ変更や更新量の増加を示す
BufferCacheHitRatio	読み取り I/O の背景説明。低下は読み取り I/O 増加の先行指標になる

しきい値は自環境で実測したベースラインから決めます。稼働後1〜2か月のデータで平日日中・夜間バッチそれぞれの通常レンジを押さえ、そこから明確に外れたら気づける水準に置きます。CloudWatchのAnomaly Detectionで曜日・時間帯のパターンを学習させる方法も相性が良い領域です。

注意したいのは、夜間バッチでI/Oが急増するのは正常動作だという点です。平均値にしきい値を引くと、バッチ時間帯に毎晩アラームが鳴って誰も見なくなります。時間帯でアラームを使い分けたい場合は、CloudWatch アラームを時間帯で抑制する手順の方法が使えます。

金額側の監視としては、AWS Budgetsでサービス別の予算アラートを設定し、Cost ExplorerでI/Oリクエストの使用量推移を月次で確認します。メトリクスの異常と請求額の変化を両面から捕まえられます。

キャッシュヒット率が下がったときに疑う順番

BufferCacheHitRatioの低下は、読み取りI/Oの増加とレスポンス劣化の両方に直結します。下がったときは次の順番で切り分けます。

インスタンスの再起動・フェイルオーバー・クラス変更がなかったか。キャッシュが空になっただけなら時間とともに回復します。イベント履歴を確認します
ワークロードが変わっていないか。新しいバッチ、新機能のリリース、レポート系クエリの追加など。pg_stat_statementsでshared_blks_readの上位クエリを前回計測時と比較し、顔ぶれが変わっていないか見ます
データ量が増えてワーキングセットがメモリに収まらなくなっていないか。テーブルサイズの推移を追います。メモリ不足が原因なら、スケールアップかデータのアーカイブ（パーティション化と古いパーティションの退避）を検討します
実行計画が変わっていないか。統計情報の鮮度、データ分布の偏り、パラメータ変更。Index ScanがSeq Scanに切り替わっていれば、読んでいるページ数が跳ね上がります
肥大化していないか。デッドタプルが増えると有効な行あたりのページ数が増え、キャッシュ効率が落ちます。autovacuumの実行状況をpg_stat_user_tablesのlast_autovacuum／n_dead_tupで確認します

この順番は「外部要因（再起動）→ ワークロード変化 → データ増加 → プラン変化 → 内部の肥大化」という、確認コストの低い順です。Performance Insightsを有効にしていれば、同時期の待機イベント（IO:DataFileReadなど）の増減と突き合わせることで、ステップ2〜4の切り分けが速くなります。

この記事のテーマをさらに学べる本

SAA-C03対応で「コストを最適化したアーキテクチャ設計」まで扱うため、見積もりの前提知識を補えます。

AWS認定資格試験テキスト　AWS認定ソリューションアーキテクト - アソシエイト　改訂第3版佐々木拓郎

楽天ブックスで詳しく見る Yahoo!ショッピングで見る

よくある質問

Aurora の I/O リクエスト数は CloudWatch のどのメトリクスで確認できる？

AWS/RDSネームスペースのVolumeReadIOPs（読み取り）とVolumeWriteIOPs（書き込み）です。ディメンションはDBClusterIdentifierで、DBインスタンス単位ではなくクラスター単位のメトリクスです。両者の合計が課金対象のI/Oリクエスト数に対応します。値の単位と報告間隔は公式ドキュメントで確認し、請求の使用量データと一度突き合わせておくことをおすすめします。

SELECT しか実行していないのに書き込み I/O が発生するのはなぜ？

参照系の処理でも、データベースの内部動作で更新が発生します。PostgreSQLではSELECTの実行時にヒントビット（行の可視性情報）が更新されたり、VACUUMやautovacuumがデッドタプルの回収やフリーズ処理を行ったり、一時ファイルの書き出しやシステムカタログ・統計情報の更新が走ったりします。いずれもredoを生成するため、書き込みI/Oとしてカウントされます。

アプリケーションが読み取り専用でも、バックグラウンドのメンテナンス処理ぶんの書き込みI/Oはゼロになりません。見積もりでは「参照系システムだから書き込みI/Oは0」とせず、実測値を使ってください。

Aurora Standard から I/O-Optimized へは後から変更できる？

ストレージ構成の切り替えはクラスターの設定変更として実施できます。ただし、変更の可否・前提条件（エンジンバージョンなど）、切り替え後に再度変更する際の制約、課金が切り替わるタイミングには仕様が定められています。作業前に公式ドキュメントで現時点の条件を確認してください。実務上は、まずStandardで数か月運用して実測値を蓄積し、その数字で両方の月額を比較してから切り替えを判断する進め方が無理のない手順です。

移行前に検証環境を用意できない場合はどう見積もる？

本来は検証環境での実測が最も確実ですが、どうしても用意できない場合は次のように進めます。

既存環境の統計から「性格」を押さえる。読み取り主体か書き込み主体か、ピークの時間帯、バッチの有無。金額の根拠ではなくプロファイル把握に使います
小規模でもAuroraクラスターを立てて、代表的なクエリを数本流す。本番フルスケールでなくても、「主要クエリ1回あたりの読み取りページ数」や「主要な更新処理1件あたりの書き込みI/O」が分かれば、実行回数を掛けて概算できます。EXPLAIN (ANALYZE, BUFFERS)のブロック数も手がかりになります
幅を持った見積もりとして提示する。単一の数値ではなく「最小ケース／想定ケース／最大ケース」のレンジで出し、前提条件を明記します
移行後に早期で再計測する前提を合意しておく。稼働後1か月の実測で見直すこと、I/O-Optimizedへの切り替え判断をそのタイミングで行うことを、あらかじめスケジュールに入れます

見積もりの不確実性を隠さず、「どの前提が変われば金額が変わるのか」を明示するほうが、後々のトラブルを避けられます。

まとめ：見積もりの精度は「実測できる環境を作れるか」で決まる

AuroraのI/O料金の見積もりは、計算式が難しいわけではありません。難しいのは、式に入れる「月間I/Oリクエスト数」を信頼できる形で手に入れる段取りです。

AuroraのI/Oリクエストは、読み取りがストレージから読んだ8KBページ1枚で1リクエスト、書き込みはredoを4KB単位でカウントする。SQLの本数や行数とは無関係
バッファキャッシュにヒットした読み取りは課金されないため、インスタンスのメモリ量が請求額に直接影響する
オンプレミスのIOPS統計はストレージアーキテクチャが違うため換算できない。ワークロードの性格を知るためだけに使う
見積もりはVolumeReadIOPs／VolumeWriteIOPsの実測から出す。メトリクスの単位と報告間隔は公式ドキュメントで確認し、請求の使用量データでクロスチェックする
平均値だけでなく、夜間バッチ・月末処理などのピークを分けて積み上げる
I/O-Optimizedは「I/O課金なし、インスタンスとストレージが上乗せ」という構成。実測値で両方の月額を計算して比較する。先にSQLとメモリでI/O自体を削るほうが効果が大きい
稼働後もVolumeReadIOPs／VolumeWriteIOPs／BufferCacheHitRatioを追い、ベースラインから外れたら切り分ける

移行プロジェクトの計画段階で、本番相当のデータ量とインスタンスクラスを持つ検証環境を押さえられるかどうかが、そのまま見積もり精度に反映されます。環境確保の調整こそ見積もり作業の本体だと考えて、早めに動くのが得策です。

なお、Auroraのメトリクス仕様、ストレージ構成の選択肢、料金体系はいずれも更新されることがあります。実際に見積もりや構成変更を行う際は、AWSの公式ドキュメントと料金ページで最新の内容を確認してください。

結論：Aurora の I/O 料金は「換算」ではなく検証環境の実測から出す

見積もりに必要なのは2つの数字だけ

オンプレミスの IOPS 統計から換算してはいけない理由

Aurora の「I/O リクエスト」は何をカウントしているのか

読み取り：ストレージから読んだ 8KB ページが1リクエスト

書き込み：redo ログを 4KB 単位でカウントする

バッファキャッシュにヒットした読み取りは課金対象にならない

レプリカ・バックアップ・Aurora Serverless で数え方は変わるのか

見積もりでつまずく「よくある誤解」3つ

誤解1：SQL の実行回数や取得行数から I/O リクエスト数を出せる

誤解2：オンプレミスの IOPS をそのまま置き換えればよい

誤解3：I/O-Optimized にすれば必ず安くなる

CloudWatch で月間 I/O リクエスト数を実測する手順

VolumeReadIOPs / VolumeWriteIOPs を正しい統計で取得する

BufferCacheHitRatio で読み取り I/O の妥当性を確認する

1秒あたりの値から月間リクエスト数と月額を計算する

ピーク時間帯とバッチ処理を見積もりに織り込む

I/O コストを下げる打ち手と、Standard / I/O-Optimized の選び分け

まずアプリ側・SQL 側で I/O を減らせないか確認する

メモリとバッファキャッシュを見直して読み取り I/O を削る

I/O-Optimized に切り替える損益分岐の考え方

本番稼働後に I/O コストが跳ねないための監視設計

継続的に見るメトリクスとアラームのしきい値

キャッシュヒット率が下がったときに疑う順番

よくある質問

Aurora の I/O リクエスト数は CloudWatch のどのメトリクスで確認できる？

SELECT しか実行していないのに書き込み I/O が発生するのはなぜ？

Aurora Standard から I/O-Optimized へは後から変更できる？

移行前に検証環境を用意できない場合はどう見積もる？

まとめ：見積もりの精度は「実測できる環境を作れるか」で決まる

関連記事