LoginSignup
4
5

More than 5 years have passed since last update.

Cloudfront:カスタムエラーページのキャッシュ時間を正確に理解する

Last updated at Posted at 2014-12-25

0.カスタムエラーページとは?

Cloudfrontとは?は今回省略します。

カスタムエラーページは、

オリジンから特定のHTTPステータスコードが返された時に、
Cloudfront側で任意のコンテンツをレスポンスでき、かつHTTPのステータスコードもいじることができる機能
例)503が返ってきた時にオリジナルのページをレスポンスし、ステータスコードを200(正常)で返す、など

です。

このカスタムエラーページも例外なくキャッシュ対象になるので、
それなりのキャッシュコントロールの考慮が必要なのですが、
正しい理解をしていないと誤った設定をすることになるので、書き留めておきます。

1.通常コンテンツのキャッシュ時間をおさらい

通常コンテンツのキャッシュ時間をコントロールするためには、Cloudfront側の[Beghavior]のminimum TTLで設定します。[Behavior]毎に設定するので、URLパターン別に設定可能です。

また、オリジンからのレスポンスヘッダーにcache-controlヘッダーが含まれない場合、CLoudfrontは24時間そのコンテンツをキャッシュしてしまうので、基本的にはオリジン側のキャッシュコントロールが必須になります。

詳細はAWSのドキュメント各種資料に解説がありますが、ざっくり以下のような動きになります。

       cache-control無し cache-control有り
minimum TTL <= 24H 24時間キャッシュ cache-controlと24Hの長い方キャッシュ
minimum TTL > 24H minimum TTLキャッシュ cache-controlとminimum TTLの長い方キャッシュ

 

2.カスタムエラーページの構成方法

例えばS3からカスタムエラーページのコンテンツを配信したい場合、以下の流れになります。
※S3にはコンテンツが配置されている前提です

①:[Origins]にS3を追加する
②:[Behavior]に対応するパスを追加する
③:[Error Pages]にカスタムエラーページ設定を行う

①:[Origins]にS3を追加

②:[Behavior]に対応するパスを追加

③:[Error Pages]にカスタムエラーページを設定

3.Error Caching Minimum TTLの挙動

[Error Pages]では、Error Caching Minimum TTLという設定があります。
こいつは、通常コンテンツの[Behavior]で設定するMinimum TTLとは少し意味合いが異なります。

Error Caching Minimum TTLは、
最初のエラーレスポンスから次回オリジンにアクセスするまでのCool down period的な意味
になります。

従って、オリジン側からのレスポンスヘッダーにCache-controlヘッダーが含まれていなくても、
Error Caching Minimum TTL経過後には再度オリジンにアクセスしにいってくれます。
つまり、エラーページ自体は[Behavior]の設定にならってCloudfrontにキャッシュされるのですが、
ちゃんとError Caching Minimum TTL経過後はオリジンにフェッチし、エラーが解消していれば正常コンテンツを応答することができるのです。
ここが、通常コンテンツとの差になります。

なお、DefaultのError Caching Minimum TTLは300(Seconds)になっていますので、
最初のエラーレスポンスから5分間はキャッシュされるけど、
5分経過後はオリジンにアクセスし、コンテンツの取得を試みる、という挙動になります。



■カスタムエラーページがCloudfrontによってキャッシュされている様子
(エラー発生中はキャッシュされるが、Error Caching Minimum TTL経過後はオリジンにアクセスされるので心配無用)

もちろん、この5分の間もキャッシュさせるかしないか、という議論もあると思うので、
キャッシュさせない、ということであればオリジンのcache-control考慮は必要になります。

4.まとめ

ユーザ側からは動作確認ベースでしか確認できないので、この仕様を知らないと、

あれ?Error Caching Minimum TTL=0なのにキャッシュしてる!
オリジンにcache-control設定いれないと!!!

となってしまうので、要注意ですね。
今回はカスタムエラーページをS3から配信する例だったので、簡単にcache-controlヘッダーを埋め込めますが、
複雑な構成になっているカスタムオリジンのWebサーバだったら、結構インパクトでますよね。
やっても実害はないですけど、楽できるところは楽していきましょう!!!

4
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
5