LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

ファイルストレージの請求額が毎月少しずつ増えている。古いファイルも多いはずなのに、どの設定を見直せば費用が下がるのか分からない——。AWSで共有ファイルストレージを使っている現場では、こうした悩みが起こりがちです。Amazon EFSのコスト最適化とは、ファイルの使われ方に合わせてストレージクラスとスループットモードを選び、使われなくなったファイルを料金の安いクラスへ自動で移す設定を整えて、費用を抑え続ける取り組みを指します。

設定する項目そのものは多くありません。ただし万能ではなく、よく読まれるファイルまで安いクラスへ移すと、読み取りの料金がかさんで合計の費用がかえって増えます。本記事では、AWSの運用を担当する情報システム部門の方に向けて、3つのストレージクラスの違い、スループットモードとライフサイクル管理の設定、つまずきやすい点、そして外部に委託するときに確認したい点を整理します。

Amazon EFSのコスト最適化とは

Amazon EFS（Amazon Elastic File System）は、AWSが提供するフルマネージド型の共有ファイルストレージサービスです。フルマネージドとは、ストレージの容量の用意や管理をAWSに任せられるという意味です。EC2（AWSの仮想サーバー）など複数のサーバーから同時に接続して使え、NFSv4（ネットワーク越しにファイルを共有するための規格）で接続します。

費用を左右する設定は主に2つあります。1つはファイルをどのストレージクラスに置くか、もう1つはスループットモードをどれにするかです。コスト最適化では、まず業務データがどのくらいの頻度で読まれているかを調べ、その結果をもとにファイルを別のクラスへ移す条件を決め、設定した後も見直します。

図に示した5つの段階（現状の調査から効果の測定まで）のうち、アクセス頻度の調査と、移す条件の設計には、AWSの知識に加えて、業務でどのデータをいつ使うのかという理解が要ります。社内で進めるか外部に委託するかを決めるときも、この2つを誰が受け持てるのかが判断の材料になります。

3つのストレージクラスの違い

Amazon EFSには、EFS Standard、EFS Infrequent Access（IA）、EFS Archiveの3つのストレージクラスがあります。AWSは、IAを四半期に数回しかアクセスされないデータ向け、Archiveを年に数回またはそれ未満の頻度でアクセスされるデータ向けと説明しています。^*1 Standardは、日常的に読み書きするデータを置くクラスです。

AWSの説明では、IAは「EFS 標準よりも最大 95% のコスト削減を実現します」^*1、Archiveは「EFS 低頻度アクセスよりも最大 50% のコスト削減を実現します」とされています。^*1 これは保存しておくための料金の話です。IAやArchiveに置いたファイルを読み取ると、保存の料金とは別に、読み取った量に応じたアクセスの料金がかかります。

想定よりよく読まれるデータをIAへ移すと、読み取りのたびに料金が積み上がり、合計の費用がかえって増えることがあります。保存の料金とアクセスの料金のどちらが大きくなるかは、そのデータが読まれる頻度で決まります。移す前にアクセスの状況を調べ、移してよいデータを見極めておきます。ブロックストレージの費用の見直しは「AWS EBSボリュームのコストを最適化する外注の進め方」で扱っています。

スループットモードと費用

費用はストレージクラスだけでなく、スループットモードの選び方でも変わります。スループットとは、決まった時間に読み書きできるデータの量のことで、スループットモードは、その上限の決め方です。Amazon EFSでは、主に次の3つから選びます。

• Elastic Throughput（既定）：処理の量に応じてスループットが自動で増減し、使った分だけ料金がかかる。アクセスが不規則な処理に向いている
• Provisioned Throughput：スループットをあらかじめ決めて確保する。必要な性能のピークがはっきりしている処理に向いている
• Bursting Throughput：保存しているデータの量に応じて、基準となるスループットが決まる

どのモードが合うかは、データの読み書きがどのくらいの間隔と量で起きているかを調べたうえで判断します。AWS Cost Explorer（AWSの費用を集計して表示する機能）やCloudWatch（AWSの監視サービス）で集める計測値（メトリクス）を読み慣れていないと、選ぶのが難しい設定です。モードを変えた後は、費用と読み書きの量の変化を確かめておくと、次の見直しの材料になります。

ライフサイクル管理の設定

ライフサイクル管理は、ファイルが最後にアクセスされた日を基準に、StandardからIA、Archiveへファイルを自動で移す機能です。^*2 一度設定すれば、ファイルを手作業で移す必要はありません。設定するポリシーは次の3種類です。^*2

• IAへの移行（Transition into IA）：最後のアクセスから決めた日数がたつとIAへ移す。既定は30日
• Archiveへの移行（Transition into Archive）：最後のアクセスから決めた日数がたつとArchiveへ移す。既定は90日
• Standardへの戻し（Transition into Standard）：IAやArchiveのファイルにアクセスしたとき、Standardへ戻すかどうか。既定は戻さない

IAとArchiveへ移すまでの日数は、1日、7日、14日、30日、60日、90日、180日、270日、365日の9つから選びます。^*3どの日数が合うかは、業務システムのデータの使われ方で変わります。検討の例を挙げると、ログファイルなら7〜14日、過去の数回分を残すバックアップなら90日以上、長く保存する静的なファイルなら180日以上が候補になります。

既定の30日と90日のままでも動きますが、この日数がすべてのデータに合うとは限りません。ファイルの種類ごとにアクセスの間隔を確かめてから日数を決めると、前の節で触れたアクセスの料金の増加を避けやすくなります。業務の決まりでデータを保存する期間が定められている場合は、その期間とも照らし合わせておきます。

つまずきやすい点

ライフサイクル管理には、知らずに設定すると費用が思ったほど下がらない動きがいくつかあります。AWSのドキュメントが挙げている点を整理すると、次のとおりです。^*2

• ファイル名、所有者の情報、ディレクトリの構成といったメタデータ（ファイルを管理するための情報）は、常にStandardに保存される
• フォルダ（ディレクトリ）の中身を一覧表示しても（lsコマンドなど）アクセスには数えられず、経過日数は最初から数え直されない
• IAやArchiveのファイルへの書き込みは、まずStandardに書き込まれ、24時間たってから再び移す対象になる
• 移す処理は通常のファイル操作より優先度が低く、ファイルの数が多いと時間がかかることがある

このため、書き込みの多いファイルはStandardに残りやすくなります。移す処理が進んでいるかは、設定した直後ではなく、しばらくたってから費用とクラスごとの保存量で確かめるのが確実です。

もう一つ気をつけたいのが、応答の速さを求めるシステムのデータです。性能の要件が厳しいアプリケーションのデータがArchiveへ移ると、読み取りの応答が遅くなります。ミリ秒単位の応答が求められるシステムでは、サービスの品質に影響が出るおそれがあります。

社内で進めるときに要る知識

Amazon EFSのコスト最適化を社内で進める場合、次のような知識が要ります。

• AWSのサービス全般：EFS、EC2、IAM（AWSの利用権限の管理）、CloudWatch、AWS Cost Explorer、AWS CLI（コマンドでAWSを操作する道具）
• ファイルシステムの設計：NFSの仕組み、接続口となるマウントターゲットの設定
• アクセスの状況の分析：CloudWatch Logsやメトリクスを使って、アクセスの頻度を見えるようにする
• 費用の試算：ストレージクラスを移した後の月額の変化を見積もる
• 継続的な監視と見直し：費用の異常を知らせるアラートの設定、ポリシーの定期的な見直し

初めの設計と設定が済んだ後も、毎月の費用の確認、ポリシーの調整、アクセスの状況の再分析が続きます。EC2のインスタンス構成を変えたり、アプリケーションを改修したりするたびに、ポリシーを見直すことになるのも珍しくありません。AWSの運用を専任で受け持つエンジニアがいれば社内でも進められますが、アクセスの料金、スループットモード、ライフサイクル管理の細かな動きを覚えるには時間がかかります。

外部に委託するときに確認しておきたい点

委託先を選ぶときは、3つの点を確かめておくと比べやすくなります。第一に、AWSの実績とEFSの運用経験です。AWS認定資格（Solutions ArchitectやDevOps Engineerなど）を持っているか、AWSパートナーネットワーク（APN）に登録しているかを確認します。ほかのAWSサービス（S3やEC2など）の経験だけでは、EFSのライフサイクル管理やNFSのマウント設定に慣れているとは限らないため、似た案件の実績も見せてもらうとよいでしょう。

第二に、業務の要件を理解しようとする姿勢です。EFSのコスト最適化は、どのデータをどのくらいの頻度で使うのかが分からなければ設計できません。話を聞かずにすぐ設定値を示す委託先より、業務の流れ、データの性質、アクセスの状況を丁寧に確かめる委託先のほうが、合った設計につながります。第三に、保守と見直しの体制です。毎月の報告、定例の改善会議、アラート設定の維持まで、設定した後の体制を提案の段階で確かめておきます。

依頼の進め方は4つの段階に分けられます。まず、EFSのファイルシステムの数と保存容量の合計、いまのストレージクラスの構成（Standard・IA・Archiveの割合）、月々のEFSの費用（AWS Cost Explorerで確認できます）、どのアプリケーションやシステムがEFSをマウントしているかを社内でまとめます。現状の費用がはっきりしていれば、委託先との打ち合わせが早く進み、改善の効果も測りやすくなります。

次に、依頼の内容をRFP（提案を求めるための依頼書）にまとめます。費用の削減目標だけでなく、応答の遅れの上限やスループットの要件、データを保存する期間の決まり、移行の作業をしてよい時間帯、異常を知らせる方法と連絡先も書いておきます。そのうえで2〜3社以上から提案を受け、設計の考え方、移行の計画、保守の体制、費用を比べます。

最後に、本番環境に適用する前に、検証用の環境（ステージング環境）でライフサイクルポリシーの動きを確かめます。移した後の費用の変化、読み取りの応答時間、アプリケーションの動作を確かめてから本番環境へ広げる手順にしておくと、アクセスの状況の見込み違いによる性能の低下や費用の増加を防ぎやすくなります。

まとめ：EFSのコストで確かめたい3つの点

Amazon EFSのコストを最適化するうえで、確かめておきたい点は3つに整理できます。第一に、3つのストレージクラスの違いと、保存の料金とアクセスの料金の兼ね合いを理解したうえで、移すデータを選ぶこと。第二に、ライフサイクル管理の日数を既定の値のままにせず、業務データのアクセスの間隔に合わせて決めること。第三に、委託先をAWSの技術力だけでなく、業務の要件を理解する力と、設定した後の保守の体制で選ぶことです。この3点を踏まえておけば、「安いクラスへ移したのに、請求額がかえって増えた」という事態を避けやすくなります。ストレージクラスの設計や設定の見直しに迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：Amazon Web Services「Amazon EFS の特徴」（https://aws.amazon.com/jp/efs/features/）。出典：Amazon Web Services「Amazon EFS の特徴」。ストレージクラスの説明（IAは四半期に数回、Archiveは年に数回以下のアクセス向け。IAとArchiveのコスト削減の説明）を参照（2026年9月確認）
2. *2　参考：Amazon Web Services「Managing storage lifecycle — Amazon Elastic File System」（https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html）。出典：Amazon EFS ユーザーガイドのうち、3つのライフサイクルポリシーと既定値、メタデータの保存先、書き込み後24時間の扱い、移行処理の優先度に関する記述を参照（2026年9月確認）
3. *3　参考：Amazon Web Services「LifecyclePolicy — Amazon EFS API Reference」（https://docs.aws.amazon.com/efs/latest/ug/API_LifecyclePolicy.html）。出典：Amazon EFS API リファレンスのうち、TransitionToIA・TransitionToArchiveに指定できる値（1日〜365日の9種類）を参照（2026年9月確認）

Tweet