Amazon CloudFrontでデフォルトのエラーキャッシュ時間が10秒になっていたので確認してみた
はじめに
清水です。AWSが提供する高速・高パフォーマンスなコンテンツ配信サービス(CDN)であるAmazon CloudFront、オリジンサーバがHTTP 4XXまたは5XXのステータスコードを返した際のデフォルトキャッシュ時間（エラーキャッシュ最小TTL/Error Caching Minimum TTLのデフォルト値）が10秒になっていました。これまで長らくエラーキャッシュ最小TTLはデフォルトで5分だったと（個人的に）記憶しています。それがいつの間にか1分になっており、さらに現在は10秒になっていました。（10秒になったのは2020/09ごろのようです。）これらをドキュメントなどから確認、また実際にデフォルト値10秒のエラーキャッシュ最小TTLの挙動を確認してみました。
エラーキャッシュ最小TTLのデフォルト値をドキュメントベースで確認してみる
デフォルト値が300秒（5分）のころ
CloudFrontのエラーキャッシュ最小TTL(Error Caching Minimum TTL)のデフォルト値、例えばCloudFrontディストリビューションを作成して何らかのファイルにアクセス、オリジンサーバ側でそのファイルを用意していないとHTTPステータスコード404 Not Foundが返ります。オリジンサーバ側でファイルを準備して再度アクセスしても、このエラーキャッシュ最小TTLの間はCloudFront側で404の状態でファイル（オブジェクト）をキャッシュするので、CloudFront経由ではファイルの更新はされず、CloudFrontからのキャッシュが返ります。その他、4XXや5XXでも同様の挙動になります。
このエラーキャッシュ最小TTL、私が記憶している限り（おそらく2013年や2014年ごろから）、デフォルトで5分（300秒）であったかと思います。手元の資料ですぐに確認できたものとして、CloudFront開発者ガイドAPI Version 2014-01-31（保存時のファイル名称から2015/12/01ごろのもの）があります。こちらにはデフォルトで5分の記載がありました。
また以下のブログエントリ（2015/08/15）でも「デフォルトで5分間のキャッシュ」という記載が冒頭にあります。
デフォルト値が60秒（1分）のころ
ということで、デフォルト状態のCloudFrontディストリビューションではエラーページのキャッシュ時間は5分（300秒）と思っていたのですが、先ほどファイルを作成し忘れて404 Not Foundが発生、その後ファイルを作成してダメもとでアクセスしたところファイルが更新されていました。エラーページがキャッシュされていない？（5分間はキャッシュされるはずなのに、キャッシュがみれない）ことにおや？と思い、ドキュメント（開発者ガイド）を確認してみます。
以下のように、エラーキャッシュ最小TTLがデフォルトで1分になっていることが確認できました。
現状ではデフォルト値は10秒
しかし感覚として、1分たたずにアクセスしても404 Not Foundは返らずに、キャッシュではなく更新されたページ内容が返ります。またまたおや？と思ったのですが、今度はドキュメント（開発者ガイド）を英語版にしてみます。
10 seconds by default、エラーキャッシュ最小TTLが10秒になったことが記載されていますね！
おそらく、現時点（2020/10/28）の段階では日本語ドキュメントには反映されていない状況かと思います。GitHubで履歴を確認すると、以下の通り2020/09/22にドキュメントの更新がされていたことがわかります。
実際にエラーキャッシュ最小TTLのデフォルト値が10秒になったことを確認してみる
ドキュメントベースでの確認ができました。続いて実際にエラーキャッシュ最小TTLのデフォルト値が10秒になっていることを確認してみます。CloudFrontディストリビューションをオリジンサーバのみ指定、他はデフォルトの状態で作成しました。オリジンサーバではApache＋PHPが稼働している状況です。この状況下で、(1) 存在しないファイルにアクセス、(2) サーバ側でファイルを作成、(3) 作成したファイルにアクセス、(4) 10秒待機してから、(5) 再度ファイルにアクセス、ということをしてみます。(1)では404 Not Foundが返ります。(3)でもキャッシュのため404 Not Foundが返ります。(5)ではエラーキャッシュ最小TTLのデフォルト値である10秒を経過しているので、ファイルが正常に取得でき、200 OKのステータスコードが返るはずです。
$ date; \ curl -I http://d1234567890.cloudfront.net/test.html; \ touch test.html; \ date; \ curl -I http://d1234567890.cloudfront.net/test.html; \ sleep 10; \ date; \ curl -I http://d1234567890.cloudfront.net/test.html 2020年 10月 28日 水曜日 13:31:57 UTC HTTP/1.1 404 Not Found Content-Type: text/html; charset=iso-8859-1 Connection: keep-alive Date: Wed, 28 Oct 2020 13:31:57 GMT Server: Apache/2.4.27 (Amazon) PHP/5.6.35 X-Cache: Error from cloudfront Via: 1.1 XXXXXXXXXXXXXXXX7da4d0d445da3deb.cloudfront.net (CloudFront) X-Amz-Cf-Pop: NRT12-C5 X-Amz-Cf-Id: XXXXXXXXXXXXXXXX9Mhci2-9vJYwXFV6VyBIvleoMhayU6xJglUBxA== 2020年 10月 28日 水曜日 13:31:57 UTC HTTP/1.1 404 Not Found Content-Type: text/html; charset=iso-8859-1 Connection: keep-alive Date: Wed, 28 Oct 2020 13:31:57 GMT Server: Apache/2.4.27 (Amazon) PHP/5.6.35 X-Cache: Error from cloudfront Via: 1.1 XXXXXXXXXXXXXXXX58885186f21c18d2.cloudfront.net (CloudFront) X-Amz-Cf-Pop: NRT12-C5 X-Amz-Cf-Id: XXXXXXXXXXXXXXXXm4u2pS1C7G2Gatmurwcqhc8Tj62ZIB5aNI4Sgw== 2020年 10月 28日 水曜日 13:32:07 UTC HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Connection: keep-alive Date: Wed, 28 Oct 2020 13:32:08 GMT Server: Apache/2.4.27 (Amazon) PHP/5.6.35 Last-Modified: Wed, 28 Oct 2020 13:31:57 GMT ETag: "XXXXXXXX00764b1" Accept-Ranges: bytes X-Cache: Miss from cloudfront Via: 1.1 XXXXXXXXXXXXXXXX0151549d009005d8.cloudfront.net (CloudFront) X-Amz-Cf-Pop: NRT12-C5 X-Amz-Cf-Id: XXXXXXXXXXXXXXXXbwGPxuDBimAJcMZVnneaxBO_CaGgvWKMxk8N3w==
10秒後のアクセスで、更新したファイル（オブジェクト）が取得でき、200 OKが返りました。
まとめ
Amazon CloudFrontのエラーキャッシュ最小TTL(Error Caching Minimum TTL)のデフォルト値が10秒になっていることを確認してみました。これまでの（個人的に思っていた）5分だと少し長いなと思うことがあり、例えば1分や1秒などそれぞれ環境に適した値に変更していました。（エントリ本文でも確認した通り、いつの間にか1分にはなっていたのですが。）最新のデフォルト値は10秒ということで、もちろん要件にもよりますが、デフォル値でキャッシュ時間が長いと思うことは少なくなるのではないのでしょうか。逆に、オリジンサーバ側が高負荷でダウン、5XXのステータスコードを返した場合などにAutoScalingでスケールアウトするまでの時間をCloudFrontのキャッシュ時間でカバーする、などの場合はデフォルト値ではなく適した値を設定するようにしましょう。
![[アップデート] Application Load Balancer コンソールから CloudFront + WAF を統合出来るようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-f650a3011b384cc3781610c17755bc71/c37c67c9bc40b72e6dce1a49f4153283/elastic-load-balancing)
