質問: 【料金面のまとめ】 * EBS(汎用SSD)とS3ならS3の方がストレージ容量が安い * S3とCloudFrontなら転送料金は変わらないが、CFの方がリクエスト料金が安い ってことで、外部からの取得はCF経由してS3をストレージにするのがいい。 【良い点】 * S3はレスポンスが早い * CloudFrontはアクセス元に近いリージョンにキャッシュを作成するため、 以降のレスポンスが早くなる。(S3よりも) 【悪い点?】 * S3にアップする為の方法を習得しなくてはならない * CloudFrontのキャッシュに気を付けなくてはならない 以上です。 詳しい方がいらっしゃいましたら、ご助言頂けると非常に助かります。 よろしくお願い致します。
回答: まず、 > > 「EC2にファイルを保存し、そのファイルへ直接アクセスする」 > > > ことによる問題点から考えて見ましょう。 一つ目に、「EC2にファイルを保存する」ことによって、 ファイルの管理法(ディレクトリベースなら、1ディレクトリに入れられるファイルの制限などがありますね)や 拡張時のディスクの増やし方などについて考慮する必要があります。 二つ目に、「ファイルへ直接アクセスする」ことによって、 毎回サーバーがリクエストを処理しなければならないために、処理を分散する方法を考えることや SSL通信であれば証明書の管理をする必要もあります。 これらの問題に対して、 * S3 (Object Storage): 一つ目の問題に対応 * cloudfront (CDN): 二つ目の問題に対応 という関係にあります。 すなわち、 S3はデータを保存するためのサービスであり、 cloudfrontはコンテンツを外部へ配信するためのサービスですので、 サービスで構築するネットワークの中で入るべき位置が異なります。 ``` Client ↓ 外からアクセス [cloudfront] (キャッシュを返すことでサーバー負荷を減らし、レスポンスも早くする) ↓ キャッシュがないところへのアクセスやPOSTなどサーバーで処理する必要があるもの ↓ (キャッシュがあれば cloudfront で処理して返す) [ELB(入れるなら)] (サーバーを割り振って負荷を分散させる) ↓ 負荷分散 [EC2] (保存や削除・キャッシュされてないものを返すなど、処理を担当) ↓ 保存する必要があるデータ [S3] (データを保持) ``` 基本的にはこのような構造となることが考えられます。 ここまで踏まえて、ご質問に戻りますと、 システムからファイルを管理するための**ストレージとしては S3 の方が、より適切**であると言えます。 最終的には cloudfront も導入されるかと思いますが、 一年程度はアクセスも少数であることが予想されるとのことですので、 ``` 通常のアクセス client → EC2 → client ファイルへのGETアクセス client → EC2 → (対応S3データのアドレスへリダイレクト) → (client) → S3 → client ファイルへのPOST/PUT/DELETEアクセス client → EC2 → (S3のAPIを叩く) → S3 → (API結果) → EC2 → client ``` こんな感じのルートになるようにしておけば、後々の拡張性など含めてスッキリした感じになるのではないでしょうか。 (ちなみに、awsにこだわらないのであれば、S3のような Object Storage サービスとして OpenStack の Swift を使わせてくれるサービスは国内外ともに多くあります。 安定性など他の問題も考える必要はありますが、料金重視でしたらこちらの方が安くなる可能性もあります。)