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]にカスタムエラーページ設定を行う
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サーバだったら、結構インパクトでますよね。
やっても実害はないですけど、楽できるところは楽していきましょう!!!