CloudFrontと組み合わせた場合のAWSS3標準の低頻度アクセスと冗長性の低下ストレージクラス？
CloudFrontを使用して、現在S3の標準ストレージクラスに保存されているすべてのサムネイルをキャッシュして配布しています。 CloudFrontはオリジナルをキャッシュし、24時間ごとにのみアクセスするため、Standardよりも安価なストレージクラス（Standard Infrequent Access（IA）またはReduced Redundancy（RR））を使用するのが理にかなっています。しかし、どちらがより適切で費用効果が高いかはわかりません。
Standard-IAのストレージはすべての中で最も安価です（Standardクラスより58％安く、RRより47％安い）が、StandardとRRの両方よりも60％高価なリクエストです。ただし、Standard-IAクラスに保存されている128kb未満のすべてのファイルは、コストを計算するときに128kbに丸められます。これは、私のサムネイル画像のほとんどに適用されます。
一方、RRクラスのストレージはStandardよりも20％安いだけですが、その要求コストはStandard-IAよりも60％安いです。
どちらが実際に最も費用効果が高いかはわかりません。両方を使用した経験のある人は、フィードバックを提供していただければ幸いです。
あなたの質問の前提に問題があります。 CloudFrontがオブジェクトを一定期間キャッシュする可能性があるという事実は、S3ストレージクラスを選択するときに実際にはほとんど関連性がありません。
REDUCED_REDUNDANCYの方が安い場合があります¹S3はデータをより少ない物理デバイスに保存するため、低価格と引き換えに信頼性がいくらか低下します...また、障害が発生した場合は、オブジェクトは、統計的にS3によって失われる可能性が高くなります。冗長性が低下したためにS3がオブジェクトを失った場合、CloudFrontはある時点でエラーを返し始めます。
このストレージクラスを選択する際の決定要因は、オブジェクトを簡単に置き換えることができるかどうかです。
冗長性の削減ストレージ（RRS）はAmazon S3ストレージオプションであり、Amazon S3の標準ストレージよりも低いレベルの冗長性で重要ではない再現可能なデータを保存することで、お客様がコストを削減できるようにします。他の場所に永続的に保存されるコンテンツを配布または共有するため、またはサムネイル、トランスコードされたメディア、または簡単に複製できるその他の処理済みデータを保存するための、費用効果が高く可用性の高いソリューションを提供します。
STANDARD_IA（アクセス頻度が低い）は、別の理由で安価です。ストレージの節約は、取得料金によって相殺されます。オブジェクトが月に2回以上ダウンロードされる場合、合計料金はSTANDARDのコストを超えます。これは、純粋にアクセス頻度が低いオブジェクトを対象としています。 CloudFrontには複数のエッジロケーションがあり、それぞれに独自の独立したキャッシュがあるため²、オブジェクトがCloudFrontに「現在保存されている」かどうかは、単純な「はい/いいえ」の答えではありません。大きなCache-Control: max-age値を指定して「システムをゲーム化」することもできません。 CloudFrontはキャッシュストレージに課金されないため、指定した有効期限が切れる前にオブジェクトをキャッシュからパージできるのは賢明なことです。実際、事例観察により、ドキュメントが示していることが確認されています。「人気」が比較的低いために、オブジェクトがCloudFrontから削除されることがあります。
このストレージクラスを選択する際の決定要因は、増加したデータ転送（取得）料金が、それらが相殺するストレージ料金の節約を正当化するのに十分に低いかどうかです。オブジェクトのダウンロードが月に1〜2回未満であると予想されない限り、このストレージクラスはコスト削減を意味しません。
標準/まれなアクセスは、タールボールやデータベースダンプ、最初にアクセスした後にレビューされる可能性が低い画像など、実際には頻繁に必要とは思われないもののために予約する必要があります。たとえば、（私の世界から例を借りて）証明- of-リベート請求のために顧客がスキャンして送信した購入/領収書。リベートが承認されたら、その領収書をもう一度確認する必要はほとんどありませんが、ファイルに保存しておく必要があります。こんにちは、Standard_IA。 （ファイルが30日間保存された後、バケットのライフサイクルポリシーを使用して、S3がこれを自動的に行うことに注意してください）。
標準-IAは、長期のファイルストレージ、同期と共有からの古いデータ、バックアップデータ、およびディザスタリカバリファイルに最適です。
補足：ストレージコストを節約するための1つの代替メカニズムは、保存する前にコンテンツをgzip -9し、Content-Encoding: gzipを設定することです。私はこれをS3で何年も行ってきましたが、それを処理できないブラウザーを報告する最初のサポートチケットが来るのをまだ待っています。 .xlsxスプレッドシートなど、すでに圧縮されているとされるコンテンツでさえ、多くの場合、少し縮小します。また、絞り出すバイトごとに、ストレージとダウンロード帯域幅がわずかに少なくなります。 ）料金。
基本的に、元の画像が残っているサイズ変更された画像や、ソースデータから簡単に再実行できるレポートなど、コンテンツを簡単に置き換えることができる場合、またはコンテンツを他の場所にバックアップする場合（AWSは基本的に常にクラウドの最初の選択肢です）サービスですが、たとえば、S3アセットのバックアップを別のクラウドプロバイダーのストレージサービスに保存しています）...冗長性を減らすことは良いオプションです。
¹REDUCED_REDUNDANCYの方が安い場合があります一部の地域のみ 2016年後半現在。それ以前は、STANDARD、しかし、競争力のある価格設定の奇妙な世界の奇妙な癖で、 2016年11月に発表されたS3値下げ の結果として、一部のAWS地域では、STANDARDストレージクラスは、REDUCED_REDUNDANCY（ "RRS"）よりもわずかに安くなりました。たとえば、us-east-1では、Standardは$ 0.03/GBから$ 0.023/GBに削減されましたが、RRSは$ 0.024/GBのままでした...no明らかな理由はこれまでにありませんその地域でRRSを使用します。価格設定ページの構造は、RRSがAWSによる現世代のオファリングとは見なされなくなったという印象を残します。確かに、それはSTANDARD_IAとGLACIERの両方よりも古い製品です。完全に非推奨または廃止される可能性は低いですが、主要な製品に含まれなくなった場合、他のストレージクラスと一致するまでコストを削減する傾向はないかもしれません。
²「CloudFrontには複数のエッジロケーションがあり、それぞれに独自の独立したキャッシュがあります」は依然として技術的に正しいステートメントですが、CloudFrontは静かに展開を開始し、その後、いくつかの重要なアーキテクチャの変更を発表しました2016、 リージョナルエッジキャッシュ の導入。ある意味で、グローバルEdgeキャッシュが独立しているのは「真実ではない」ということです。 CloudFrontは2層ネットワークになり、グローバル（外層）エッジノード時々リージョナル（---）からコンテンツをフェッチするため、違いはほとんどありません。内側の層）オリジンサーバーから直接ではなく、エッジノード。これは、オブジェクトがキャッシュ内にあると見なされる可能性を高める影響を与えるはずです。これは、外側の層でのキャッシュミスが、より多くの利用可能なキャッシュがあると報告されている内側の層によるヒットに変換される可能性があるためです。外側の層の一部またはすべてよりもストレージスペース。地域のエッジがS3（カスタムオリジンのみ）に使用されていないことをドキュメントが示しているため、これがS3オリジンのヒット率にどの程度の影響を与えるかは外部の観察からはまだ明らかではありませんが、これが普遍的に当てはまるかどうかは明らかではないようです、特に Lambda @ Edge の導入により。それは重要かもしれませんが、この記事の執筆時点では、ここに提示された質問に対する私の回答に重要な影響を与えるとは思われません。
CloudFrontはオリジナルをキャッシュし、24時間ごとにのみアクセスするため
必要に応じて、CloudFrontキャッシュをもっと長くすることができます。キャッシュコントロールヘッダーを設定するメタデータをオブジェクトに追加する必要があります。 S3ドキュメント に従って、最大100歳までの年齢を指定できます。 max-ageを秒単位で設定するだけなので、オブジェクトを100年間キャッシュしたい場合は、次のようにします。
Cache-Control: max-age=3153600000
SIAとRRに関する主な質問については、2つの違いのすべてにほとんど触れています。どちらか一方を使用するコストを計算するだけです。いくつかの計算を実行して、コスト見積もりが何であるかを確認する必要があります。すべて128K未満のサムネイルが100個ある場合、SIAは100 * 128Kバイトの料金を請求しますが、RRはそれらの100個のサムネイルの合計サイズの費用を請求するだけです。同様に、CloudFrontでかなり高いキャッシュタイムアウトを設定した場合、S3からのフェッチは毎日10回しか表示されない可能性があるため、SIAは毎日10 * 128Kバイトの取得に対して課金しますが、RRはそれらの10個のサムネイルのサイズ。
サムネイルのサイズと量、および予想されるトラフィックの量に基づいていくつかの実数を使用すると、コストの見積もりを立てるのは非常に簡単です。
参考までに、 これらのスライドショー および/または これらのビデオ のいくつかもご覧になることをお勧めします。これらはすべてAmazonのre：Invent会議からのものであり、これらのリンクはそれらの会議でS3固有のプレゼンテーションを提供するはずです。