🤔

静的サイトはなぜ S3 + CloudFront構成でホスティングするのか

SHIRO

2024/03/25に公開

はじめに

フロントエンドアプリケーション(特にSPAやシンプルなLPなど)をホスティングする際の選択肢として、安価かつ安定してやるならS3+CloudFront構成での配信を思いつくことが多いと思います。実際私も真っ先に思い浮かべることが多いのですが、その構成にすることに対して多くのメリットがあると漠然とは知っているものの詳しくは理解しきれていませんでした。また、S3はパブリックなエンドポイントを持ってるためCloudFrontをかますことは実はオーバーエンジニアリングだったりするのかもしれないという疑問も少し持っていました。
今回は、自分の理解不足&疑問の解消のために改めてまとめてみました。

S3 + CloudFrontのメリット

スケーラビリティと可用性

S3は耐久性が高く、スケーラビリティに優れたストレージサービスです。データ量の増加に伴い自動的にスケールアップし、EC2等で同じ静的サイトを作成することと違ってパッケージ管理のアップデートなどのメンテナンス作業が不要になります。
CloudFrontはAWSが提供するグローバルなCDNで、コンテンツをエッジロケーションにキャッシュします。これにより、世界中のユーザーに対して低遅延でコンテンツを配信できます。

パフォーマンスの向上

CloudFrontは世界中に分散された数百のエッジロケーションを有しています。ユーザーがサイトにアクセスすると、そのリクエストは自動的にユーザーに最も近いエッジロケーションにルーティングされます。ユーザーに最も近いエッジロケーションからコンテンツを提供することで、データ転送時間が短縮され、サイトの読み込み速度が向上します。地理的な距離が短いほど、ネットワーク遅延は小さくなります。
また、キャッシングによる効率的なコンテンツ配信を行います。最初のリクエスト時にエッジロケーションにキャッシュされ、同じコンテンツへの後続のリクエストはオリジンサーバーへの問い合わせを必要とせず、キャッシュから直接迅速に提供されます。コンテンツの種類に合わせたキャッシュの詳細な設定も簡単にコントロールも可能になっています。

セキュリティ

S3+CloudFrontの構成にすることで、HTTPSを介した安全なコンテンツの配信を容易に実現できます。AWS Certificate Manager（ACM）でSSL/TLS証明書を無料で取得し、CloudFrontに統合することが可能です。

CloudFront FunctionsやLambda@edgeの活用

CloudFront FunctionsとLambda@Edgeは、CloudFrontのCDN上で実行できる2つの異なるコンピューティングソリューションです。これらはブラウザやアプリといったクライアントとオリジンの間のエッジロケーション上で動作することで、認証認可やレスポンスの生成といったユーザー体験に寄与するちょっとしたカスタマイズを加えてユーザーの物理的の近い場所で高速に動かすことができます。

これらはエッジロケーションでコードを実行する点で共通していますが、使用目的、機能性、実行環境などにおいていくつかの違いがあります。詳しい違いについては公式のドキュメントや既にまとめてくださっている方々の記事を参照してみてください。

S3だけの構成では何が不足しているのか

S3はパブリックなエンドポイントを持ってるためCloudFrontを使わずともS3の場合で多くの場合問題ないと考えましたが、調査をしていくうちにS3だけでは不足しているポイントがあることがわかりました。

コストパフォーマンスの懸念

S3だけでホスティングしている場合、アクセスが急増した時のコストは、CloudFrontでキャッシュを作成している場合に比べて高くなる可能性があります。S3はインターネットへのデータ転送とGETリクエストなどのデータ取得リクエストに対してコストが発生するためです。
CloudFrontと組み合わせる場合、エッジロケーションにキャッシュされたコンテンツはオリジンであるS3からではなく、ユーザーに最も近いエッジサーバーから配信されます。その結果、S3からインターネットへのデータ転送量が大幅に削減されます。また、キャッシュされている間は同じコンテンツに対するリクエストがCloudFrontによって処理されるためS3に対するリクエスト数が減少します。したがって、アクセス量の増加が予想される場合は、S3とCloudFrontを組み合わせることで、コスト効率良く、高パフォーマンスなサービス提供が可能になります。

HTTPSの制限

S3の静的ウェブサイトホスティング機能では、HTTPSを直接サポートしていません。独自ドメインでHTTPSを利用したい場合、CloudFrontを経由してSSL/TLS証明書を適用する必要があります。AWS Certificate Manager (ACM) で取得した証明書はCloudFrontと無料で統合することが可能です。

パス変更などの複雑さ

S3だけを使用している場合、ウェブサイトのパス構造やドメイン名を変更したいときにはバケット内でのファイルの移動や再構成が必要になります。S3の静的ウェブサイトホスティング機能ではバケット名とドメイン名を合わせる必要どCloudFrontを使用すれば、S3のファイルパスや命名の再構成をせずとも、ディストリビューションの設定を変更するだけで柔軟にURLパスをコントロールが可能になります。

S3+CloudFrontでの実装サンプル

弊社のテックリードのtacrewさんが直近CDKを活用したSPA用にS3+CloudFront構成のホスティング環境作成を行なった記事があるので、実際にどうやって構築するのか気になる方は以下のの記事もぜひ読んでみてください。

参考

最後に

静的サイトのS3 + CloudFront構成にについては多くの場所で語られているもので今更感もありましたが、今回の記事を整理するにあたって非常に勉強になったのでいい機会となりました。
ここまで読んでいただきありがとうございました！

ファンタラクティブテックブログPublication

ユーザーファーストなサービスを伴に考えながらつくる、デザインとエンジニアリングの会社です。エンジニア積極採用中です！hrmos.co/pages/funteractive/jobs