Ryusuke Tesaki

「完全に個人の意見」ですが、特にこだわりがなければ、AWS 上で動かすPublic にアクセス可能なWEBアプリの前段にはCloudFront を置くことをワイはお勧めしますやで！ 理由は以下の３つやで。 1. ネットワーク転送量コストの観点 2. スパイク時の負荷分散 3. ネットワーク経路の最適化 ---以下説明--- 1. ネットワーク転送量コストの観点 AWSのネットワークコストの多くは、インターネットへのアウトバウンド通信じゃないでしょうか。CloudFront を挟むことでこれが単純増加しないかと誤解されている方が多いですが、CloudFront のオリジンにAWSのサービスを設定している際は、オリジンからのデータ取得は無料です（1枚目の画像参照）。 また CloudFront Security Savings Bundle を使えば、1 年間にわたって月間最低使用量を確約いただくことと引き換えに、CloudFront の請求額を最大 30% 節約できるオプションも使えますよ。 後述しますが、キャッシュできない動的アプリケーションもキャッシュ無効化してCloudFront 挟むメリットがあるんすよ。 --- 2. スパイク時の負荷分散 ECサイトでの商品画像とか、エンドユーザー向けのサービスとかで何かしらの画像配信をしている人からよく言われるんですが、 「画像の更新が頻繁に発生するので長くキャッシュさせると切り替わらないのでCDN挟んでいない」 とか、 「画像更新のたびにInvalidation のAPI叩いてたら高額になってしまった」 聞きます。 そういう場合はTTL 10secとかでいいのでキャッシュしておくといいと思います。これだけでスパイク時のオリジンへの負荷分散として役立ちます。たとえば10secに1万リクエストきたとしたら、もちろんキャッシュ時間短いので最初の1リクエストはオリジンに行くけど、残りの9999リクエストをエッジロケーションからの配信になり、オリジンへのリクエストの負荷分散になります。 10sec画像切り替わらないで困るケースもあんまりないんじゃないでしょうか。 --- 3. ネットワーク経路の最適化 「動的コンテンツが多いしキャッシュできないしCloudFrontいらないかな〜」「毎回オリジンに取りに行いくって無駄じゃね？」というお気持ちに関してお伝えしたい話です。ユーザー -> ALBでアクセスするようなサービスを考えた時、この間にCloudFrontエッジロケーション を挟むことで、エッジロケーションからALB間の通信はAWS のバックボーンネットワークを通ります(2.3枚目の写真) AWS バックボーンネットワークを介した通信をすることで、より安定したユーザ体験や経路の最適化が期待できます。