Amazon EFSで読み取りコストが増加したので、CloudWatchメトリクスで原因調査してみた

おつまみ
2025.01.27
こんにちは！AWS事業本部のおつまみです。
みなさん、Amazon EFSの料金が急激に増加した経験はありますか？私はあります。
先日あるアカウントで、1日だけAmazon EFSの料金が増加していることに気づきました。
その際にCloudWatchメトリクスで原因調査をしたので、その方法を共有します！
 いきなり結論Elastic Throughput モードの使用により、読み取りコストが予想以上に増加する可能性がある
CloudWatchメトリクスを活用して、異常な読み取りIOのスパイクを特定することが重要
コスト削減のためには、スループットモードの見直しやクライアント側のファイル操作の最適化が有効
 前提：Amazon EFSの基礎知識まず前提として、Amazon EFSの基礎知識として料金体系とスループットモードについて簡潔に説明します。
 料金体系Amazon EFSの料金は、主に2つの要素で決まります。
ストレージ使用量
データを保存する量に応じて料金が発生
よく使うデータには「標準ストレージクラス (Standard)」、あまり使わないデータには「低頻度アクセスストレージクラス (EFS IA)」を選択
スループット使用量
データの読み書き速度に応じて料金が発生
Bursting Throughput モードでは、基本的な速度が提供され、使っていないスループットが貯まると一時的に高速になる。
Provisioned Throughput モードでは、設定した速度に応じて料金が発生
Elastic Throughput モードでは、実際に使ったデータの読み書き量に応じて料金が発生

参考
料金 - Amazon EFS | AWS
Amazon EFS パフォーマンス - Amazon Elastic File System
 スループットモード次にAmazon EFSには、現時点（2025/1）で以下の3つのスループットモードがあります。
Elastic Throughput モード（デフォルト）
Provisioned Throughput モード
Bursting Throughput モード
各モードの性能とユースケースです。
参考：Amazon Elastic File System【AWS Black Belt】
ここで注意しなければならないのが、デフォルトの Elastic Throughput モードです。Elastic Throughput モードはスループットが自動的にスケールアップまたはスケールダウンします。Bursting Throughput モードのようにベースラインスループットの概念がないため、バーストクレジットも与えられません。使用したスループット全てに対して料金が発生します。
そのため、定常的に読み書きが多いワークロードの場合は、Elastic Throughput モードを使用すると想定よりも課金が発生しがちです。
参考：Amazon EFS の Elastic Throughput モードと Bursting Throughput モードでファイルの読み書きしてスループットを確認してみた | DevelopersIO
今回対象となったアカウントにおいても、Elastic Throughput モードを使用していたため、コストが増加していました。
 CloudWatchメトリクスで原因調査してみたCloudWatchメトリクスで原因調査する方法をご紹介します。
EFSのCloudWatchメトリクスで以下の指標を確認することで、異常なスパイクや通常と異なるパターンを確認することができます。
DataReadIOBytes: 読み取りIO量
MetadataReadIOBytes: 各メタデータの読み取りIO量
また読み込み課金はこのメトリクスの合計値（DataReadIOBytes + MetadataReadIOBytes）となり、東京リージョンの価格は以下の通りです。
Elastic スループットリクエスト - Data and Metadata 読み取り (転送 1 GB あたり) : 0.04USD
参考：料金 - Amazon EFS | AWS
対象のアカウントを確認すると、該当の1月8日に特徴的な動きが見られました。
MetadataReadIOBytes（5分間の合計）
DataReadIOBytes（5分間の合計）
よって、グラフから以下のような考察ができました。
全体的な動き
MetadataReadIOBytes（上のグラフ）は23:00頃から急激に増加傾向にある
DataReadIOBytes（下のグラフ）は21:00に大きなスパイクがあり、その後は比較的安定している
特徴的な動き
MetadataReadIOBytes
21:00-22:45までは6.16M前後で安定
23:00-23:30の間に大きく増加（最大で約551M）
23:45以降は再び低いレベルに戻っている

DataReadIOBytes

　- 21:00に約201Gの大きなスパイク

　- その後は2.13M前後で安定して推移
考えられる原因
以下のような処理が原因として考えられる
ファイルシステムの全検索やスキャン
バックアップ処理
ファイル同期ツールの実行
アプリケーションの異常な動作

なお、1ファイルあたりの読み込みメタデータのIOは4KiBとなり、このサイズはファイルの大きさによって変わりません。そのため、小さいファイルが大量にある環境で頻繁な読み書きが発生すると、想定以上の課金が発生する可能性があります。
参考：Amazon EFSのメタデータの読み書きサイズが気になったので検証してみた | DevelopersIO
実際このアカウントをお持ちのお客様にAmazon EFSに利用用途を確認したところ、微小な書込みを大量に行っているようでした。
 コスト削減方法Amazon EFS でProvisioned Throughput モードを使っている場合にコストを削減する方法をいくつかご紹介します。
 Bursting Throughput モードに変更し、ベースラインスループットを増やす意図的にダミーファイルを作成してストレージ使用量を増加させることでベースラインスループットをあげる方法がある。詳細は参考資料をご参考ください。
参考
EFS のバーストスループットモードについて、ベースラインスループットを増やす方法を教えてください
Amazon EFSのバーストクレジットを活用してコストを4分の1に削減！ - Uzabase for Engineers
 クライアント側のファイルの操作を最適化する原因調査でも記載したように大量の小さなファイルを操作する場合、メタデータが付与されてコスト増加に繋がります。そのため可能であれば、クライアンド側で並列処理や1ファイルにまとめて処理することでコストを削減することができます。
参考
Amazon Elastic File System【AWS Black Belt】
なお、こちらは机上調査となりますので、他にも有益な方法をご存知の方はぜひフィードバックいただけると幸いです。
 最後に今回はAmazon EFSで読み取りコスト増加に対して、CloudWatchメトリクスで原因調査する方法をご紹介しました。
Amazon EFSの利用においては、スループットモードの選択やファイル操作の最適化が重要です。ぜひ、今回の内容を参考にして、コスト管理とパフォーマンスの最適化に役立ててください。
最後までお読みいただきありがとうございました！
以上、おつまみ（＠AWS11077）でした！
 参考料金 - Amazon EFS | AWS
Amazon Elastic File System【AWS Black Belt】
Amazon EFS の Elastic Throughput モードと Bursting Throughput モードでファイルの読み書きしてスループットを確認してみた | DevelopersIO
Amazon EFSのメタデータの読み書きサイズが気になったので検証してみた | DevelopersIO
EFS のバーストスループットモードについて、ベースラインスループットを増やす方法を教えてください
Amazon EFSのバーストクレジットを活用してコストを4分の1に削減！ - Uzabase for Engineers
EFS で適切なスループットモードを選択する | AWS re:Post