![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
CDNとしてコンテンツをキャッシュできる。全世界にキャッシュを持つので、キャッシュクリアや設定の変更反映には時間がかかるので注意。またCloudFrontにキャッシュさせるとブラウザキャッシュにも入ってしまうので、なんかおかしいなと思ったらブラウザのキャッシュクリアも試してみること。設定の変更には時間がかかるので検証する場合はまとめて＆気長に！
| Distribution | CloudFrontの一番大きな管理単位 |
| Origin | Distributionに複数配置可能。次のBehaviorsにて/path以下を別ドメインに割り当てるなんてことも可能。 |
| Behaviors | パスに対してどのoriginを割り当てるかの設定。path/*をどのOriginにするかを指定する。クエリーストリングを渡さないのがデフォルトなので注意。パスはそのままoriginにわたるので/hogeだとorigin/hogeになる |
| C Name | ランダムなxxx.cloudfront.netだとアクセスしづらいのでCNameを設定できるが正規のSSL証明書が必須となった |
何もしないとデフォルトは２４時間キャッシュ。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");
| None | クエリーストリング無視。完全静的ページ向け |
| Forward all, chache based on whitelist | クエリーストリングで指定パラメータ以外はキャッシュする。a=xxx&b=123でaが指定されている場合bが変わってもa=xxxのページキャッシュがかえる |
| Forward all, cache based on all | クエリーストリング列も含めてキャッシュ対象 |
| キャッシュがないとき | X-Cache: Miss from cloudfront |
| キャッシュ有通常ページ | X-Cache: Hit from cloudfront |
| キャッシュ有かつエラーページ | X-Cache: Error from cloudfront |
キャッシュ無効化は１０００件までは無料。ワイルドカードでも良いので消したいフォルダの上位で指定するのが無駄なくて良い。無効化は各エッジサーバーに伝播するのに、結構時間がかかるのとObjectの数が3000個らしいので頻繁に変わるところは適宜キャッシュコントロールを付けるのがおすすめ。
仕掛けるタイミングはViewer Request/Origin Request/Origin Response/Viewer Responseで４つ。それぞれ一つだけであるが、behaviorごとに設定できる！
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-edge.html
default_cache_behavior {
# 中略
# lambda@Edge
lambda_function_association {
event_type = "viewer-request"
lambda_arn = aws_lambda_function.redirect.qualified_arn
}
}
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "sts:AssumeRole",
"Principal": {
"Service": ["lambda.amazonaws.com", "edgelambda.amazonaws.com"]
},
"Effect": "Allow"
}
]
}
AWSServiceRoleForLambdaReplicator AWSServiceRoleForCloudFrontLogger
上から順番に一致なので、より細かいものを上に持ってくるべし
hoge/* hoge/moge/*
hoge/moge/* hoge/*
年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は同時に存在できないので、移行元で別名に変更後、わりとすぐに別名で作成できる。
"だがうまくいかない"
Lambda@Edgeのoriginトリガー(cache missの時に動く、/をindex.htmlにするだけであればこれで十分)
