CDNとしてコンテンツをキャッシュできる。全世界にキャッシュを持つので、キャッシュクリアや設定の変更反映には時間がかかるので注意。またCloudFrontにキャッシュさせるとブラウザキャッシュにも入ってしまうので、なんかおかしいなと思ったらブラウザのキャッシュクリアも試してみること。設定の変更には時間がかかるので検証する場合はまとめて&気長に!
Distribution | CloudFrontの一番大きな管理単位 |
Origin | Distributionに複数配置可能。次のBehaviorsにて/path以下を別ドメインに割り当てるなんてことも可能。 |
Behaviors | パスに対してどのoriginを割り当てるかの設定。クエリーストリングを渡さないのがデフォルトなので注意 |
C Name | ランダムなxxx.cloudfront.netだとアクセスしづらいのでCNameを設定できるが正規のSSL証明書が必須となった |
何もしないとデフォルトは24時間キャッシュ。originサーバーでのCacheヘッダーを参照するようにするとその通りに動いてくれる。no-cacheやprivateを入れていればキャッシュしない。Behaviroの設定でカスタマイズすることもできるのでurlパス単位で設定できる。
PHPだと以下のキャッシュコントロールを入れるとキャッシュされなかった。
<?php header("Cache-Control: no-cache"); header("Cache-Control: private"); date_default_timezone_set('JST'); echo date(DATE_RFC2822); echo date("Y/m/d G:i:s");
キャッシュがないとき | X-Cache: Miss from cloudfront |
キャッシュ有通常ページ | X-Cache: Hit from cloudfront |
キャッシュ有かつエラーページ | X-Cache: Error from cloudfront |
キャッシュ無効化は1000件までは無料。ワイルドカードでも良いので消したいフォルダの上位で指定するのが無駄なくて良い。無効化は各エッジサーバーに伝播するのに、結構時間がかかるのとObjectの数が3000個らしいので頻繁に変わるところは適宜キャッシュコントロールを付けるのがおすすめ。
年1-2回レベルで発生しているらしいので、落ちた時の対策を考えておく必要がある。
RewriteEngine On RewriteCond %{HTTP_USER_AGENT} !CloudFront RewriteCond %{REQUEST_METHOD} =GET RewriteRule ^(.*)$ http://%1クラウドフロントのURL$1 [R=301,L,NE]
最後のNEはURLエンコーディングをしないということで、これを入れないと検索できない。
もともとno-cacheなので大して負荷軽減にはなってないぞ。
RewriteEngine on RewriteCond %{HTTP_USER_AGENT} !CloudFront RewriteCond %{QUERY_STRING} !(cmd=edit|plugin=newpage|その他除外したいクエリー) RewriteCond %{REQUEST_METHOD} =GET RewriteRule ^(.*)$ http://%1クラウドフロントのURL$1 [R=301,L,NE]
同じくNE必須。
ログを出力を有効にすると約10分毎にログがS3に生成される。PUTが多くなるのでS3の無料枠をはみ出すことになるので本格運用する場合はコストに含めておくべき。
同じcnameは同時に存在できないので、移行元で別名に変更後、わりとすぐに別名で作成できる。
"だがうまくいかない"