MENU
AWSを中心としたクラウドインフラ技術サイト
  1. ホーム
  2. AWS
  3. Amazon CloudFront

Amazon CloudFront

AWS AWS認定試験

目次

CloudFront の特徴

  • データ、動画、アプリケーション、API を低レイテンシーの高速転送により視聴者に安全に配信する高速コンテンツ配信ネットワーク (CDN) サービスです。
  • WEBアプリケーションでグローバルな高速な配信処理を達成することができます。
  • AWS WAF を利用して CloudFront に転送される HTTP/HTTPS リクエストを監視することができます。
  • CloudFront には AWS Shield Standard が組み込まれているので、常時 DDoS 攻撃を防御しています。
  • CloudFront では、代替ドメイン名 (CNAME とも呼ばれる) を使用すると、CloudFront によってディストリビューションに割り当てられたドメイン名ではなく独自のドメイン名 (例：www.example.com等) をファイルへのリンクで使用できます。
  • リージョナルエッジキャッシュは、エッジロケーションとオリジンの間に設置されるイメージで、エッジロケーションにキャッシュがない場合にリージョナルエッジキャッシュにキャッシュがあれば返します。ない場合はオリジンから返します。
  • エッジロケーションとリージョナルエッジキャッシュは AWS 側が自動的に選択します。

Black Belt（PDF）

https://d1.awsstatic.com/webinars/jp/pdf/services/20190730_AWS-BlackBelt_Amazon_CloudFront.pdf

Amazon CloudFront と AWS WAF を組み合わせるとアプリケーションを保護することができます。

エッジロケーションとは

  • エッジロケーションにコンテンツをキャッシュし、必要なときにのみオリジンからコンテンツを取得することで、オリジンのワークロード（作業負荷）を減らすことができます。
  • オリジンサーバーが直接応答するリクエストの数を減らすことができます。

※ワークロードとは作業負荷のことを言います。

エッジロケーションの機能

  • コンテンツ配信
  • キャッシュ蓄積

エッジロケーションを使用する AWS サービス

  • Amazon CloudFront
  • Lambda（Lambda@Edge を利用すると Lambdaファンクションをオリジンサーバではなくエッジロケーションで実行でき、プロセスの作成に要する時間を短縮できたり、レイテンシーが大幅に軽減されます。）
  • S3（Amazon S3 Transfer Acceleration を使用すると、クライアントと S3 バケットの間で、長距離にわたるファイル転送を高速、簡単、安全に行えるようになります。Transfer Acceleration では、Amazon CloudFront の世界中に分散したエッジロケーションを利用しています。）

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

  • distribution　←　流通。配布。分布。

CloudFront を使用してコンテンツを配信するときは、ディストリビューションを作成して構成を設定します。

ディストリビューションを作成して、コンテンツを配信する場所と、コンテンツ配信の追跡と管理の方法の詳細を CloudFront に指示します。

CloudFront 側で SSL 証明書を保持して利用できる

CloudFront 側で SSL 証明書を保持して利用できます。

SSL 証明書をインポートすることもできますし ACM（AWS Certificate Manager）を利用することもできます。

※他には ELB、Amazon API Gateway の API などで ACM 管理の SSL 証明書を利用できます。

また、以下の環境で SSL 証明書を利用できます。

  • ビューワー（閲覧者）と CloudFront との間

  • CloudFront とオリジンとの間で HTTPS を使用するための証明書

CloudFront で HTTPS 接続だけ許可する設定手順

CloudFrontでHTTPS接続だけ許可する設定手順です。

  • CloudFront の Viewer Protocol Policy の設定で HTTPS Only を設定する。
  • CloudFront の Viewer Protocol Policy の設定で Redirect HTTP to HTTPS を設定する。
  • CloudFront の Viewer Protocol Policy の設定で SSL/TLS 証明書を利用できるように設定する。 

CloudFront のセキュリティについて

Amazon CloudFront はデフォルトで DDoS 攻撃に対処するサービスである Amazon Sheild Standard が適用されており、Web アプリケーションを保護できます。（追加料金がなく自動で Amazon Sheild Standard が適用されます）

これにより SYNフラッドや UDPリフレクション攻撃などの多くの一般的な DDoS 攻撃がオリジンに到達するのを防ぎます。

また、Amazon CloudWatchアラームを追加してこうした攻撃による影響発生をモニタリングできます。

CloudFront 単独では SQLインジェクションなどの攻撃を予防することはできないため、WAF によって防ぐ必要があります。

CloudFront と S3 の構成

静的なWebページを構築する場合は、CloudFront と S3 だけで構成できます。

CloudFront と S3 の静的 Web ページでアカウント制限をかける場合

CloudFront の OAI（オリジンアクセスアイデンティティ）という特別な CloudFront ユーザーを作成して、S3 バケットポリシーの特定のユーザーに許可することで、CloudFront 経由で特定のユーザだけが S3バケットにアクセスできるように構成することができます。

逆に言うと OAI を使用することで直接 S3 バケットの URL を経由してアクセスすることができなくなります。セキュリティの向上につながります。

※OAC（オリジンアクセスコントロール）は現在は推奨されていません。

CloudFront と S3 の静的 Web ページでアカウント制限と IP アドレス制限をかける場合

CloudFrontのOAI（オリジンアクセスアイデンティティ）と WAF の機能を利用することで、特定のユーザと特定の IPアドレスのみが S3バケットにアクセスできるように制限することができます。

CloudFront で標準的に連携されている AWS WAF を利用して、特定の IPアドレスのみが CloudFront 経由でアクセスできるように設定することができます。

AWS WAF を利用してのアクセス制限は IPアドレスベースとなるので、特定のユーザだけ排除するなどといった制限は AWS WAF ではできません。

CloudFrontとS3の構成で特定のユーザに対してアクセス制限をする場合

CloudFront と S3 の構成の場合、バケット内のオブジェクトのアクセス権限を全員に割り当ててから CloudFront で「署名付き URL」または「署名付き Cookie」を作成して Amazon S3 バケット内のファイルへのアクセスを制限します。

その後、OAI（オリジンアクセスアイデンティティ）ザーを作成して配布に関連付けます。

CloudFront でヘッダーを管理・操作できる

CloudFront でヘッダーを管理・操作できます。以下の 3つの方向でのヘッダーを管理できます。

  • オリジンに送るリクエストヘッダー（Origin Request）
  • ビューア（ユーザー）から来るリクエストヘッダー（Viewer Request）
  • ビューアに返すレスポンスヘッダー（Viewer response / Origin response）

オリジンに送るリクエストヘッダー（Origin Request）

オリジンに送信するリクエストにカスタムヘッダーを追加するように CloudFront を設定できます。オリジン側で認証などしたい場合に利用できます。

オリジン設定のカスタムヘッダーで設定します。

ビューア（ユーザー）から来るリクエストヘッダー（Viewer Request）

ビューワー（閲覧者）がリクエストヘッダーに Accept-Encoding: gzip を含めてリクエストした場合、CloudFront が自動的にファイルを圧縮して供給するなどで利用します。

Lambda@Edge や CloudFront Functions を利用します。

ビューアに返すレスポンスヘッダー（Viewer response / Origin response）

ビューアに返すレスポンスヘッダーは、Lambda@Edgeで書き換えるか、Response Headers Policy で付けます。

エッジロケーションでコンテンツを ZIP 圧縮が可能

エッジロケーションでの ZIP 圧縮によって配信データサイズを少なくしてコスト削減ができます。

ビューワー（閲覧者）がリクエストヘッダーに Accept-Encoding: gzip を含めてリクエストした場合は、CloudFront が自動的にファイルを圧縮して供給できます。

ファイルが小さくなるとダウンロード時間が短縮されます。

特定地域だけアクセス制限をすることが可能

CloudFront の地域制限（地理的ブロッキング）を使用して特定地域だけアクセス制限（アクセス拒否）をすることが可能です。

具体的にはエッジロケーションによる地理的制限を有効化することで、ディストリビューションに関連するすべてのファイルへのアクセスを制限し、国レベルでアクセスを制限できます。

署名付き URL

CloudFront の署名付きURLは、特定の URL に対して期限付き・条件付きでアクセスを許可する仕組みです。通常の URL に、署名や有効期限などの情報を付けて発行し、CloudFront はその URL を受け取ると、署名が正しいか・期限内か・必要な条件を満たしているかを検証してから配信します。CloudFront で使う署名方式としては、信頼されたキーグループに登録した公開鍵に対応する秘密鍵で URL を署名し、CloudFront はその公開鍵で検証します。CloudFront は署名付き URL で RSA 2048 と ECDSA 256 の署名をサポートしています。

たとえば、会員だけに PDF を配る、購入者だけにダウンロードリンクを渡す、期間限定で動画やファイルを見せる、といった用途で使います。署名付き URL は個別ファイルへのアクセス制御に向いています。

署名付き URL の使い方

署名付き URL を利用する流れは以下のようなイメージです。

  1. CloudFrontディストリビューションに、署名を検証するための trusted key group または trusted signer を設定する
  2. アプリが、対応する秘密鍵で URL を署名する
  3. 利用者に、その署名付き URL を渡す
  4. 利用者がその URL で CloudFront にアクセスする
  5. CloudFront が署名・期限・ポリシー条件を確認し、OK ならコンテンツを返す

署名付き URL を使うケース

署名付き URL の使いどころです。

  • アプリケーションのダウンロードなど、個々のファイルへのアクセスを制限したい。（みんな同じファイルにアクセスをする。）
  • ユーザーがクッキーをサポートしていないクライアントを使用している。
  • URL が変更しても構わない。

署名付き Cookie

CloudFront の署名付き Cookie は、CloudFront 経由で配信する非公開コンテンツに対して、Cookie を持っている利用者だけアクセスを許可する仕組みです。URL 自体はそのままにして、ブラウザに保存された Cookie でアクセス可否を判定できるのがポイントです。たとえば、会員サイト内の画像・PDF・動画セグメントなど、複数ファイルをまとめて保護したいときによく使います。

署名付き Cookie の使い方

署名付き Cookie を利用する流れは以下のようになります。

  1. ユーザーがアプリにログインする
  2. アプリ側が「この人には閲覧権限あり」と判断する
  3. アプリが署名済みのCloudFront用CookieをSet-Cookieで返す
  4. ブラウザは以後のCloudFrontへのリクエストでそのCookieを送る
  5. CloudFrontはCookieの署名や有効期限などを検証し、問題なければ配信する

署名付き Cookie を使うケース 

  • HLS 形式の動画のすべてのファイル、または Web サイトの購読者領域のすべてのファイルなど、制限のある複数のファイルへのアクセスを提供したい。例えば、AさんはファイルAにアクセス可能、BさんはファイルBにアクセス可能など。
  • URL を変更したくない。（署名付き URL は URL が変わります）

Amazon CloudFront のコスト

顧客へのコンテンツ配信に使用されたデータ転送とリクエストに基づきます。リクエストは数であったりリクエストの種類であったり場所であったりします。

逆に言えば、顧客へのデータ転送やリクエストがなければ（通信が全くなければ）コストは掛からないと言えます。

■Amazon CloudFront のコストについて

https://aws.amazon.com/jp/cloudfront/pricing

  • データ転送出力（転送アウト）（GB 単位） (インターネット/オリジン)
  • HTTP/HTTPS リクエスト
  • オリジンへのリージョン内データ転送アウト (GB 単位)
  • トラフィックの分散（データ転送とリクエストの価格は地域によって異なり、価格はコンテンツが配信されるエッジの場所に基づいています。）

ちなみに「オリジンへのリージョン内データ転送アウト」の「データ転送アウト」ですが、これは CloudFront のエッジから閲覧者（クライアント）へ実際に配信したバイト量のことです。配信した分だけGB単位で課金されます。

完全にテキストベースのWebサイトではなく、画像が貼ってあったり、月に1万アクセス（1日330アクセス）くらいならあっという間に1GBは超えます。

■計算
1pv あたり
　・HTML：80–150 KB
　・CSS/JS 合計：300–900 KB
　・画像：0.7–2.5 MB
平均 1pv ≈ 1.0〜2.0 MB と仮定
　→ 10,000 PV × 1.0〜2.0 MB ＝ 10〜20 GB / 月

1カ月あたり1000pvで画像が300KBレベルなら無料になりそうですが、それよりもたくさん画像を使っておもしろくしてたくさんアクセスがあった方がよいですよね。

■常時無料枠

  • 1 か月あたり 1 TB のインターネットへのデータ転送
  • 1 か月あたり 10,000,000 件の HTTP または HTTPS リクエスト
  • 1 か月あたり 200 万件の CloudFront 関数呼び出し
  • 1 か月あたり 2,000,000 回の CloudFront KeyValueStore の読み取り
  • 10 個の配信テナント
  • 無料の SSL 証明書

この常時無料枠を確認すると、本サイトのようにそこまでアクセスがないようなサイトはほぼ無料になります。
※ただしオリジン（ALB、EC2、S3バケットなど）へのリージョン内データ転送アウトはGB単位で料金が発生するので、完全無料というわけではありません。もちろん閲覧者（クライアント）へのデータ転送が1GB以内でしたら料金が発生しません。

オリジンサーバのフェイルオーバー設定も可能

オリジンサーバの可用性を向上させるためにオリジンサーバのグループを作成し、CloudFrontのプライマリオリジンとセカンダリオリジンを設定できます。

プライマリオリジンが HTTP ステータスコードでエラーを返したらセカンダリオリジンにフェイルオーバーさせることができます。

オリジンアクセスアイデンティティー（Origin Access Identity）で S3バケットへのアクセスを制御する

オリジンアクセスアイデンティティー（Origin Access Identity）で S3バケットへのアクセスを制御することが可能です。

  1. オリジンアクセスアイデンティティ（OAI）と呼ばれる特別な CloudFront ユーザーを作成し、ディストリビューションに関連付けます。

  2. CloudFront が OAI を使用してバケット内のファイルにアクセスしてユーザーに提供できるように、S3 バケットのアクセス許可を設定します。ユーザーが S3 バケットへのダイレクト URL を使用して、そこにあるファイルにアクセスできないようにします。

オンプレミス環境も CloudFront のオリジンサーバに設定できる

CloudFront のオリジンサーバは EC2 インスタンスなど AWS のリソースだけでなくオンプレミス環境のサーバでもオリジンサーバに設定できます。

この機能により手っ取り早くオンプレミス環境のサーバのパフォーマンスアップや負荷分散を実現できます。

AWS AWS認定試験
Amazon CloudFront AWS AWS認定試験 CloudFront 署名付きCookie 署名付きURL
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

サイト管理人

関連記事

コメント

コメントする

AlphaOmega Captcha Classica  –  Enter Security Code
  ⟲    ➴
 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。