Amazon S3 の API オペレーションを分析してストレージコストを最適化する

このブログは Manish Singh（シニアテクニカルアカウントマネージャー）によって執筆された内容を日本語化したものです。原文はこちらを参照してください。

急速に変化するデータ環境（例：大規模なデータが頻繁に作成、共有、複製される状況）により、データストレージの需要が高まっています。多くのお客様は、費用対効果の高いデータの保存方法や、費用をかけずにデータから必要となるすべての情報を入手できる最適な方法を探しています。

クラウドストレージは、「従量課金」モデルによる柔軟なオプションを提供しています。Amazon Simple Storage Service（Amazon S3）は、業界をリードするレベルのスケーラビリティ、可用性、セキュリティ、そしてパフォーマンスを提供するオブジェクトストレージサービスです。Amazon S3 に移行することで、俊敏性を向上し、過剰なプロビジョニングが不要になることでコストが最適化され、無制限のスケールを享受することができます。

あらゆる規模のお客様が、さまざまなワークロードやユースケースで Amazon S3 を活用しています。そして多くのお客様は、ワークロードに適したストレージクラスを特定し、S3 ライフサイクルを設定してストレージコストを削減することを心地よく思います。一方でお客様は、アプリケーションパフォーマンスに影響を与えたり運用上のオーバーヘッドを発生させたりすることなく、Amazon S3 のコストを詳細に調査し、料金を最適化する新しい手段を知りたいと考えています。

このブログでは、適切なストレージクラスを使用するだけではなく、Amazon S3 の料金を最適化する方法についても紹介します。API リクエスト（オペレーション）に関連する Amazon S3 の料金を可視化する方法、API リクエストが多く発生しているバケットを特定する方法、S3 バケットへの API コールを詳しく調査する方法、API リクエスト費用を最適化する一般的な手順について詳しく説明します。コストを最適化する際の多くに共通することですが、今回紹介する情報は特に Amazon S3 の料金モデルを理解するのに役立つはずです。そして、料金の監視と分析に利用可能なさまざまなツールを使用したり、詳細を確認することができるようになります。

Amazon S3 の料金体系

Amazon S3 に関連する料金は以下の 6 つに分類できます。

1. ストレージクラスの GB 単価に基づいて課金される、保存されたデータ容量に対するストレージ料金。
2. API リクエスト料金とも呼ばれるリクエストとデータ取得料金。例えば、GET、PUT、LIST といった操作で、行われる API の呼び出し回数に基づきます。
3. インターネットや他リージョンにデータを転送する際のデータ転送料金。
4. アカウントのバケットに対して有効化する、ストレージ管理と分析機能（S3 インベントリ、S3 ストレージクラス分析、S3 Storage Lens、S3 オブジェクトタグ）の料金。
5. S3 クロスリージョンレプリケーション、同一リージョンのレプリケーション、および S3 バッチオペレーションに関連する料金。
6. S3 Object Lambda の料金。

ストレージ料金やデータ転送料金を別にすると、GET、PUT、LIST、HEAD やライフサイクル移行などの API リクエストは Amazon S3 における料金の特に大きな部分を占めています。現在の Amazon S3 コスト最適化手法のほとんどは、適切なストレージクラスの特定やデータ転送の最適化に重きを置いており、API リクエスト料金については考慮に漏れがちです。

リクエストとデータ取得（API リクエスト）の料金は、以下の 2 つの要素に基づきます。

1. S3 バケットやオブジェクトに対して行われる、GET、PUT、ライフサイクル移行などの API リクエストの種類。1000 リクエスト毎の料金については、Amazon S3 料金ページの「リクエストとデータ取り出し」セクションを参照してください。
2. S3 バケットに対して行われた API リクエスト数。API リクエストの料金はリクエスト数に基づき、データのサイズやリクエストがコンソールや CLI、SDK のいずれを介して実行されたかは関係ありません。例えば、コンソールからの GET リクエストと CLI からの GET リクエストの料金は同じになります。同様に、1 KB のファイルと 1 MB のファイルの GET リクエスト料金は同じになります。

API リクエストに関連する料金は、AWS Cost Explorer や AWS コストと使用状況レポート（AWS CUR）において、PutObject や ListObject などの名前で確認することができます。

AWS Cost Explorer を使用し Amazon S3 の料金を可視化する

AWS Cost Explorer は Amazon S3 の API リクエスト料金を可視化し、料金に大きく影響している API リクエストの絞り込みに役立ちます。

1. AWS Cost Management にサインインし、Cost Explorer に移動します。
2. フィルターセクションのサービスから、S3（Simple Storage Service）を選択します。適用をクリックします。
3. フィルターセクションの使用タイプグループから、S3: API Requests – Glacier、S3: API Requests – Standard、S3: API Requests – Standard Infrequent Access、 S3: Data Retrieval – Standard Infrequent Access などの状況に適したフィルターを選択します。適用をクリックします。
4. API リクエストの種類を分析するために、グループ化の条件セクションにて API オペレーションを選択します。
5. 分析したい日付範囲を選択し、適用をクリックします。
6. これにより、さまざまな API リクエストのコストと利用状況を示すグラフが表示されます。

7. CSV 形式でダウンロードを選択することで、API リクエスト数と関連料金をより自由に分析できます。

API リクエスト料金が発生しているバケットを特定する

Amazon S3 の料金を大きく占める API を特定したら、コストと使用状況レポートのデータを使用することで、バケットレベルの詳細を取得できます。以下は Amazon Athena を使用してコストと使用状況のデータを分析し、API リクエストが行われたバケットを特定する方法です。

1. コストと使用状況レポートの作成に従って、コストと使用状況レポートを有効化します。この時、バケットの詳細を取得する必要があるので、リソース ID を含めるを選択します。
2. Amazon Athena を使用したコストと使用状況レポートのクエリに従って、コストと使用状況レポートを Amazon Athena と統合します。
3. コストと使用状況レポートを有効化して Amazon Athena と統合できたら、次のクエリを実行し、バケット情報と関連する API リクエストとその料金の詳細を取得します。

SELECT
"line_item_operation" as API,
"line_item_resource_id"  as Bucket,
SUM("line_item_blended_cost") as Cost
FROM <<CUR_TABLE_NAME>>
WHERE "product_product_name" = 'Amazon Simple Storage Service'
AND "line_item_usage_type" not like '%Byte%'
AND "line_item_resource_id" != ''
AND line_item_usage_start_date >= CAST('YYYY-MM-DD 00:00:00' AS TIMESTAMP) 
  AND line_item_usage_start_date < CAST('YYYY-MM-DD 00:00:00' AS TIMESTAMP)
GROUP BY
"line_item_operation",
"line_item_resource_id"
ORDER BY
SUM("line_item_blended_cost") DESC

CUR_TABLE_NAME と日付の範囲（YYYY-MM-DD 00:00:00）を変更し、さまざまなバケットごとの API 料金を取得します。この情報は、バケットとそれに関連する API リクエスト料金の特定に役立ちます。

結果は次の表のようになります。

バケットに対して行われた API リクエストの分析

Amazon S3 サーバーアクセスログは、バケットに行われたリクエストの詳細を記録します。サーバーアクセスログを有効化し、 Amazon Athena を使用して API リクエストを分析します。

1. サーバーアクセスログを有効化し、Amazon Athena と統合します。詳細は Amazon Athena を使用して Amazon S3 サーバーアクセスログを分析するを参照してください。
2. 次のクエリを実行して、API リクエスト数の多い IP アドレスを特定します。

SELECT remoteip,requester,useragent,COUNT(*) AS remote_count
FROM <<access_log_bucket>>
WHERE Operation = 'api_call_to_review' AND
parse_datetime(RequestDateTime,'dd/MMM/yyyy:HH:mm:ss Z') 
BETWEEN parse_datetime('2021-08-08:00:00:00','yyyy-MM-dd:HH:mm:ss')
AND 
parse_datetime('2021-10-08:00:00:00','yyyy-MM-dd:HH:mm:ss') 
GROUP BY remoteip,requester,useragent
order by remote_count desc

ステップ 1 にて作成したテーブルを access_log_bucket にて指定し、REST.GET.BUCKET、REST.GET.LIFECYCLE、REST.GET.OBJECT、REST.PUT.OBJECT、REST.HEAD.OBJECT 等のトラックしたい要素を api_call_to_review にて指定します。また分析を行いたい時間の範囲も適宜指定してください。

API リクエストをさらに詳しく分析する際に使用できる他の列名について理解したい場合は、サーバーアクセスログのフォーマットに関するドキュメントを参照してください。

API 料金を最適化するさまざまな方法

コスト最適化を行いたい API コールとバケットを特定したら、以下の一般的なコスト最適化手法を参照してください。

GetObject と PutObject

GetObject と PutObject リクエストは、それぞれ S3 バケットからオブジェクトを取得、S3 バケットにオブジェクトを追加するために使用され、これらは頻繁に使用されます。GET および PUT API のコストは、追加および取得されるオブジェクト数に依存し、サイズは影響しないことを踏まえて戦略を検討します。

• 小さなオブジェクトが多数存在する場合、GET および PUT API のコストが高くなる可能性があります。アプリケーションのアーキテクチャを見直し、複数の小さなオブジェクトから、1 つの大きなオブジェクトに置き換えられないか検討してください。例えば、1 分ごとにファイルを作成する代わりに、過去 15 分間、もしくは 30 分間に加えられた変更データを使用するなど、より長い時間に基づいてファイルを作成しましょう。
• .tar や .zip ファイルを作成して、オブジェクトを 1 つのファイルにまとめます。この時、まとめられたファイル内における個々のオブジェクトの識別や、アクセスのしやすさを考慮する必要があります。
• S3 パブリックアクセスブロックを使用することで、バケットレベルもしくはアカウントレベルでオブジェクトへのパブリックアクセスをブロックし、不正アクセスや予期しない API 料金の発生を防ぐことができます。
• 静的オブジェクトが多数を占める場合、Amazon CloudFront を使用した GET リクエスト数の削減を検討してください。この場合、費用対効果の分析を別途行い、Amazon CloudFront を導入することでコストが削減され期待に応えることができるか判断する必要があります。
• コストと使用状況レポートを使用して、S3 バケットのストレージ料金と API リクエスト料金（GET、PUT、LIST）を比較します。S3 バケットの料金のうち API リクエストが多くを占める場合、最適なストレージクラスが選択できているのか、もしくは Amazon DynamoDB といった他の選択肢がワークロードに適しているのか検討する必要があります。

ListBucket

ListBucket は特定のバケットにおけるオブジェクトの一覧を表示するために使用されます。特定の S3 バケットにおいて ListBucket の料金が高い場合は、アプリケーションの設計を再確認し、この操作を頻繁に利用する理由を確認してください。またその理由を基に、HEAD リクエストで代替できないか検討してください。

S3 ライフサイクル移行

S3 ライフサイクル移行ルールは、オブジェクトを別のストレージクラスへ移行する際や期限切れにする際に使用されます。ライフサイクルの移行ルールの内容に応じて、次の 2 種類の料金が発生します。

• 移行料金：あるストレージクラスから別のストレージクラスに移行されたオブジェクト数に基づきます。
• 早期削除料金：一部ストレージクラスに定められた最小ストレージ期間を満たさない場合、削除料金が発生します。

S3 ライフサイクル移行ルールをバケット全体に適用するだけではなく、プレフィックスやオブジェクトタグ、オブジェクトサイズに基づいたフィルタリングを設定することで、移行料金を削減することができます。S3 ライフサイクル移行に関連するコストを管理するには、以下の 4 つのオプションを参考にしてください。

1. 移行するオブジェクト数を減らす
   • ライフサイクル移行ルールを適用するためにアクセスパターンを分析し、適切な S3 バケットとプレフィックスの範囲、および適切なストレージクラスを特定します。ライフサイクル移行ルールを設定する前に、S3 ストレージクラス分析や S3 Storage Lens などのツールを使用してアクセスパターンを監視し、オブジェクトサイズや総オブジェクト数などのさまざまなメトリクスを確認します。
   • ライフサイクル移行する前に、小さなオブジェクトを大きなファイル（.tar、.zip）にまとめてください。移行コストは移行されるオブジェクト数に基づくため、小さなオブジェクトを大きなファイルにまとめることで料金を削減できます。複数のオブジェクトをまとめる際は、検索性の考慮が必要になります。
   • オブジェクトタグはオブジェクトに関連づけられるキーと値のペアです。プレフィックスや 1 つ以上のオブジェクトタグ、またはその両方を使ってライフサイクル移行ルールにフィルターを定義し、移行または期限切れになるオブジェクト数を制限します。詳細については、S3 ライフサイクル移行ルールの設定に関するブログも参照ください。例えば、key が transition、value が glacier のオブジェクトのみを、Amazon S3 Glacier ストレージクラスのいずれかに移行するといったことができます。以下は詳細な手順となります。
     • Amazon S3 コンソールにアクセスし、設定したいバケットの管理タブに移動します。
     • ライフサイクルルールを作成するを選択します。
     • フィルターを指定するため、ルールスコープを選択にて 1 つ以上のフィルターを使用してこのルールのスコープを制限するを選択します。
     • フィルタータイプのセクションにてプレフィックスを指定し、ルールの適用範囲を絞り込みます。
     • 同じくフィルタータイプのセクションにて、オブジェクトタグの下にあるタグの追加を選択します。各タグはキーと値（任意）の両方に一致する必要があります。また、指定されたすべてのタグを持つオブジェクトに対してのみ、ルールが適用されます。もしオブジェクトに他のタグが存在していても、ルールは適用されます。
       • ライフサイクル移行ルールの目的でタグを追加する前に、費用対効果の分析を行って、オブジェクトタグを含めた費用削減効果を見積もってください。オブジェクトタグに関連する費用の詳細については、Amazon S3 の料金を参照してください。

2. ライフサイクル移行ルールを適用する前に、最小オブジェクトサイズと請求要件を理解してください。S3 Standard-Infrequent Access（S3 Standard-IA）および S3 One Zone-IA ストレージクラスの課金対象最小オブジェクトサイズは 128 KB です。つまり、128 KB 未満のオブジェクトを S3 Standard-IA や S3 One Zone-IA に移行しても、期待通りのコスト削減は果たせません。ストレージクラスごとに定められた最小オブジェクトサイズを確認するには S3 ストレージクラスのパフォーマンスチャートを参照してください。
   • ライフサイクル移行ルールは、オブジェクトサイズを基にしてフィルターを定義できます。コストを節約するために小さいファイルを移行したくない場合は、最小、最大オブジェクトサイズに基づいたフィルターが活用できます。

3. オブジェクトを移行、または期限切れにする S3 ライフサイクルルールを作成する前に、アクセスパターンに加えて、データ保持要件と各ストレージクラスの最小ストレージ期間を確認してください。例えば、S3 Standard-IA や S3 One Zone-IA には 30 日間の最小ストレージ期間が、S3 Glacier Instant Retrieval や S3 Glacier Flexible Retrieval には 90 日間の最小ストレージ期間が設けられ課金されます。ストレージクラスごとの最小ストレージ期間を確認するには S3 ストレージクラスのパフォーマンスチャートを参照してください。最小ストレージ期間を経過せずにオブジェクトの移行や期限切れを行った場合、最小ストレージ期間に満たない日数分が日割りで DeleteObject 料金として発生します。
4. S3 Storage Lens を使用することで、オブジェクトストレージの使用状況とアクティビティの傾向を可視化できます。S3 Storage Lens は、オブジェクト数、平均オブジェクトサイズ、PUT リクエスト、GET リクエスト、LIST リクエストなど 30 を超えるメトリクスを提供しており、ライフサイクル移行ルールの微調整や API リクエスト料金の最適化に役立ちます。以下は S3 Storage Lens を活用する手順の一例です。
   • S3 Storage Lens に関するブログを参考に、ダッシュボードを作成します。
   • ダッシュボードを開きタブの中からバケットを選択します。特定のプレフィックスを分析したい場合は、プレフィックスを選択してください。
   • 総ストレージ量、オブジェクト数、オブジェクトサイズの平均等のメトリクスを確認し、移行コストを見積もってライフサイクル移行ルールを決定します。

• • メトリクスのカテゴリからアクティビティを選択し、GET リクエスト、PUT リクエスト、HEAD リクエスト、LIST リクエストなどのメトリクスを確認して、API リクエストを分析します。

クリーンアップ

継続的に課金されないようにするには、このブログを基に作成したリソースを削除してください。

• Amazon S3 のサーバーアクセスログを停止してください。
• S3 ストレージクラス分析や S3 Storage Lens などの Amazon S3 の管理および分析ツールを停止してください。

まとめ

このブログでは、様々な Amazon S3 の API リクエストに関連する料金の可視化と分析について説明しました。そして、AWS Cost Explorer やコストと使用状況レポート、サーバーアクセスログをそれぞれ使用して、S3 バケットに関連する API リクエスト料金を特定する方法を示し、料金を最適化するための複数のアプローチを確認しました。

Amazon S3 を使用するお客様は、適切なストレージクラスの活用やデータ削除を行うことで、長年コストを最適化してきました。Amazon S3 へのリクエストや取り出し（API リクエスト）がどのように課金されるのか、また API リクエスト料金を削減するための一般的なアプローチを理解することで、さらなるコストの最適化が達成できます。API リクエストの料金体系を理解することで、管理者や開発チームは正しいアーキテクチャを設計でき、予想外の料金を回避することができます。

Amazon S3 のコストを削減するための、リクエスト料金とデータ取得料金の最適化に関するこのブログをお読みいただきありがとうございました。