私たちは、S3 バケット (ムンバイ) から単一地域 (インド) のユーザーにビデオを提供しています。何千人ものユーザーがインドからのみこれらのファイルにアクセスすると予想しています。CloudFront ディストリビューションを使用する価値はありますか? CloudFront を使用すると、レイテンシーは短縮されますか? CloudFront を使用しない場合、S3 は帯域幅を処理できますか?
助けてくれてありがとう。
答え1
パフォーマンスの観点から言えば、はい、おそらく役に立つでしょう。
CloudFront は現在インドに 5 つのエッジロケーション (チェンナイ (2)、ニューデリー (1)、ムンバイ (2)) を持っているため、コンテンツがユーザーの近くに位置する可能性が高いため (ユーザーの地理的分布によって異なります)、CloudFront を使用するとレイテンシーを低く抑えることができると考えられます...
ただし、インドのエッジロケーションからダウンロードする場合は CloudFront に 0.17 ドル/GB のプレミアム コストがかかりますが、ムンバイの S3 から直接ダウンロードする場合は 0.1093 ドル/GB です (CloudFront + S3 を使用する場合、S3 帯域幅料金は適用されません)。
つまり、確かに「有用」ではあるが、この特定の地理的地域でコストを正当化するほど十分に有用であるかどうかは判断できない。
S3はベストプラクティスガイドラインCloudFront も使用されていない場合、1 秒あたり 800 (ピーク) または 300 (持続) を超えるリクエスト レートが予想されるバケットの場合GET。サービスはこれらの値を超えて拡張されますが、ガイドラインに従うことで、より効果的に拡張できます (ホット キーとインデックス ホット スポットは、適切に分散されたキーほど簡単に拡張できません)。100 リクエスト/秒未満のリクエスト レートの場合、特別な考慮は必要ありません。
追加のオプションはS3 転送アクセラレーション、AWSの「エッジネットワーク」（言い換えれば、CloudFront）を介してリクエストを選択的にルーティングします。輸送ネットワーク) ですが、実際のキャッシュは行われません。ムンバイでは、ダウンロードの場合は $0.04/GB + $0.1093/GB です。ここでの利点は、ブラウザがエッジロケーションのサーバーに接続している可能性があり、そこから S3 への接続がプロキシされることです。これにより、トラフィックはパブリックインターネットに渡される前に、AWS ネットワーク上で可能な限り長い距離を移動します。これにより、転送が最適化され、視聴者に近い中間地点でパケット損失が処理されるため、転送時間が大幅に短縮されます。S3 Transfer Acceleration を使用すると、CloudFront が最も近いエッジにリクエストを送信するために使用する DNS ロジックが、代わりに特定の視聴者を S3 リージョンに接続するための最適な方法を決定するために使用されます。そのため、ユーザーを S3 に直接接続することも (この場合、そのリクエストのアクセラレーション機能に対して $0.04/GB の帯域幅料金は請求されません)、エッジネットワーク経由でルーティングすることもできます (この場合、請求されます)。ここでの考え方は、バケットの位置情報に対するリクエスタの位置情報に基づいて、役に立たないと思われるリクエストについては、この機能が自動的にバイパスされるというものです。バケットでこの機能を有効にすると、バケットのエンドポイントも に変更されますbucket-name.s3-accelerate.amazonaws.com。これは REST インターフェースのみをサポートし、Web サイトのホスティング機能はサポートしませんが、リダイレクトやインデックス ドキュメントなどの機能を使用していない場合は問題ありません。地理的な場所とそこでの帯域幅の価格設定の特殊性を考慮すると、ここから始めるのが良いかもしれません。