AWS/CloudFront の履歴(No.24)

概要†

CDNとしてコンテンツをキャッシュできる。全世界にキャッシュを持つので、キャッシュクリアや設定の変更反映には時間がかかるので注意。またCloudFrontにキャッシュさせるとブラウザキャッシュにも入ってしまうので、なんかおかしいなと思ったらブラウザのキャッシュクリアも試してみること。設定の変更には時間がかかるので検証する場合はまとめて＆気長に！

↑

CloudFront 用語集†

Distribution	CloudFrontの一番大きな管理単位
Origin	Distributionに複数配置可能。次のBehaviorsにて/path以下を別ドメインに割り当てるなんてことも可能。
Behaviors	パスに対してどのoriginを割り当てるかの設定。path/*をどのOriginにするかを指定する。クエリーストリングを渡さないのがデフォルトなので注意。パスはそのままoriginにわたるので/hogeだとorigin/hogeになる
C Name	ランダムなxxx.cloudfront.netだとアクセスしづらいのでCNameを設定できるが正規のSSL証明書が必須となった

↑

SSLでCNAMEを使う†

ヴァージニアのACMに独自証明書をインポートする。

https://recipe.kc-cloud.jp/archives/11408

terraform

https://qiita.com/tos-miyake/items/f0e5f28f2a69e4d39422

https://tech.torico-corp.com/blog/aws-cloudfront-acm-ssl-sertificate/

↑

キャッシュについて†

何もしないとデフォルトは２４時間キャッシュ。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");

↑

QueryString Forwarding and Caching†

None	クエリーストリング無視。完全静的ページ向け
Forward all, chache based on whitelist	クエリーストリングで指定パラメータ以外はキャッシュする。a=xxx&b=123でaが指定されている場合bが変わってもa=xxxのページキャッシュがかえる
Forward all, cache based on all	クエリーストリング列も含めてキャッシュ対象

↑

キャッシュかどうかの見分け方†

ヘッダーにX-Cacheが付与されている。

キャッシュがないとき	X-Cache: Miss from cloudfront
キャッシュ有通常ページ	X-Cache: Hit from cloudfront
キャッシュ有かつエラーページ	X-Cache: Error from cloudfront

↑

IP制限†

Terraform使ってやるといい https://www.terraform.io/docs/providers/aws/d/ip_ranges.html

↑

キャッシュ無効化†

キャッシュ無効化は１０００件までは無料。ワイルドカードでも良いので消したいフォルダの上位で指定するのが無駄なくて良い。無効化は各エッジサーバーに伝播するのに、結構時間がかかるのとObjectの数が3000個らしいので頻繁に変わるところは適宜キャッシュコントロールを付けるのがおすすめ。

↑

Originの制限†

CloudFront→OriginでSSLはダメ？(toolsがダメだったがWWWはOKなので別の原因だろう)
Diguest認証外したらOK！

↑

Lambda@Edge†

仕掛けるタイミングはViewer Request/Origin Request/Origin Response/Viewer Responseで４つ。それぞれ一つだけであるが、behaviorごとに設定できる！

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-edge.html

↑

注意点†

一度紐づけると各リージョンにreplicaが作成されて、コンソールから削除はできない。CloudFrontからの紐付けが外れると数時間で消える。

↑

ARN†

バージョン付きARNじゃないとダメで、どこで取得できるのか？ARN取得して:バージョン番号を付与する。qualified_arnがそれ

default_cache_behavior {
# 中略
   # lambda@Edge
   lambda_function_association {
     event_type = "viewer-request"
     lambda_arn = aws_lambda_function.redirect.qualified_arn
   }
}

↑

必要な権限†

assume role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": ["lambda.amazonaws.com", "edgelambda.amazonaws.com"]
      },
      "Effect": "Allow"
    }
  ]
}

以下の管理ポリシーはDocumentには記載があるが実際には付与しないでもOKだった。（付与したらエラー）

AWSServiceRoleForLambdaReplicator
AWSServiceRoleForCloudFrontLogger

↑

Behaivor†

上から順番に一致なので、より細かいものを上に持ってくるべし

これだとhoge/mogeは一つ目にマッチしてしまうので

hoge/*
hoge/moge/*

逆にする

hoge/moge/*
hoge/*

↑

エラーページ†

↑

CloudFrondの障害など†

年1－2回レベルで発生しているらしいので、落ちた時の対策を考えておく必要がある。

↑

CloudFront用のrewrite設定†

↑

Wordpress†

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !CloudFront
RewriteCond %{REQUEST_METHOD} =GET
RewriteRule ^(.*)$ http://%1クラウドフロントのURL$1 [R=301,L,NE]

最後のNEはURLエンコーディングをしないということで、これを入れないと検索できない。

↑

pukiwiki†

もともと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の無料枠をはみ出すことになるので本格運用する場合はコストに含めておくべき。

↑

CloudFront移行†

同じcnameは同時に存在できないので、移行元で別名に変更後、わりとすぐに別名で作成できる。

↑

S3連携†

CloudFrontからのみアクセス可能にするためにはOAIを作成後、そのUSER IDをS3のポリシーに設定。Update Bucket policyをすると該当S3のバケットポリシーを許可してくれる。

"だがうまくいかない"

OriginAccessIdentityを作成後に該当バケットのバケットポリシーを見ると、アクセス許可が入っているはず。

{
   "Version": "2008-10-17",
   "Id": "PolicyForCloudFrontPrivateContent",
   "Statement": [
       {
           "Sid": "1",
           "Effect": "Allow",
           "Principal": {
               "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity XXXXXX"
           },
           "Action": "s3:GetObject",
           "Resource": "arn:aws:s3:::アクセスさせたいバケット名称/*"
       }
   ]
}

↑

S3連携でDirectory Index実現†

CloudFrontはDefault Root Objectが指定できるがドメイン直下のみ
S3もIndex.htmlなどの設定ができるが、S3直接アクセスのみ(CloudFront経由だと機能しない)

Lambda@Edgeのoriginトリガー(cache missの時に動く、/をindex.htmlにするだけであればこれで十分)

Counter: 4054, today: 1, yesterday: 1