ソリューションアーキテクト対策_CloudFront篇

はじめに

試験勉強した際のメモを自分用に記事化。
内容は公式やBlack Beltの写経ですので目新しいことはありません

公式のご紹介

とはいえこの記事に迷い込んだ方もいると思いますのでご紹介です。

CloudFrontの料金ページ
https://aws.amazon.com/jp/cloudfront/pricing/

Origin Shieldの記事 by ClassMethod
https://dev.classmethod.jp/articles/amazon-cloudfront-support-cache-layer-origin-shield/

CloudFrontの料金

概要

オンデマンド料金の場合、以下の課金が発生する。

・エッジロケーションからのデータ転送(out)
インターネットへのリージョンデータ転送(out)、オリジンへのリージョン内データ転送(out)も含まれる。

・HTTP, HTTPSリクエスト(リクエストが行われた地域も含む)によるトラフィック

・トラフックの分散地域
リージョンやエッジロケーションの地理的な場所によってAWSのコストが少ない場所では安価になる。

専用IPカスタムSSL

独自SSL証明書機能の専用IPバージョンを使用する、1つ以上のCloudFrontディストリビューション(※)に関連づけられた各独自SSL証明書ごとに料金が発生する。
(※)EC2やRDSをインスタンスと呼ぶように、CloudFrontはディストリビューションと呼ぶ

Origin Schield

オリジンの前段に置くキャッシュレイヤのこと。
使用すると、キャッシュを利用してオリジンへのリクエストや、オリジンからのアウトバウンドトラフィックをOrigin Shieldに集約することができる。

また、Origin Schield以外にも以下のキャッシュレイヤが存在する。
(Origin Schieldはよりオリジン寄りの配置)

・200を超えるPoints of presence(POP)。エッジロケーションのこと

・10を超えるリージョナルエッジキャッシュ

CloudFrontあれこれ

CloudFrontのコンテンツのURLを制限したい

AWS WAFを利用してrefer(参照)制限をする。
WAFはCloudFrontに転送されるhttp, httpsリクエストをモニタリングして、コンテンツへのアクセスを制御可能にするウェブアプリケーションFW。

S3のオブジェクトのURLに対して署名付きCookieや署名付きURLで制限することも可能であるが、どちらもURL自体は利用できてしまう懸念あり。

CloudFrontのプライベートメディアファイルへのアクセス方法

• 署名付きURL
  署名付きのURLからのみアクセスさせる。ただし現在のオブジェクトURLが変わる。
  ユーザーがCookiesをサポートしていないクライアントを使っている場合に署名付きURLを使用する。

• 署名付きCookies
  署名付きCookiesからのみアクセスさせる。現在のオブジェクトURLは変わらない。

CloudFrontのオリジンサーバに頻繁にアクセスするときは

Cache-Controlのmax-ageディレクティブが低い値に設定されているのが原因。
なので数値を上げる。

Cache-ControlとディレクティブはCloudFront固有のパラメータではない。
CloudFlareのページがめっちゃわかりやすい。
https://www.cloudflare.com/ja-jp/learning/cdn/glossary/what-is-cache-control/

CloudFrontのディストリビューションとは

噛み砕くとCloudFrontを実現する際の、構成設定のかたまりをディストリビューションと言う。たぶん。
設定項目はオリジンとかアクセス制限とかセキュリティをどうするか、とか。
公式がわかりやすい。
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/distribution-overview.html

Route53とCloudFrontのフェールオーバー

Route53ではフェールオーバールーティングが利用できる。
ヘルスチェックに失敗したらプライマリサーバからセカンダリサーバに切り替える。クロスリージョンで構成が可能。

CloudFrontはCloudFrontディストリビューションでフェールオーバーオプションが選択できる。

その場合はオリジンサーバをプライマリ/セカンダリでグループ化し、httpエラーコードがレスポンスされた場合はセカンダリサーバへ自動で切り替わるようにする。

CloudFrontはオンプレミス環境でも利用可能

なので既存インフラ環境を大幅に変更せずにパフォーマンスを改善することが可能。
オリジンサーバはAWS、オンプレどちらでも良い。
ディストリビューションのカスタムオリジン設定でオンプレのロードバランサを設定することができる。
なのでオンプレ環境でもCloudFrontを利用してサイトフェールオーバーやDDoS攻撃から保護し、ウェブサイトの可用性を向上することが可能である。

CloudFrontを経由した特定ユーザー以外からのアクセスを拒否したい場合は

OAI(Original Access Identity)と呼ばれる特別なCloudFrontユーザーを作成し、ディストリビューションに紐づける。
その後CloudFrontがOAIを使用してバケット内のファイルにアクセスしてユーザーに提供できるように、S3バケットのアクセス許可を設定する。
これでユーザーがバケットへのダイレクトURLを使って、そこにあるファイルにアクセスできないようになる。

CloudFrontの用語

• カスタムヘッダー
  カスタムオリジンへのアクセスを制限する仕組み。
  これは別にCloudFrontの用語ではないと思うw

• ビューワープロトコルポリシー
  ビューワーがCloudFrontにアクセスするのにHTTPSを使用しなければならないようにディストリビューションを設定。

• オリジンプロトコルポリシー
  CloudFrontがビューワーと同じプロトコルを使用してリクエストをオリジンに転送するように、ディストリビューションを設定。

多言語Webサイトで特定サイトにルーティングしたい時は

日本語のサイトが表示されるためにCloudFront側で設定を行う時は、クエリ文字列パラメータを設定する。
クエリ文字列。。？てなるがw、？の後に追加されるパラメータ。以下は例！

https:xxxxx.net/images/image.jpg?color=red&size=large

color=red&size=largeがクエリ文字列。
color=red, size=largeがパラメータ。

CloudFrontはクエリ文字列を使用してオリジンに一定の情報を送信して、クエリ文字に応じて処理を変更することができる。
なのでこのような設定を行うことで、どのコンテンツにキャッシュするかを選択できる。

ユーザーが選択した言語に基づくクエリ文字列パラメータが含まれるので、日本語ユーザー(が投げたリクエストに含まれるクエリ文字列パラメータ)は日本語サイトを閲覧できる。

おわりに

引き続き追記します！

簡単ですが以上です。