【メモ】 CloudFrontについて調べた
主な特徴
CloudFrontとはCDN（コンテンツデリバリーネットワーク）で、
エンドユーザーにコンテンツをより低いレイテンシー（応答までの時間）で届けるサービス
CDNのメリットとしてCF側にキャッシュを貯めておくことができる
レスポンスが早く、レイテンシーが低くコンテンツが返せる
オリジンサーバの負荷低減（リソース節約）になる
グローバルエッジネットワーク
400 以上のエッジロケーションと 13 のリージョン別中間層キャッシュからなる、グローバルなネットワークを展開
日本には東京20, 大阪に7のエッジロケーションがある。
リージョン別エッジキャッシュ
（リソースを提供するサーバをオリジンと呼ぶ）
edge locationだけでなく、regional edge cacheと呼ばれる層も存在する。
400以上あるedge locationsはregional edge cacheからコンテンツが配られる。それによってオリジンサーバー側が全てコンテンツを配る必要がなく、効率的にコンテンツ配信が出来る。
Origin Shield
regional edge cacheを拡張したもの。別のリージョンからリクエストが来る場合のパフォーマンス向上。
Original Shieldを使わない場合、海外のregional edge cacheから直接オリジンサーバにリクエストが来るため負荷になりやすい。
オリジンサーバと同じリージョンにregional edge cacheと同く仕組みをOriginal Shieldと呼ぶ。海外リージョンから来たリクエストもOrigin Shieldを経由することができ、リクエストの削減・コスト最適化に寄与する。
Automatic Flash Crowd Protection
通常エッジにコンテンツキャッシュがない場合、ユーザー側のリクエストはすべてオリジンにもリクエストが来てしまう。
同時に大量リクエストが発生した場合（Flash Cloud）最初のリクエストのみをオリジンに送る負荷軽減する仕組み。
キャッシュコントロールとポリシー
CloudFrontの設定
ディストリビューション（カスタムドメイン、SSL、TLSなどの証明書紐付け、ログ）
Behavior
パスパターンに合わせてどのオリジンサーバに紐づけるのか設定
ex: image/*
キャッシュポリシー
オリジンリクエストポリシー
Origin
どのオリジンサーバにCloudFrontを紐づけるのか設定
ex: {bucket-name}.s3.{region}.amazonaws.com
（この場合S３がオリジンサーバになる）
コンテンツを適宜キャッシュしたり、Origin request policyを使ってedge側でwebに対する攻撃を防御することも可能
Behavior
キャッシュコントロール機能
キャッシュヒット率を向上させる
GET, HEAD, OPTIONのリクエストがキャッシュ対象
単一リクエストのキャッシングは最大30GB
同一のコンテンツを返すためにキャッシュキーにできる値は、URL、Cache Policyで有効化したHTTPヘッダー、Cookieパラメータが完全一致した場合、キャッシュが再利用される
キャッシュキーを設定すると、設定したキーのみオリジンに送られる仕組みだった
→これだとキャッシュキーにはしたくないがオリジンには送りたいニーズがあったので2020年からポリシーが分離した
キャッシュポリシー
consoleから設定が可能
どの値をキャッシュキーにしてcache controlするか
オリジンリクエストポリシー
クライアントからリクエストした値のうちどれを転送するのか設定できる
キャッシュファイルの無効化(Invalidation)
ワイルドカードを使って無効化パスを指定する
キャッシュファイルの無効リクエストは有償なので、日々の業務においてはCache Policyの各TTLや、オリジンで指定するCache-Controlレスポンスヘッダで適切なキャッシュ期間を設定する
最初の1000パスまでは追加料金なしでそれ以降は従量制
Origin Group
オリジンフェイルオーバー機能
primary, secondaryオリジンの2つのオリジングループを作成することで、400, 500系エラーが発生した場合secondaryオリジンにroutingすることができる機能
CloudFront Header
ユーザーがCloudFrontを経由してリクエストされた場合、様々のヘッダを付与した状態でオリジンにリクエストすることが可能。
オリジンリクエストポリシーで追加可能
デバイス情報
スマホからのリクエストなのか分かる
タイムゾーン
都市情報
クライアント側のIP、ポートが載ったheader
リクエストしたクライアントのIPアドレスと接続ポート情報を含むCloudFront-Viewer-Addressヘッダが提供される
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/adding-response-headers.html
Server Timingヘッダ
オリジン間のパフォーマンス計測ができる
HTTPヘッダでメタデータを提供することでブラウザから閲覧することができる
Server Timingヘッダを利用することでユーザーリクエストのトランザクション全体のメトリクスを確認することができる
レスポンスヘッダポリシーから設定が可能
レスポンスヘッダポリシー
CloudFront→ポリシー→レスポンスヘッダー→レスポンスヘッダーポリシーを作成 から設定可能
CORSヘッダやセキュリティ関連のヘッダ、任意のカスタムヘッダを定義
CloudFrontのEdgeのコンテンツ圧縮機能
Cache policyのGzip, Brotli（ブレトリ）を有効
BefaviorのCompress Objects Automaticallyを有効
リクエストヘッダにAccept Encoding:gzip,brが指定されていて、オリジンがレスポンス圧縮に対応していない場合はCloudFrontエッジでGzip、Brotli圧縮をおこなって配信
これによりキャッシュがある場合は圧縮されたキャッシュを返すことができる
Lambda Edge
リクエストorレスポンスを受け取る前と後をトリガーにしてAWS Lambdaを実行することができる
Lambda Edgeではファイルシステムのアクセスもできるので、SSRや画像コンテンツのリクエスト前にクエリ文字列に合わせて画像フォーマットを変更したりなど、複雑な処理が可能。
CloudFront Functions
Edge location側でプログラムを実行することができる。（1ミリ秒未満）
Lambda Edgeと違いユーザーにより近いEdge locationで処理を実行することができる。
オリジンリクエスト、オリジンレスポンのトリガーは前項のLambda Edgeで実行する。
Lambda Edgeと異なり外部へのリクエスト、ファイルシステムへのアクセスができない
実行環境は軽量なjavascriptのみ
具体的には簡単な認証（basic 認証）やurl rewriteやヘッダの操作など
Cloud Frontのビヘイビアから設定可能
エラーレスポンスのカスタマイズ
4xx, 5xxエラーの場合はレスポンスページを別のオリジンに指定することができる
GEO制限
特定の国のユーザーに対するアクセス制御が可能
有効にすることで、日本からのアクセスのみ許可する設定などが可能
レポート・モニタリング
ログやメトリクスを可視化することができる
CloudWatchを参考に閾値を設けて障害や異常検知を行える
Amazon Athena(SQLで分析できるツール)+Amazon QuickSight（グラフ）を使ってデータを可視化することもできる。
リアルタイムログ
edge locationからログを集約することで1分以内のログ収集が可能
Kinesis Data Streamを経由する
セキュリティポリシー
ViewerとCloudFront間のSSL,TLSの組み合わせを選択することができる
オリジンサーバの保護
クライアントからCloudFrontを経由せずにオリジンサーバにアクセスされることを防ぐ
S3であればOAI（origin access identify）が使えるがカスタムオリジンサーバはヘッダやIPアドレスで制限するのは運用が大変だった
→CloudFrontのManaged Prefix Listを使う
VPNセキュリティグループルールでIPアドレスを制御することができる
フィールドレベル暗号化
POSTリクエストの特定のデータフィールドを特定のアプリケーションのみアクセスできるように保護できる
public keyを使って複合化できる。
クレジットカード番号情報をユーザー情報と合わせてサーバーに送る場合、データベースに生のまま保存したくない時に使える。
AWS Shield
DDoS攻撃対策, WAFと連携することができる
CDNに必要なセキュリティ
ユーザー → CDN → オリジン（S3やApplication Load Balancerなど）
関連する脅威
DDOS攻撃
大量アクセスすることでサービスダウンされる
Bot
スクレイパーなど悪質なもの
HTTP攻撃
XSS, SQLiなど脆弱性を攻撃
認証しないと閲覧できないコンテンツを盗むもの
AWS WAF
Web application firewall
DDos, HTTP攻撃からの保護
通信内容を検査して不正なアクセスを遮断するセキュリティ対策
Webアプリケーションの脆弱性を悪用した攻撃からwebアプリケーションを保護
悪意のあるリクエストを検知・ブロック
カスタムルールの適用
モニタリング
どのくらいブロックしたのか等
cloud watchと組み合わせて利用
Web ACL
Rule → Actionを設定することができる
ルールに対してブロックするのか検知のみするのか等の設定が可能
DDos攻撃に有効なのがレートベースルール。
5分間あたりの同一IPからのリクエスト数が設定された閾値を超過したらBlock or Countする
AWS Managed Rules for AWS WAF
Ruleをセットしていくのを個別で作成して運用すると大変なので、事前に構築済みのルールセットを使用することができる
一部のルールを除いて追加必要なしで利用することが出来る
内容が最新の攻撃手法に合わせてアップデートされる
Bot Controlルールグループ
ボットと判断されるトラフィックを検知して、それに基づいたアクションを指定することができるグループ
リクエストの内容からボットの種別（search engineなど）をラベル情報として付与
ラベルを元に処理を場合分けすることが可能
Cloud FrontにきたリクエストをWAFが検査
スコープダウンステートメントを利用して特定のURLに対して適用することも可能
Custom Response
Blockした際に403以外のカスタムレスポンスを返却することができる
実践的な対策としては、
国内経由と海外経由で別のレートベースルールを適用する
DDoS攻撃は海外経由が多い傾向
国内からのアクセスは緩めにして、海外からのアクセスは厳しめにすることが可能
レートベースルールBlock時にあえて200status codeでレスポンス
対策されたと検知されるとIPアドレスを変えながら繰り返しDDoS攻撃してくるパターンの対策ができる
カスタムレスポンスで4xx系ではなく2xx系レスポンスして対策
サーチエンジンなどの悪意のないボットのクロールレートを調整
悪意のないボットアクセスでも頻度によっては負荷を与えることがある
頻度が高すぎる場合に429（Too Many Request）レスポンスを返す
良性のボットの多くはクロール先からのレスポンスに従ってクロールレートを調整するメカニズムが存在する
AWS Shield Advanced
DDoSは複数のリソースからターゲットに対して攻撃してくる。（1つのリソースからの攻撃はゆるやかでも、多くの複数リソースから攻撃される場合がある）レートベースルールだと不安な場合に検討する。
AWS Shield Standard
自動的に適用されている
一般的なDDoS攻撃に対して自動的に緩和
AWS Shield Advanced
大規模かつ高度な攻撃に備える
Shieldレスポンスチームという年中無休の専門チームが支援
プライベートコンテンツの保護
動画、音楽など購入者のみ閲覧
署名付きURL, 署名付きCookieを利用
Cloud FrontのBehaviorから「ビューワーのアクセスを制限する」を有効にすることで署名のないアクセスを全てブロックすることができる（URLもしくはCookieで指定）
クライアント側から認証リクエストを送る、署名付きのURLまたはCookieを生成してクライアントにレスポンスする→認証情報を載せた状態でCloudFrontにアクセスすることで署名を検証して問題がなければコンテンツを返却するフローが可能。
単一コンテンツは署名付きURL、複数コンテンツの場合は署名付きCookieが推奨されている。
スキ頂けると嬉しいです〜