この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

Aurora PostgreSQL（db.r6g.xlarge、リザーブド1年前払い）の前月請求を見たら、IO課金が総額の86%を占めてた。「IOが請求の25%を超えたらI/O-Optimizedを検討すべき」という目安をよく見るけど、うちはその倍以上いってる。

前月の請求内訳

内訳はこんな感じ（例）。

• 総費用: $3,500
  • IO料金: $3,000
  • バックアップ料金: $500
• リザーブドインスタンスのランニングコスト: 月換算で$460前後

IO料金だけで総額の85.7%。25%基準からすると完全にオーバー。

AWSの公式アナウンス（2023年5月11日、GA）でも「IO課金がAurora総額の25%を超える場合、I/O-Optimizedで最大40%のコスト削減が見込める」という基準が示されている。うちの数字はこの目安からもかなり分かりやすく該当するケースなので、素直に移行を検討していいと判断した。

IO比率が25%を超えてるかは、Cost Explorerで Usage Type ごとにグルーピングして RDS:StorageIOUsage の割合を見れば一発で分かる。うちみたいに90%近いなら、迷わず検討していいと思う。

Standardとの料金構成の違い

Aurora I/O-Optimizedは2023年5月11日にGAした構成。それより前に構築したAurora環境だと、Standardのまま気づかず運用してるケースもありそうだなと思った。

料金構成としてはこう変わる。

• Standard: リクエスト数に応じてIO課金が発生する
• I/O-Optimized: IO課金がゼロになる代わりに、ストレージ料金が$0.10→$0.225/GB-月（約2.25倍）、インスタンス料金が25〜30%程度上がる

インスタンス料金の増加幅は資料によって多少表記が違う（25%〜30%）ので、このあたりはリージョンや時期でも変わりうる前提で、最終的には料金ページで確認したほうがいい。IO課金がゼロになる効果と、ストレージ・インスタンス側の増加分を天秤にかけたときに、どのラインで得になるかという話になる。

切り替え自体はクラスタ単位のモディファイで、データ移行は不要。Management ConsoleかCLIから切り替えられて、NVMeベースでないインスタンスならダウンタイムも発生しない、とAWS側の説明にある。

リザーブドインスタンスの注意点

I/O-Optimizedに切り替えるとインスタンス料金自体が変わるので、既存のRIがそのまま適用されない部分が出てくる。AWSのドキュメントには「既存RIと同程度の追加RIを30%分購入する」ような案内があった。乗り換えのタイミングでRIを組み直すかどうかも検討事項になりそう。

コスト以外の効果

「I/O最適化」という名前の通り、コスト面だけじゃなくパフォーマンス面の効果もあるらしい。

AWS側の説明では、I/O処理を小さく・より頻繁なバッチで行うことでレイテンシが減り、スループットが上がるとされている。IOリクエスト数に応じた課金がなくなること自体は料金の話だけど、その裏でI/Oの処理方式そのものが変わっているのがポイントっぽい。

恩恵が出やすそうなワークロードとしてはこのあたり。

• 分析系ワークロード（データ処理が集中する）
• 高トランザクションなOLTPアプリケーション
• 継続的に大量IOが発生するETLプロセスなど

うちのケースはOLTP寄りで、しかもIO比率がもともと高い状態だったので、コストとパフォーマンス両方の効果が期待できそうという判断材料になった。ただしここは実機での比較検証はしてない。あくまでAWS公式の説明ベースの話として書いてる。実際に切り替えた後、レイテンシやスループットがどう変化したかは別途確認する予定。