AWS CloudFront導入時に気を付けること。

はじめに

パフォーマンスや負荷対策としてキャッシュを用いるという手法はよくあり、AWS CloudFrontもそれを提供するサービスの一つです。 しかしながら利用する上でいくつか注意点があるため、今回は3点ほど書いていこうと思います。

1-1. 静的コンテンツ用のエイリアスをCloudFrontで発行する

動的コンテンツをキャッシュしてしまうとマズイために動的コンテンツはCloudFrontを通さないようにする場合は静的コンテンツのみそれ用のエイリアスをCloudFrontで発行します。

サイトのFQDNはexample.co.jpだけど、画像などの静的コンテンツについてはsubexample.cloudfront.co.jpのようなドメインを発行し、それぞれのパスをsubexample.cloudfront.co.jp/img/test.pngなどにします。

1-2. AWS Shieldなどのサービスも導入し、動的コンテンツもCloudFrontを通るようにする場合はDNSの設定をする

1-1のような方法でも良いですが、AWS CloudFrontを利用するとAWS Shield Advancedの利用ができるため、せっかくならDDoS対策もしたいものです。 ただしAWS Shieldを通るようにするにはAWS CloudFrontを通らないといけないため、少し大変です。また、動的コンテンツをキャッシュするのもマズイので、それ用の対策もしなければなりません。

※AWS Shieldについては以下の記事が参考になるかと思います。

oooomincrypto.hatenadiary.jp

まずAWS CloudFrontを通るようにする場合、サイトのFQDNをCDN用のFQDNにするのはNGです。 すでにブックマークやリンクされていたりクローラーが訪れていた場合、FQDNを変えてしまうとその情報がなくなってしまうためです。

この場合はサイトのFQDNに対してCNAMEレコードを設定しましょう。そうすることでサイトのFQDNへアクセスしてもCloudFrontを通過します。

また、動的コンテンツのキャッシュを防ぐ方法については以下等が参考になるかと思います。

Amazon CloudFront が特定のファイルをキャッシュしないようにする

キャッシュしない CloudFront とそのメリット・デメリット | はったりエンジニアの備忘録

2. リバースプロキシの対応

AWS CloudFrontはリバースプロキシとしても動作します。 そのため、Webサーバに通信が来るときはリクエスト元のIPアドレスがサイトにアクセスした人のものではなく、Cloud FrontのIPアドレスに変わっています。 上記の場合、そのWebサービスへのアクセスをIPアドレスで制御するような仕組みを入れていると処理が正常に行われず困ってしまいます。

もちろんその対処法については存在しており、X-Forwarded-For(XFF)というHTTPヘッダに元々のIPアドレスを格納する仕組みを用いるのが一般的ですのでそちらを活用していきましょう。

developer.mozilla.org

上記の仕組みを利用する場合はプログラム内でX-Forwarded-Forヘッダーに格納されている一番左のIPアドレスを取得することでクライアントのIPアドレスを判断します。

おわりに

以上でAWS CloudFront導入時に気を付けることの解説でした。 (記事を書いてて思ったのが、特にAWS CloudFrontに限らずCDNサービス全体にいえることかな？？とも思ったり...。まあ...良いか。)