[AWS]キャッシュを持たないCloudFrontの利点とは?

By | 2018年7月3日

 最近ブログ名のラズパイがあまり出てきていません。どうものなめです。

タイトルにある「キャッシュなしのCloudFront」ってどういうことか分かりますか?

キャッシュサーバーのサービスなのにキャッシュを一切持たせないとはこれいかに・・・って思いませんか?知っている人からしたら当たり前なのでしょうが、私はこの構成を知ったときは、「え?なんで???」って思いました。しかし以外にも調べてみるとキャッシュを一切持たせないCloudFrontを使ってる情報が出てくるんですよね・・・。

 ということで、今回はキャッシュを保持しないCloudFrontの利点について調べてみました!

 

構成について


 文字だけじゃイメージし難いと思ったのでさっくりシンプルアイコンでシステム図を描きました。図にいくつか余計なものが描いてあるので、勘のいい人は既に利点に気が付いたのではないでしょうか。

 

1つ目の利点

 まず1つ目の利点は、SSL対応が容易な点です。仮にオリジンサーバーがhttpsに対応していなくても、CloudFront側でhttpsへの対応を行うことができます。その場合はオリジンサーバーとのアクセスがhttp(ポート:80)になるため、ヘッダ情報を書き換えるなどの工夫をしてあげないとMixedContentがたくさん出てしまいますが・・・。

 https化するためにALBかCloudFrontのどちらかを使うとしたら、規模の小さいサイトならコスト的にも後者で良いかなと思います。

 

2つ目の利点

 2つ目の利点は、S3のsorryページへのアクセスです。CloudFrontを経由したアクセスで、もしもオリジンサーバーのアクセスにエラーが生じた場合には、任意のエラーコードを返してS3の静的ページを表示させることができます。また、CloudWatchでエラーコードのメトリクスを監視させれば、どんなエラーが発生したのかを記録することができ、SNSで通知の設定をしておけば不具合にすぐ気がつくことができます。

 しかし、正直これだけであれば別のサービスでも対応できそうですね。

 

3つ目の利点

 3つ目の利点は、WAFを使うことができることです。ぶっちゃけこれが一番大きなメリットなんじゃないかなと思っています。WAFというのは『ウェブアプリケーションファイアウォール』のことで、ざっくり説明してしまうと悪意ある攻撃を弾いてくれます。

 AWSのサービスにある「AWS WAF」は単体で使うことができません。必ずALBかCloudFrontと紐付けて使用する必要があります。であれば、わざわざCloudFrontを使わなくても、ALBにWAFを使うように設定すれば良いことになります。

 結論としてはALBでWAFの設定をすることは間違いではないです。しかしCloudFrontを利用した方がセキュリティ面でのメリットが大きくなります。

 

ALBとCloudFront


 世界中の不特定多数から悪意あるアクセスが発生したとします。
ALBにWAFを設定している場合には、東京リージョン内まで悪意あるアクセスを許してしまいますが、最終的にはそれをALB側で弾くことになります。


 CloudFrontでWAFを設定した場合にはどうなるでしょうか。CloudFrontでは世界中に100個以上のエッジロケーション(キャッシュサーバー)が設置されており、ユーザーがアクセスするときは最も近くにあるエッジロケーションを経由することになります。

 CloudFrontのWAFでは、このエッジロケーションでファイアウォールが実行されます。すなわち、エッジロケーションの時点で悪意ある攻撃を弾くため、オリジンサーバーのある東京リージョン内へは魔の手が届きません。

 

まとめると…

 CloudFrontを挟むことで、より一層セキュアな設計をすることが可能になります。(多分)
そのため、キャッシュ目的でない場合であってもCloudFrontを利用するケースがあるようです。

 軽く調べて納得したので理由をまとめて見ました。「間違ってるよ」とか「ほかにもこういうメリットがあるよ」みたいな先人たちのアドバイスをお待ちしています。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)