障害時の対応に付いて
AWS - Amazon CloudFront の障害に備えてフェイルオーバーを設定する
s3, MediaPackageをオリジンとして使った時
ウェブディストリビューションでの Amazon S3 オリジン、MediaPackage チャネル、およびカスタムオリジンの使用
TTLがどのように効くのか
【新機能】Amazon CloudFrontに「Maximum TTL / Default TTL」が設定できるようになりました！ ｜ Developers.IO
パスパターンはワイルドカード
このため、HLSを配信するCDNは様に設定しました。
/studio*-lq.m3u8
/studio*.m3u8
重要 エラーページについて
『どの程度エラーページを保持するべきか』という設定がある
エラーレスポンスのカスタマイズ - Amazon CloudFront
CloudFrontのエラーキャッシュのTTLを変更する - Qiita
カスタムオリジンの話 別ドメインをオリジンとする。大抵のサービスはこれなのではないか
カスタムオリジンの場合のリクエストとレスポンスの動作 - Amazon CloudFront
初期設定
参考 キャッシュしないCloudFrontを設置する | // sakura note
Minimum TTL / Maximum TTL の話 一覧がある
【新機能】Amazon CloudFrontに「Maximum TTL / Default TTL」が設定できるようになりました！ ｜ Developers.IO
「Mimimum TTL / Maximum TTLはヘッダより強い」
「ブラウザのキャッシュはヘッダが優先される」
「何も設定しなければDefault TTLの値になる」
くらいのざっくりで覚えておいて、実際に設定する際にこの記事を参考にして頂ければと思います。
CDNのレイテンシ比較
Is TLS Fast Yet? コアな人々が反応してる
Googleがテスト中のCDN「Google Cloud CDN」は、ベータ版で既に世界最速 - GIGAZINE
(APIではクッキー使わないと確定しているので、今回の件とは異なるが) クッキーを『Forward Cookies All』に設定しているとマズい
CloudFrontで「Forward Cookies」を「All」にしている時に注意すべき点 ｜ Developers.IO
CDNはエラーページもキャッシュする。404が発生してからファイルを置いてもキャッシュされた404のページが表示される
エラーページのキャッシュ時間
例えばオリジンサーバにファイルをアップロードする前に、CloudFrontのキャッシュサーバからアクセスした場合はどうなるでしょうか。 CloudFrontのエッジサーバはオリジンサーバにファイルを取得しようとしますが、オリジンサーバからは「404: NotFound」などのエラーレスポンスが返ってくるはずです。CloudFrontでは、エッジサーバでこれらエラーレスポンスをデフォルトで300秒（5分）キャッシュします。そのため、デフォルト状態ではオリジンサーバにファイルをアップロードする前にキャッシュサーバからアクセスしてしまった、などの場合は5分間はファイルにアクセスできない状態が続くことになります。
AWS再入門 Amazon CloudFront編 ｜ Developers.IO
ログは1時間程度のタイムラグがある
ログはS3に保存されます。リアルタイムではなく、1時間ほど集計に時間がかかることに注意してください。
http://dev.classmethod.jp/cloud/cm-advent-calendar-2015-aws-re-entering-cloudfront/
アクセス解析 傾向をつかむ( 下の方に紹介がある )
Amazon CloudFrontの強化されたアクセス分析機能を整理してみた ｜ Developers.IO
invalidationは60秒で行われるようになった
【朗報】Amazon CloudFrontのキャッシュ削除(Invalidation)が速くなりました【5秒で90%】 ｜ Developers.IO
mackerelプラグインある、と言っても、メトリクス取っても、あまりうれしくないかな、と、現状おもうので今はスルー
mackerel-agent-plugins/mackerel-plugin-aws-cloudfront at master · mackerelio/mackerel-agent-plugins
CloudFrontの冗長化
Amazon CloudFront の障害に備えてフェイルオーバーを設定する - Qiita
Route53のヘルスチェックの機能を用いて、切り替える。やり方としては、落ちたらオリジンを見るように設定するのが妥当か… 一瞬、『Cloudfrontが落ちたらAkamaiを見るように設定するか?』とも考えたが、『CDN間の異なる振る舞い』に引っかかるのは怖い。ので、APIに関しては『cloudfrontが落ちたらoriginを見る』のが妥当
翻って、ライブはどうか?これは『両方で実績がある』し『扱うのもAPIと異なり、変な状態でキャッシュしてしまう事が問題になる』割合が低い、のでAkamaiに自動的に切り替わる、という設定も技術的に可能ならありだと思う
( 既に設定ずみ、だと思う )cloudfrontを経由した時でも、nginxのログにはユーザのIPアドレスを残す
How to get the client IP when using CloudFront and nginx - Jayway
[HOWTO] Get real IP coming via AWS CloudFront and ELB to nginx – Medium
s3にコンテンツを置く、メリットとかステータスコードを変えるとか
CDNの使い方で『跡地だけs3に置いて、cloudfrontで経由させる』というテクニック。 nginxに大量に設定が残っているのはメンテしにくい
S3+CloudFrontだけでリダイレクト設定を作る - Qiita
CloudFrontをAmazon S3 オリジンサーバーからのリダイレクトでキャッシュさせない方法 - Qiita
ステータスコード 302だとNG, 307だと何故かokとのこと
参考
シンプルに作り方が載ってる Amazon CloudFrontをカスタムオリジンで使用する方法 | Lancork
VPCのNetwork ACLの変更が必要、との情報だった。凄く気になったが、結局、この方法は不要であった。この点、納得行かないので、一応、情報残しておく CloudFront最近の事例と間違った使い方
クラスメソッドは、『CDNオリジン用のサブドメインを切る』という運用のようだ ただし、レイヤーが一つ増えるというか、オリジン用のドメインが一つ増えて、構成が見えにくくなるので、ALBのドメインの設定でいけるのであれば、それで行きたい AWS WAFを使うためシステムにCloudFrontを導入した時の注意点まとめ ｜ Developers.IO なにか、オリジン用のサブドメインが必要な理由があるか、探したが見つからなかった
クラスメソッドで「オリジンもSSLだし、CloudFront->ALB間もインターネットなのでSSL化したい」という話 CloudFrontからカスタムオリジンまでの通信をHTTPS化する方法を2パターン ｜ Developers.IO