Amazon CloudFront のよくある質問

Q.Amazon CloudFront とは何ですか？

Amazon CloudFront は、企業やウェブアプリケーションデベロッパーに、少ない待ち時間と高いデータ転送速度でコンテンツを配信できる、簡単で費用対効果の高い方法を提供するウェブサービスです。 その他の AWS サービスと同様に、Amazon CloudFront はセルフサービスの従量課金制システムを提供しており、長期契約や最低料金は必要ありません。CloudFront を使用すれば、エッジロケーションのグローバルネットワークを使用して、お客様のファイルをエンドユーザーに届けることができます。

Q.Amazon CloudFront でできることは何ですか?

Amazon CloudFront はシンプルな API を備えています。これによって以下のことが可能となります。

• 世界中のエッジロケーションのネットワークを使用してリクエストに対応し、保管されているコンテンツを少ない待ち時間と高速データ転送速度で配信します。
• わずらわしい契約や、最低利用期間などを必要とせずに開始できます。

Q.Amazon CloudFront の利用を開始するにはどうすればよいですか?

Amazon CloudFront の詳細ページの [今すぐ無料でお試し] ボタンをクリックします。別の AWS のサービスを Amazon CloudFront で使用するファイルのオリジンに使用する場合は、CloudFront ディストリビューションを作成する前にそのサービスにサインアップする必要があります。

Q.どのようにすれば Amazon CloudFront を使用できますか?

Amazon CloudFront を使用するには、以下を行います。

• 静的ファイルの場合は、ファイルの最終バージョンを1つ以上のオリジンサーバーに格納します。これらは Amazon S3 バケットにすることができます。動的に生成された、つまりパーソナライズまたはカスタマイズされたコンテンツの場合は、Amazon EC2 またはその他のウェブサーバーをオリジンサーバーとして使用できます。これらのオリジンサーバーは、Amazon CloudFront を通じて配信されるコンテンツを格納または生成します。
• シンプルな API 呼び出しを通じて、お客様のオリジンサーバーを、Amazon CloudFront に登録します。この呼び出しは、CloudFront.net のドメイン名を返します。これを利用してオリジンサーバーから Amazon CloudFront サービスを通じてコンテンツを配信できます。例えば、Amazon S3 バケット「bucketname.s3.amazonaws.com」をすべての静的コンテンツのオリジンとして、Amazon EC2 インスタンス「dynamic.myoriginserver.com」をすべての動的コンテンツのオリジンとして登録できます。次に、API または AWS Management Console を使用して、「abc123.cloudfront.net」をディストリビューションのドメイン名として返す Amazon CloudFront ディストリビューションを作成できます。
• cloudfront.net ドメイン名、または作成した CNAME エイリアスをウェブアプリケーション、メディアプレーヤーまたはウェブサイトに含めます。cloudfront.net ドメイン名（またはセットアップした CNAME）を使用して行われる各リクエストは、最高のパフォーマンスでコンテンツを配信するために、最適なエッジロケーションに割り当てられます。エッジロケーションは、リクエストに対してファイルのローカルコピーを提供するよう試みます。ローカルコピーが入手不能な場合、Amazon CloudFront はオリジンからコピーを取得します。それ以降のリクエストにおいて、エッジロケーションでこのコピーが入手可能となります。

Q.Amazon CloudFront はどのようにしてより優れたパフォーマンスを発揮するのですか?

Amazon CloudFront では、コンテンツのコピーを視聴者の近くにキャッシュするエッジロケーションおよびリージョン別エッジキャッシュのグローバルネットワークを導入しています。Amazon CloudFront によって、エンドユーザーのリクエストが、確実に最寄りのエッジロケーションによって対応されるようになります。結果として、視聴者のリクエストの伝達距離が短くなるため、視聴者に対するパフォーマンスが向上します。エッジロケーションやリージョン別エッジキャッシュでキャッシュされていないファイルについては、Amazon CloudFront はオリジンサーバーと持続的な接続を保持して、これらのファイルができる限り早くオリジンサーバーから取得されるようにします。最後に、Amazon CloudFront は付加的な最適化 (例えば、より幅広い TCP の初期の輻輳ウィンドウ) を使用して、コンテンツを視聴者に配信する際により高いパフォーマンスを提供します。

Q.Amazon CloudFront は、どのようにしてインターネット上でコンテンツを配信するためのコストを削減するのですか?

その他の AWS の各種サービスと同様に、Amazon CloudFront には最低契約期間や最低料金がありません。使用量に応じてお支払いいただくだけです。Amazon CloudFront を使用した場合、自社でホスティングする場合に比べ、インターネット上の複数サイトにあるキャッシュサーバーのネットワーク運用における経費と複雑さが軽減され、トラフィックが急上昇する可能性に対応するために能力を過剰に提供する必要性もなくなります。Amazon CloudFront は、エッジロケーションで同時に同じファイルに閲覧者のリクエストが行われた場合に、1つのオリジンサーバーへのリクエストとして折りたたむテクニックも使用しています。これによりオリジンサーバーの負荷が軽減され、オリジンインフラストラクチャを拡張する必要性が削減されるため、さらにコスト削減につながります。

また、AWS オリジン (Amazon S3 や Amazon EC2 など) を使用している場合、2014 年 12 月 1 日以降、Amazon CloudFront への AWS データ転送に対しては課金されなくなりました。これは、すべての AWS リージョンからすべてのグローバル CloudFront エッジロケーションへのデータ転送に適用されます。

Q.Amazon CloudFront によってどのようにウェブサイト全体を高速化できますか？

Amazon CloudFront では、ユーザーがファイルに設定した標準的なキャッシュコントロールヘッダーを使用して、静的コンテンツと動的コンテンツを識別します。1 つの Amazon CloudFront ディストリビューションを使用してすべてのコンテンツを配信すると、ウェブサイトまたはウェブアプリケーション全体にパフォーマンスの最適化が適用されていることを確認するのに役立ちます。AWS はオリジンルートの監視および調整、システム状態の監視、問題が発生した場合の迅速な対応が可能なため、AWS オリジンを使用すると、パフォーマンスの改善、信頼性、使いやすさ、および Amazon CloudFront と他の AWS サービスとの統合という利点があります。1つのサイトで異なる種類のコンテンツに異なるオリジン（例えば、静的オブジェクトに Amazon S3、動的コンテンツに Amazon EC2、サードパーティコンテンツにカスタムオリジン）を使用して、使用量に応じて支払えるという利点もあります。

Q.Amazon CloudFront と Amazon S3 の違いは何ですか?

Amazon CloudFront は、よく使用されるウェブサイト画像、動画、メディアファイル、またはソフトウェアのダウンロードなど、頻繁にアクセスされる静的コンテンツを配信する場合に優れた選択肢となります。エッジデリバリーによるメリットを受けられるためです。

Q.Amazon CloudFront は、これまでのコンテンツ配信ソリューションとはどのように異なっているのですか?

Amazon CloudFront では契約を交渉したり高料金を支払ったりせずに高パフォーマンスのコンテンツ配信の利点を素早く手に入れることができます。Amazon CloudFront はセルフサービスモデルでの安価で従量制の料金体系へのアクセスを提供します。 デベロッパーの方はまたその他のアマゾン ウェブ サービスとの緊密な統合の利点も得られます。 Amazon S3、Amazon EC2、および Elastic Load Balancing をオリジンサーバーとするこのソリューションは使いやすく、デベロッパーに堅牢なストレージと高性能のコンテンツ配信という 2 つの強力な機能を提供します。 Amazon CloudFront を Amazon Route 53 および AWS CloudFormation と統合した場合、さらにパフォーマンスが向上し、設定も簡単です。

Q.Amazon CloudFront ではどのような種類のコンテンツがサポートされていますか？

Amazon CloudFront では HTTP またはWebSocket のプロトコルを使用して送信可能なコンテンツがサポートされています。これには、HTML または PHP のページやWebSocket ベースのアプリケーションなどの動的ウェブページとアプリケーション、ウェブサイトの画像、音声、動画、メディアファイルまたはソフトウェアのダウンロードなど、よく使用される静的ファイルが含まれます。Amazon CloudFront は HTTP 経由でライブまたはオンデマンドメディアのストリーミング配信もサポートしています。

Q.Amazon CloudFront は、AWS オリジンサーバー以外のサーバーでも利用できますか？

はい。Amazon CloudFront は、静的、動的両方のコンテンツについて、オリジナルの最終バージョンを保有するオリジンサーバーで利用できます。カスタムオリジンは追加料金なしで使用できます。

Q.Amazon CloudFront ではオリジンの冗長性をどのように実現していますか?

CloudFront ディストリビューションに追加されるすべてのオリジンには、予備のオリジンを割り当てて、プライマリオリジンを使用できないときに、トラフィックに自動対応するために使用できます。HTTP 4xx/5xx の各ステータスコードの組み合わせを選択して、プライマリオリジンから返されたときに予備のオリジンへのフェイルオーバーをトリガーできます。AWS と AWS 以外のオリジンを任意に 2 つ組み合わせることができます。

Q: Amazon CloudFront はサービスレベル利用規約 (SLA) を提供しますか?

はい。Amazon CloudFront SLA は、任意の請求期間中で、お客様の月間使用可能時間の割合が、当社のサービス契約を下回る場合、サービスクレジットを提供しています。詳細については、こちらを参照してください。

Q: Amazon CloudFront で AWS マネジメントコンソールを使用できますか?

はい。AWS マネジメントコンソールを使うとシンプルでポイントアンドクリックのウェブインターフェースで Amazon CloudFront を設定、管理できます。AWS Management Console は、すべての Amazon CloudFront の機能をサポートしており、コードの記述やソフトウェアをインストールすることなく、高速なコンテンツ配信を開始することができます。AWS マネジメントコンソールは、https://console.aws.amazon.com で無料でご利用いただけます。

Q: どのようなツールやライブラリが、Amazon CloudFront と連携するのですか?

当社のリソースセンターには、Amazon CloudFront のコンテンツ配信を管理するためのさまざまなツールや、多様なプログラミング言語のためのライブラリがあります。

Q.Amazon CloudFront ディストリビューションで zone apex (www.example.com ではなく example.com) を指定することはできますか?

はい。AWS の正式な DNS サービスである Amazon Route 53 を使用すると、「エイリアス」レコードを構成できます。このレコードによって、DNS 名の apex またはルート（example.com）を Amazon CloudFront ディストリビューションにマッピングできます。Amazon Route 53 は、CloudFront ディストリビューション用に正しい IP アドレスが設定されたエイリアスレコードの各リクエストに応答します。Route 53 では、CloudFront ディストリビューションにマッピングされているエイリアスレコードへのクエリは課金されません。このようなクエリは、Amazon Route 53 の使用状況レポートに「Intra-AWS-DNS-Queries」として記載されます。

Q.CloudFront のリージョン別エッジキャッシュとは何ですか?

CloudFrount は、エッジロケーションというデータセンターの世界的ネットワークを経由してコンテンツを配信します。リージョンのエッジはオリジンウェブサーバーと、コンテンツを直接ビューワーに配信するグローバルエッジロケーションの間にあります。これにより、視聴者に対するパフォーマンスを向上させながら、運用上の負担と、お手持ちのリソースの拡張コストを低く抑えることができます。

Q.リージョン別エッジキャッシュはどのように機能しますか?

Amazon CloudFront では、複数のリージョン別エッジキャッシュロケーションを視聴者のすぐ近くで、グローバルに追加しています。これらは、オリジンウェブサーバーと、ビューワーに直接コンテンツを配信する世界各地のエッジロケーションの間にあります。オブジェクトの人気が落ちるにつれて、個々のエッジロケーションはこれらのオブジェクトを削除してより人気の高いコンテンツのために場所を空けることができます。リージョン別エッジキャッシュは、個別のどのエッジロケーションよりも大きなキャッシュ幅を持っているため、オブジェクトはこの最も近いリージョン別エッジキャッシュでキャッシュに長く残ります。このことは、より多くのコンテンツを視聴者の近くに保ち、CloudFront がオリジンウェブサーバーに戻る必要性を減少させて、視聴者に対する全体的なパフォーマンスを向上させるのに役立ちます。例えば、欧州の CloudFront エッジロケーションが、フランクフルトのリージョン別エッジキャッシュに行ってオブジェクトを取得してからオリジンウェブサーバーに戻ることができます。リージョン別エッジキャッシュロケーションは現在、カスタムオリジンに戻る必要があるリクエストにのみ使用されます。つまり、S3 オリジンへのリクエストでは、リージョン別エッジキャッシュロケーションはスキップされます。

Q.リージョン別エッジキャッシュの機能はデフォルトで有効になっていますか?

はい。この機能は、すべての新規または既存の CloudFront ディストリビューション向けにデフォルトで有効にされているため、お客様の CloudFront ディストリビューションを変更する必要はありません。この機能の使用に追加料金は発生しません。

Q.Amazon CloudFront によって使用されるエッジネットワークロケーションはどこですか?

Amazon CloudFront では、コンテンツ配信にエッジロケーションとリージョン別エッジキャッシュのグローバルなネットワークを使用しています。Amazon CloudFront のロケーションの完全なリストはこちらから確認できます。

Q.指定した国に対してコンテンツを提供するかしないかを選択することはできますか?

はい、Geo Restriction 機能を使用すれば、コンテンツへのアクセスを許可するユーザーの国のリストを指定できます。または、コンテンツへのアクセスを許可しないユーザーの国を指定できます。いずれの場合も、CloudFront では、指定された国の閲覧者からのリクエストに、HTTP ステータスコード 403 (禁止) を使用して応答します。

Q.GeoIP データベースはどの程度正確ですか?

IP アドレスと国ルックアップデータベースの対応精度はリージョンによって異なります。最近のテストによると、IP アドレスと国の対応の全体的精度は 99.8% です。

Q.エンドユーザーにカスタムエラーメッセージを表示することはできますか?

はい、独自のブランドと HTTP 4xx と 5xx の様々なエラー応答を使用して、カスタムエラーメッセージ (HTML ファイルや .jpg 画像など) を作成することができます。作成したら、発生源が指定したエラーのいずれかを Amazon CloudFront に返してきたときにカスタムエラーメッセージをビューアーに返すよう CloudFront を設定できます。

Q.Amazon CloudFront はどのぐらいの期間ファイルをエッジロケーションに保管しますか？

デフォルトでは、キャッシュコンロールヘッダーが設定されていない場合、各エッジロケーションがファイルを変更したかどうかをチェック後24時間以上経てリクエストを受領するといつでも、ファイルの更新バージョンをチェックします。これは、「失効期間」と呼ばれます。 この失効期間は、0秒以上の任意の長さに設定できます。この設定は、オリジンにあるファイルのキャッシュコントロールヘッダーで行います。Amazon CloudFront は、キャッシュコントロールヘッダーを使用して、オリジンのファイルの更新バージョンを確認する頻度を決定します。失効期間を0秒に設定すると、Amazon CloudFront はすべてのリクエストをオリジンサーバーで再検証します。ファイルがそれほど頻繁に変更されない場合、失効期間を長めに設定し、ファイルへの更新を管理するためにバージョニングシステムを実践することをお勧めします。

Q.アイテムを Amazon CloudFront エッジロケーションから削除するにはどうするのですか？

エッジロケーションからファイルを削除する方法は複数あります。オリジンからは簡単にファイルを削除することができます。また、エッジロケーションのコンテンツが各オブジェクトの HTTP ヘッダーに定義された失効期間に到達すると、そのコンテンツは削除されます。指定された失効期間の前に、有害なまたは有害の可能性がある資料を削除する必要がある場合、無効な API を使用してすべての Amazon CloudFront のエッジロケーションからオブジェクトを削除できます。無効リクエストの料金はこちらでご覧ください。

Q.無効リクエスト数には制限がありますか？

オブジェクトを個別に無効にする場合は、進行中のディストリビューションごとに最大 3,000 個のオブジェクトまで、一度に無効化リクエストを作成できます。これは、最大 3,000 個のオブジェクトに対する 1 つの無効化リクエスト、1 つのオブジェクトに対する最大 3,000 個のリクエスト、または 3,000 個のオブジェクトを超えないその他の任意の組み合わせとすることができます。

* ワイルドカードを使用している場合、最大 15 個の無効化パスのリクエストを一度に作成できます。また、進行中のディストリビューションごとに最大 3,000 個の個別のオブジェクトを同時に作成することができます。ワイルドカードの無効化リクエストの制限は、オブジェクトの個別の無効化の制限とは無関係です。この限度を超過すると、以前のリクエストが終了するまで、余分な無効リクエストはエラーを返します。

無効機能は、予想できない状況でのみ使用できます。前もって頻繁にファイルをキャッシュから削除する必要がある場合は、ファイルのバージョニングシステムの実行または失効期間の短縮 (あるいは両方) を行います。

Q.Amazon CloudFront は PCI に準拠していますか?

はい、Amazon CloudFront はペイメントカード業界データセキュリティ基準 (PCI DSS) のレベル 1（サービスプロバイダレベル 1 が最も大きな分類です）に準拠した一連のサービスに含まれています。より詳細な情報は、デベロッパーガイドをご覧ください。

Q: Amazon CloudFront は HIPAA に適合していますか?

はい、AWS では HIPAA 準拠プログラムを拡張し、Amazon CloudFront を HIPAA 対応サービスとして追加しました。AWS と事業提携契約 (BAA) を締結している場合は、Amazon CloudFront を使用して保護医療情報 (PHI) を迅速に提供できるようになります。詳細については、HIPAA への準拠およびデベロッパーガイドをご覧ください。

Q: Amazon CloudFront は SOC に準拠していますか?

はい、Amazon CloudFront は SOC (System & Organization Control) 基準を満たしています。(SOC) レポートは、重要なコンプライアンス管理および目標を AWS がどのように達成したかを実証する、独立したサードパーティーによる審査報告書です。詳細については、AWS SOC コンプライアンスおよびデベロッパーガイドをご覧ください。

Q: AWS SOC 1、SOC 2、SOC 3 について、それぞれのレポートをリクエストするにはどうすればよいですか?

AWS SOC 1 レポートと AWS SOC 2 レポートは、AWS Artifact (AWS のコンプライアンスレポートをオンデマンドで入手するためのセルフサービスポータル) を使用して入手できます。詳細は、AWS マネジメントコンソール内の AWS Artifact にサインインするか、AWS Artifact の開始方法ページでご確認いただけます。最新の AWS SOC 3 レポートは、AWS のウェブサイトで公開されています。

Q.Amazon CloudFront はどのような種類の HTTP リクエストをサポートしていますか？

Amazon CloudFront では現在、GET、HEAD、POST、PUT、PATCH、DELETE、および OPTIONS のリクエストをサポートしています。

Q.Amazon CloudFront は POST レスポンスをキャッシュしますか？

Amazon CloudFront は POST、PUT、DELETE、および PATCH リクエストへのレスポンスをキャッシュしません。これらのリクエストはオリジンサーバーにプロキシされます。OPTIONS リクエストに対する応答のキャッシュを有効にすることができます。

Q.HTTP/2 の使用方法について教えてください。

既存の Amazon CloudFront ディストリビューションがある場合は、API またはマネジメントコンソールを使用して HTTP/2 を有効にできます。コンソールで、[Distribution Configuration] ページから [Supported HTTP Versions] に移動します。 そこで、[HTTP/2, HTTP/1.1, or HTTP/1.0] を選択できます。すべての新しい CloudFront ディストリビューションで HTTP/2 が自動的に有効になります。

Q.オリジンで HTTP/2 がサポートされていない場合はどうしますか?

Amazon CloudFront では、現在 HTTP/2 がサポートされており、ビューアのクライアントおよびブラウザにコンテンツを配信できます。エッジロケーションとオリジンサーバー間の通信に関しては、Amazon CloudFront では引き続き HTTP/1.1 が使用されます。

Q.Amazon CloudFront では、TLS なしで HTTP/2 がサポートされますか?

現在はできません。しかし、ほとんどの最新ブラウザでは暗号化された接続を介してのみ HTTP/2 がサポートされています。Amazon CloudFront での SSL の使用に関する詳細については、こちらを参照してください。

Q.WebSockets とはどのようなものですか？

WebSocket は、リアルタイムの通信プロトコルであり、クライアントと、長時間維持される TCP 接続経由のサーバーの間の双方向通信チャンネルを提供します。クライアントとサーバーで永続的なオープン接続を使用することにより、リアルタイムのデータを相互に送信することができます。新しいデータがやり取りされていることを確認するために、クライアントで頻繁に接続を再開する必要はありません。WebSocket 接続は、チャットアプリケーション、コラボレーションプラットフォーム、マルチプレイヤーゲーム、金融取引プラットフォームでよく使用されます。Amazon CloudFront での WebSocket プロトコル の使用についての詳細は、当社ドキュメントを参照してください。 

Q. Amazon CloudFront ディストリビューションが WebSocket プロトコルをサポートするようにするにはどうしたらよいですか？

WebSocket はグローバルに使用することができるため、デフォルトでサポートされている WebSocket プロトコルを CloudFront リソース内で有効にするために追加設定を行う必要はありません。

Q.WebSocket の接続は、Amazon CloudFront を通じていつ確立されますか？

Amazon CloudFront で WebSocket の接続が確立されるのは、クライアントが 'Upgrade: websocket' ヘッダーを含め、サーバーが HTTP ステータスコード 101 で応答して、WebSocket プロトコルに切り換え可能であることが確認されてからです。

Q.Amazon CloudFront は TLS 経由でのセキュアな WebSocket をサポートしていますか？

はい。Amazon CloudFront は、SSL/TLS プロトコルを使用して、WebSocket の暗号化接続 (WSS) をサポートしています。

Q.独自のドメイン名を使用して HTTPS 接続でコンテンツを配信するように CloudFront ディストリビューションを設定できますか?

デフォルトでは、URL に CloudFront ディストリビューションドメイン名を使用して、コンテンツを HTTPS 接続で視聴者に配信できます (例: https://dxxxxx.cloudfront.net/image.jpg)。独自のドメイン名と独自の SSL 証明書を使用して HTTPS 接続でコンテンツを配信する場合は、独自 SSL 証明書機能を使用できます。詳細はこちらをご覧ください。

Q.フィールドレベル暗号化とは何ですか?

フィールドレベル暗号化は CloudFront の機能で、ユーザーが提出したクレジットカード番号などのデータをオリジンサーバーに安全にアップロードすることができます。この機能を使用すると、PUT/POST リクエストがお客様のオリジンに転送される前に、フィールド固有の暗号化キー (お客様が指定) を使用して、機密データを HTTPS 形式でさらに暗号化できます。これにより、機密データはお客様のアプリケーションスタックの特定のコンポーネントまたはサービスでのみ、復号化および表示できます。フィールドレベル暗号化の詳細については、ドキュメントの「フィールドレベルの暗号化」を参照してください。

Q.CloudFront で既に SSL/TLS 暗号化を使用していますが、それでもフィールドレベル暗号化が必要ですか?

多くのウェブアプリケーションがユーザーからクレジットカード番号などの機密データを収集しており、その後、機密データはオリジンインフラストラクチャで実行されているアプリケーションサービスによって処理されます。それらのウェブアプリケーションは、エンドユーザーと CloudFront、および CloudFront とオリジン間で SSL/TLS 暗号化を使用しています。オリジンでは、ユーザー入力に基づいて重要なオペレーションを複数のマイクロサービスで実行するようになっている可能性があります。しかし通常、機密情報を使用するのは、これらのマイクロサービスの小さなサブセット 1 つで十分です。つまり、ほとんどのコンポーネントが何の理由もなくこれらのデータに直接アクセスできることを意味します。間違った変数を記録するなど、単純なプログラミングミスによって、顧客のクレジットカード番号がファイルに書き込まれてしまう可能性があります。

フィールドレベル暗号化を使用すると、CloudFront のエッジロケーションがクレジットカードデータを暗号化できます。そこからは、プライベートキーを持つアプリケーションのみが機密フィールドを復号化できます。従って、オーダーフルフィルメントサービスでは暗号化されたクレジットカード番号のみが表示されますが、支払いサービスではクレジットカードデータを復号できます。これにより、アプリケーションサービスの 1 つで暗号テキストが漏洩しても、データは暗号化された状態のまま保護されるため、よりレベルの高いセキュリティを実現できます。

Q.Amazon CloudFront の SNI 独自 SSL と専用 IP 独自 SSL の違いは何ですか。

専用 IP 独自 SSL は、SSL コンテンツが各 CloudFront エッジロケーションで機能するように、専用 IP アドレスを割り当てます。IP アドレスと SSL 証明書間のマッピングは 1 対 1 で行われるため、専用 IP 独自 SSL はブラウザや SNI をサポートしないその他のクライアントで機能します。現在の IP アドレスのコストに起因し、専用 IP 独自 SSL は時間数で按分され、1 か月あたり 600 USD となっています。

SNI 独自 SSL は Transport Layer Security プロトコルの SNI 拡張機能に依存します。この機能は、ウェブサイトの閲覧者が接続を試みているホスト名を含めることで、複数のドメインが同じ IP アドレスを介した SSL トラフィックを処理できるようにするものです。専用 IP 独自 SSL を使用すると、CloudFront は各 Amazon CloudFront のエッジロケーションからコンテンツを配信します。これは、専用 IP 独自 SSL 機能と同じセキュリティの元で行われます。SNI 独自 SSL は、Chrome バージョン 6 以降（Windows XP 以降、および OS X 10.5.7 以降で実行）、Safari バージョン 3 以降（Windows Vista 以降および Mac OS X 10.5.6 以降で実行）、Firefox 2.0 以降、Internet Explorer 7 以降（Windows Vista 以降で実行）などの最新のブラウザで機能します。SNI をサポートしない旧版のブラウザでは、コンテンツの HTTPS バージョンをロードするための接続を CloudFront で確立することができません。SNI 独自 SSL は標準の CloudFront のデータ転送とリクエストの料金のみでご利用いただけます。

Q.Server Name Indication とは何ですか。

Server Name Indication（SNI）は、Transport Layer Security（TLS）プロトコルの拡張機能です。このメカニズムにより、関連付けられた SSL リクエストのドメイン（サーバー名）が識別されるため、SSL 通信で適切な証明書を使用することができます。これにより、1 つの IP アドレスを複数サーバー間で使用することができるようになります。SNI には、サーバー名の追加のためにブラウザが必要です。ほとんどの最新のブラウザはこれをサポートしますが、いくつかの旧式ブラウザではサポートされません。詳細については、CloudFront デベロッパーガイドの SNI のセクション、または SNI の Wikipedia の記事を参照してください。

Q.CloudFront は AWS Certificate Manager と統合できますか?

はい。SSL/TLS 証明書をプロビジョンし、CloudFront ディストリビューションに関連付けることが数分で行えるようになりました。新しい AWS Certificate Manager (ACM) を使用して証明書をプロビジョンし、わずか数クリックで CloudFront ディストリビューションにデプロイしてしまえば、後は ACM によって証明書の更新管理が実行されます。ACM を使うことで、証明書のプロビジョン、デプロイ、および管理を追加料金なしで実現できます。

CloudFront では、サードパーティー認証機関から取得し、IAM 証明書ストアにアップロードした証明書も引き続きサポートされています。

Q.Amazon CloudFront では、有料またはプライベートなコンテンツへのアクセスコントロールをサポートしますか?

はい。Amazon CloudFront はオプションでプライベートコンテンツ機能を備えています。このオプションが有効になっていると、リクエストをセキュリティで保護しながら認証することにより、許可された場合のみ、Amazon CloudFront がファイルを配布します。CloudFront デベロッパーガイドでこの機能の詳細をご覧ください。

Q.CloudFront 経由で配信されるウェブアプリケーションを、DDoS 攻撃からどのように保護できますか?

AWS のお客様は、追加料金なしで AWS Shield Standard をご利用いただけます。AWS Shield は、AWS で実行しているウェブアプリケーションに対する DDoS 攻撃を防御するマネージド型サービスです。AWS のお客様すべてを対象とする AWS Shield Standard により、SYN/UDP フラッド攻撃やリフレクション攻撃といった最も頻繁に発生する一般的なインフラストラクチャ (レイヤー 3 およびレイヤー 4) 攻撃を防御し、AWS でのアプリケーションの高可用性を保護できます。

AWS Shield Advanced は、AWS ビジネスサポートと AWS エンタープライズサポートに登録しているお客様を対象とするオプションの有料サービスです。AWS Shield Advanced により、Elastic Load Balancing (ELB)、Amazon CloudFront、および Route 53 で実行しているアプリケーションを標的とする大規模かつ高度な攻撃を防御できます。

Q.CloudFront 経由で配信されるウェブアプリケーションを、どのように保護できますか?

CloudFront ディストリビューションを AWS WAF (Web アプリケーションファイアウォール) と統合すると、IP アドレス、HTTP ヘッダー、独自 URL 文字列に基づいてルールを設定して、ウェブアプリケーションを攻撃から守ることができます。AWS WAF では、これらのルールを使用して、ウェブアプリケーションに対するウェブリクエストをブロック、許可または監視 (カウント) できます。詳細については、AWS WAF デベロッパーガイドをご覧ください。

Q.オリジンに転送されるリクエストのヘッダーを追加または変更できますか?

はい。Amazon CloudFront を設定して、オリジンに転送されるリクエストに対して、カスタムヘッダーの追加または既存のヘッダーの値のオーバーライドを行えます。これらのヘッダーを使用すると、オリジンに対して行われたリクエストが CloudFront から送信されたものであることを検証するのに役立ちます。また、指定したカスタムヘッダーの値を含むリクエストのみを許可するよう、オリジンを設定することもできます。さらに、同じオリジンで複数の CloudFront ディストリビューションを使用している場合、カスタムヘッダーを使って、オリジンのリクエストをディストリビューションごとに区別できます。最後に、カスタムヘッダーを使用すると、リクエストに対して返される適切な CORS ヘッダーを判断するのに役立ちます。カスタムヘッダーは、CloudFront API や AWS マネジメントコンソールを使って設定できます。この機能に追加料金はかかりません。カスタムヘッダーの設定方法に関する詳細については、こちらをご覧ください。

Q.Amazon CloudFront は、どのようにして HTTP クッキーを処理するのですか？

Amazon CloudFront では、HTTP Cookie を使用してカスタマイズまたはパーソナライズされた動的コンテンツの配信がサポートされます。この機能を使用するには、一部またはすべての Cookie を Amazon CloudFront からお客様独自のオリジンサーバーに転送するかどうかを指定する必要があります。転送された Cookie の値は、Amazon CloudFront のキャッシュ内で一意のオブジェクトを特定するときに考慮されます。コンテンツ配信のエンドユーザーにとっては、Cookie を使用して自分だけのためにパーソナライズされたコンテンツと、Amazon CloudFront のパフォーマンスという、2 つのメリットがあります。お客様は、Cookie の値を Amazon CloudFront のアクセスログに記録するかどうかを選択することもできます。

Q.Amazon CloudFront は、どのようにして URL のクエリ文字列パラメータを処理するのですか？

Amazon CloudFront キャッシュでオブジェクトを識別するキャッシュキーの一部として、クエリ文字列を設定することができます（省略可能です）。これは、わずかな時間エッジでキャッシュされる可能性のある動的ウェブページ（検索結果など）の構築に役立ちます。

Q.キャッシュキーで使用するクエリパラメータを指定できますか?

はい。クエリストリングホワイトリスト機能によって、キャッシュキーで特定のパラメータのみを使用しながら、すべてのパラメータをオリジンに転送するよう Amazon CloudFront を簡単に構成できます。

Q.ホワイトリストに追加するクエリパラメータの数に上限はありますか?

はい。Amazon CloudFront では最大 10 個のクエリパラメータをホワイトリストに追加するよう構成できます。

Q.どのようなパラメータタイプがサポートされていますか?

Amazon CloudFront は RFC3986 のセクション 3.4 に定義されている URI クエリパラメータをサポートします。具体的には、HTTP GET ストリングに組み込まれている「?」文字の後ろにあるクエリパラメータで、「&」文字で区切られています。

Q.CloudFront は gzip 圧縮に対応していますか?

はい。CloudFront は、テキストデータやバイナリデータを自動的に圧縮できます。この機能を使用するには、キャッシュ動作設定で CloudFront によるオブジェクトの自動圧縮を行うよう指定し、クライアント側でリクエストヘッダーに Accept-Encoding: gzip を追加するようにします (ほとんどのウェブブラウザはデフォルトで対応しています)。この機能の詳細については、デベロッパーガイドを参照してください。

Q.ストリーミングとは何ですか? なぜストリーミング配信するのですか？

一般的に、ストリーミングとは、音声や動画を再生する際、あらかじめメディアファイルをダウンロードせずに、インターネットのエンドユーザーに配信することを言います。ストリーミングに使うこのプロトコルには、Apple の HTTP Live Streaming (HLS)、MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH)、Adobe の HTTP Dynamic Streaming (HDS)、Microsoft の Smooth Streaming などの HTTP を用いる配信があります。ストリーミングのプロトコルは、メディアをリアルタイムで配信するため、ウェブページやその他のオンラインコンテンツを配信するために使用されるものとは異なり、閲覧者はデータの配信中に、コンテンツを閲覧したり視聴したりすることができます。ストリーミングコンテンツは、お客様やお客様のエンドユーザーにとって、いくつかの恩恵をもたらす可能性があります。

• ストリーミングによって、閲覧者は視聴体験をよりコントロールできるようになります。例えば、これまでのダウンロード配信を使用するよりも、ストリーミングを使用した動画のほうが、視聴者が内容を前後に探索しやすいということが挙げられます。
• ストリーミングを使用すれば、コンテンツをよりうまくコントロールすることができます。動画を見終わったら、閲覧者のクライアントまたはローカルドライブ上にファイルが残らないからです。
• ストリーミングは経費削減に役立つだけでなく、閲覧者が実際に閲覧するメディアファイルの一部だけを配信することができます。対照的に、従来のダウンロード方法では、閲覧者がファイルの一部しか閲覧しない場合であっても、メディアファイル全体が配信されることが度々あります。

Q.Amazon CloudFront では、ビデオオンデマンド (VOD) ストリーミングプロトコルがサポートされますか?

はい。Amazon CloudFront では、動画コンテンツをオンデマンドで配信するためのオプションを複数用意しています。Amazon S3 (またはカスタムオリジン) に格納する前に、例えば AWS Elemental MediaConvert を用いて HLS、MPEG-DASH、または Microsoft Smooth Streaming に変換したメディアファイルがあれば、Amazon CloudFront ウェブディストリビューション を用いて、どのようなメディアサーバーでもそのフォーマットでストリーミングできます。

別の方法として、要求される HTTP ストリーミング形式にメディアファイルを変換できるサードパーティーのストリーミングサーバー (例: AWS Marketplace から入手できる Wowza Media Server) を Amazon EC2 で実行することもできます。このとき、このサーバーを Amazon CloudFront ウェブディストリビューションのオリジンとして指定できます。

詳細は AWS ページのビデオオンデマンド (VOD) をご覧ください。

Q.Amazon CloudFront は、複数プラットフォームへのライブストリーミングをサポートしていますか？

はい。Amazon CloudFront ライブストリーミングは、AWS Elemental MediaPackage や AWS Elemental MediaStore などの HTTP ベースのストリームを出力するライブ動画創作サービスであればどれでも使えます。MediaPackage は、ビデオディストリビューターが複数の配信とコンテンツ保護標準を用いて、どのような規模でもストリーミングコンテンツを高いセキュリティと信頼性で動画配信できる、動画創作、ジャストインタイムパッケージングサービスです。MediaStore は HTTP 創作、ストレージサービスで、ライブメディアに必要な高パフォーマンス、すぐに得られる一貫性、予測可能な低レイテンシーを、アマゾンストレージのセキュリティと耐久性と共にお届けします。

詳細は AWS ライブビデオストリーミングのページをご覧ください。

Q: Origin Shield とは?

Origin Shield は、一元化されたキャッシングレイヤーで、キャッシュヒット率を高めてオリジンの負荷を軽減するのに役立ちます。Origin Shield では、リージョン間でリクエストを折りたたんで、オブジェクトごとに 1 つのリクエストがオリジンに送信されるようにするため、オリジンの運用コストも削減できます。Origin Shield を有効にすると、CloudFront はすべてのオリジンフェッチを Origin Shield を介してルーティングし、コンテンツが Origin Shield のキャッシュにまだ保存されていない場合にのみオリジンにリクエストを送信します。

Q: Origin Shield はどのような場合に使用できますか?

Origin Shield は、視聴者がさまざまな地理的リージョンに広がっているワークロードや、ビデオストリーミング、オンザフライでの画像処理、もしくは同様のプロセスなどのためのジャストインタイムのパッケージ化を伴うワークロードなどに理想的です。Origin Shield をオリジンの前で使用することで、まず中央のキャッシュをチェックして、Origin Shield のキャッシュにないコンテンツのオリジンフェッチのみを一括で作成するため、冗長なオリジンフェッチの数を減らすことができます。同様に、Origin Shield をマルチ CDN アーキテクチャで使用すれば、他の CDN に対し Amazon CloudFront をオリジンとして配置して、CDN 全体で重複するオリジンフェッチの数を減らすことができます。これら、およびその他の Origin Shield のユースケースについては、Amazon CloudFront の開発者ガイドをご覧ください。

Q: どの Origin Shield のリージョンを使用すればよいですか?

Amazon CloudFront では、CloudFront のリージョン別エッジキャッシュがある AWS リージョンで Origin Shield を提供しています。Origin Shield を有効にする場合、オリジンへのレイテンシーが最も低くなる AWS リージョンを選択する必要があります。Origin Shield は、AWS リージョンにあるオリジン、および AWS にないオリジンに対して使用できます。詳細については、Amazon CloudFront の開発者ガイドで Choosing the AWS Region for Origin Shield をご覧ください。

Q: Origin Shield の耐障害性および可用性は高いでしょうか?

はい。すべての Origin Shield リージョンは、Auto Scaling 機能を備えた数多くの Amazon EC2 インスタンスにより、複数のアベイラビリティーゾーンにまたがる高可用性アーキテクチャを使用して構築されています。さらに、CloudFront のロケーションから Origin Shield への接続では、各リクエストにアクティブエラートラッキングを使用し、プライマリ Origin Shield ロケーションが利用できない場合は、セカンダリ Origin Shield ロケーションへリクエストを自動的にルーティングします。

Q:使用量の最大値が 150 Gbps または 250,000 RPS を超えると予想される場合でも、Amazon CloudFront を使用できますか?

はい。こちらで制限値の拡大を申請してください。その後 2 営業日以内にお客様のアカウントの制限値を拡大いたします。

Q: 私の Amazon CloudFront アカウントが提供できる配信数に制限はありますか?

AWS アカウントごとに作成できる配信数の現在の制限については、アマゾン ウェブ サービス General Reference の Amazon CloudFront Limits を参照してください。制限の引き上げを要求するには、CloudFront 上限緩和申請フォームにアクセスしてください。

Q: Amazon CloudFront を介して配信することができるファイルの最大サイズはどのくらいですか?

Amazon CloudFront を介して配信することができる単一ファイルの最大サイズは20 GB です。この制限は、すべての Amazon CloudFront 配信に適用されます。

Q: Amazon CloudFront で利用できるログ記録機能は何ですか?

CloudFront ディストリビューションを作成または変更するとき、アクセスロギングを有効化できます。CloudFront は、ディストリビューションから配信されるリクエストを、標準ログとリアルタイムログに記録する 2 つの方法を提供します。

CloudFront 標準ログは、選択した Amazon S3 バケットに配信されます (ログ記録は、ビューワーリクエストから数分以内に配信されます)。CloudFront が有効になっているときは、詳細なログ情報が W3C 拡張形式で、指定の Amazon S3 バケットに自動的に公開されます。アクセスログの内容は、お客様のコンテンツに対する個々のリクエストに関する詳細な情報です。例えば、リクエストされたオブジェクト、リクエストの日時、リクエストに応答したエッジロケーション、クライアント IP アドレス、リファラー、ユーザーエージェント、Cookie ヘッダー、結果タイプ (たとえば、キャッシュヒット、ミス、エラー) です。CloudFront は標準ログの料金を請求しませんが、ログファイルの保存とアクセスに対して Amazon S3 の料金が発生します。

CloudFront リアルタイムログは、Amazon Kinesis Data Streams で選択したデータストリームに配信されます (ログ記録は、ビューワーリクエストから数秒以内に配信されます)。リアルタイムログのサンプリング率、つまり、リアルタイムのログ記録を受信するリクエストの割合を選択できます。ログ記録で受信が行われる特定のフィールドを選択することもできます。CloudFront リアルタイムログには、標準ログと同じデータポイントがすべて含まれ、ビューワーリクエストヘッダーや国コードなど、各リクエストに関する特定の追加情報が W3C 拡張形式で含まれます。CloudFront は、Kinesis Data Streams の使用に対して生じる料金に加えて、リアルタイムログの料金を請求します。

Q: 自分のユースケースに適した CloudFront ログを判別するには?

ユースケースに応じて宛先を選択できます。時間に制限のあるユースケースで、数秒以内にすばやくログデータを入手する必要がある場合は、リアルタイムログを選択します。リアルタイムログのパイプラインをより安価に利用するには、特定のキャッシュ機能についてのみログを有効化する、またはサンプリングレートを低くするなどして、ログデータをフィルタリングできます。リアルタイムパイプラインは早急なデータ提供のために構築されます。そのため、データに遅延が生じると、ログレコードがドロップされることがあります。一方、リアルタイムデータを取得する必要はなく、低コストのログ処理ソリューションを必要としている場合は、現在の標準ログオプションが最適な選択肢となります。S3 の標準ログは完全性のために構築されており、ログは通常、数分後から利用できます。これらのログは特定のキャッシュの動作ではなく、ディストリビューション全体に適用できます。そのため、そのとき限りの調査、監査、分析などにログが必要なときは、S3 の標準ログのみを有効化することもできます。両方のログを組み合せて使用することもできます。運用上の可視性のためにはリアルタイムのログでフィルターされたリストを使用し、監査には標準のログを使用します。

Q: 利用できるログの対象となるオプションには何がありますか?
CloudFront の標準ログは S3 バケットでご利用いただけます。また、DataDog や Sumologic などのサードパーティ製のソリューションを構築することで、これらのログからダッシュボードを作成するために統合ビルドを使用できます。

リアルタイムのログは Kinesis Data Stream でご利用いただけます。Kinesis Data Streams のログは Amazon Kinesis Data Firehose へ発行できます。Amazon Kinesis Data Firehose は、Amazon S3、Amazon Redshift、Amazon Elasticsearch Service、および Datadog、New Relic、Splunk などのサービスプロバイダーに簡単な方法でログを配信できます。Kinesis Firehose はまた、一般的な HTTP エンドポイントへのデータ配信に対応しています。

Q: Kinesis Data Stream には Kinesis シャードがいくつ必要になりますか?
シャードの必要数を見積もるには、次の手順を使用してください。

1. ご使用の CloudFront ディストリビューションが受信する 1 秒あたりのリクエスト数を計算 (または概算) します。1 秒あたりのリクエスト数の計算には、CloudFront の使用量レポート、またはCloudFront メトリクスが役立ちます。
2. 単独のリアルタイムログレコードの典型的なサイズを判別します。利用できるすべてのフィールドを含む一般的なレコードはおよそ 1 KB です。ログレコードのサイズが不明な場合は、サンプルレートを低く (たとえば 1% に) 設定して、リアルタイムログを有効化し、Kinesis Data Streams でのデータのモニタリングを使用して平均的なレコードサイズを割り出します (レコード数の合計を受信バイト数の合計で割ります)。
3. 1 秒あたりのリクエスト数 (ステップ 1) に典型的なリアルタイムログレコードのサイズ (ステップ 2) を掛けて、リアルタイムログの設定が Kinesis データストリームへ送信すると考えられる 1 秒あたりのデータ量を判別します。
4. 1 秒あたりのデータを使用して、必要なシャードの数を計算します。1 つのシャードは 1 秒あたり 1 MB、1 秒あたり 1,000 件のリクエスト (ログレコード) を超える量を処理できません。必要なシャードの数を計算するときには、バッファーとして最大 25% の余裕を持たせるようお勧めします。

たとえば、ご使用のディストリビューションで 1 秒あたり 1 万件のリクエスト受信するのであれば、リアルタイムレコードのサイズは通常 1 KB です。つまり、ご使用のリアルタイムログの設定により、1 秒あたり 1,000 万 (1 万 x 1,000) バイト、または 9.53 MB が生成されることを意味します。このシナリオでは、必要な Kinesis シャード数は 10 個のみとなります。バッファーを持たせるため、最低でも 12 個のシャードを作成するようにしてください。

Q: Amazon CloudFront には、使用状況、視聴者、および提供されているコンテンツの詳細を確認できるよう、すぐに使えるレポートが用意されていていますか?

はい。詳しいキャッシュ統計レポートの受信、CloudFront 使用状況のモニタリング、顧客がコンテンツを閲覧している場所の確認、オペレーションに関するメトリックに対するほぼリアルタイムのアラームの設定など、Amazon CloudFront にはレポートニーズに適したさまざまなソリューションが用意されています。すべてのレポートオプションには、AWS マネジメントコンソールの Amazon CloudFront Reporting & Analytics ダッシュボードからアクセスできます。また、Amazon CloudFront の Reports & Analytics ページでもさまざまなレポートオプションの詳細を確認できます。

Q: 自分のディストリビューションにタグを付けられますか?

はい。Amazon CloudFront では、コスト配分タグ付けをサポートしています。タグを使用すると、AWS リソースの分類とグループ化によるコスト配分や経費の削減が簡単になります。例えば、タグを使用して、管理者、アプリケーション名、コストセンター、または特定のプロジェクトごとにリソースをグループ化できます。コスト配分タグ付けの詳細については、コスト配分タグの使用を参照してください。CloudFront ディストリビューションにタグを追加する準備が整ったら、Amazon CloudFront にタグを追加ページを参照してください。

Q: セキュリティ、運用、コンプライアンスを監査するために、自分のアカウントで実行したすべての Amazon CloudFront API 呼び出しの履歴を取得することはできますか?

はい。アカウントで行った Amazon CloudFront API の呼び出しの履歴を取得するには、CloudTrail の AWS マネジメントコンソールで AWS CloudTrail を有効にします。詳細については、AWS CloudTrail のホームページを参照してください。

Q: リアルタイムでメトリクスのモニタリングとアラーム発行を行うオプションはありますか?

Amazon CloudWatch を使用して、閲覧者のリクエストを受けてわずか数分後に Amazon CloudFront ディストリビューションの動作パフォーマンスに関するモニタリング、アラーム発行、および通知の受信を行うことができます。6 個の運用メトリクスがそれぞれ 1 分間隔で自動的に CloudFront から Amazon CloudWatch に対して発行されます。その後、CloudWatch を使用して、CloudFront トラフィックに通常とは異なるパターンが発生した場合のアラームを設定できます。CloudWatch での CloudFront アクティビティのモニタリングとアラームの設定を初めて行う場合は、Amazon CloudFront デベロッパーガイドのチュートリアルを参照するか、Amazon CloudFront マネジメントコンソールを開き、ナビゲーションペインで [Monitoring & Alarming] を選択してください。

Q: Lambda@Edge とは何ですか?

Lambda@Edge を使用すると、世界中の AWS エッジロケーションでコードを実行できます。サーバーのプロビジョニングや管理の必要がなく、エンドユーザーへの応答で発生するネットワークレイテンシーを最小限に抑えることができます。Node.js/Python コードを AWS Lambda にアップロードし、Amazon CloudFront リクエスト (視聴者のリクエストがあったとき、リクエストがオリジンに転送されたときやオリジンから戻ってきたとき、エンドユーザーに返される直前など) に応答してトリガーされるよう関数を設定するだけで、作業が完了します。コードはその後、コンテンツに対するリクエストが受信され、CloudFront エッジロケーション全体のリクエストのボリュームに合わせてスケールされるときに、すべての AWS エッジロケーションで実行できるようになります。詳細についてはドキュメントを参照してください。

Q.Lambda@Edge を使用してコンテンツをどのようにカスタマイズできますか?

CloudFront エッジで行うコンテンツ配信の決定を確認したら、キャッシュにどの動作をさせるか、およびリクエストフローのどのポイント (視聴者のリクエストがあったとき、リクエストがオリジンに転送されたときやオリジンから戻ってきたとき、エンドユーザーに返される直前など) にロジックが適用されるかを決定します。次に、Lambda コンソールまたは API を使用して Node.js/Python Lambda 関数を記述し、それをディストリビューション向けに選択した CloudFront トリガーイベントに関連付けます。一度保存さえしておけば、次に該当するリクエストがディストリビューションに実行される際、この関数が CloudFront エッジに伝達され、必要に応じてスケールおよび実行されます。詳細についてはドキュメントを参照してください。

Q: Amazon CloudFront でどのようなイベントをトリガーできますか?

以下のような Amazon CloudFront イベントに応答して関数が自動的にトリガーされます。

• 閲覧者のリクエスト – このイベントは、インターネット上のエンドユーザーまたはデバイスが CloudFront に対して HTTP(S) リクエストを行い、そのユーザーに最も近いエッジロケーションにリクエストが到達したときに発生します。
• 閲覧者の応答 – このイベントは、エッジにある CloudFront サーバーが、リクエストを実行したエンドユーザーまたはデバイスに応答する準備ができたときに発生します。
• オリジンのリクエスト – このイベントは、リクエストされたオブジェクトを CloudFront エッジサーバーがキャッシュに保持しておらず、閲覧者のリクエストをバックエンドのオリジンウェブサーバー (Amazon EC2、Application Load Balancer、または Amazon S3) に送信する準備ができたときに発生します。
• オリジンの応答 – このイベントは、エッジの CloudFront サーバーがバックエンドのオリジンウェブサーバーから応答を受け取ったときに発生します。

Q.IPv6 とは何ですか?

インターネットに接続されるすべてのサーバーとデバイスは、数値のインターネットプロトコル (IP) アドレスを持つ必要があります。インターネットとその利用者数が急増する中で、IP アドレスの必要性も急増しています。IPv6 は、インターネットプロトコルの新しいバージョンであり、従来の IPv4 よりも広いアドレス空間を使用します。IPv4 では、すべての IP アドレスの長さが 32 ビットであり、43 億個の一意のアドレスを使用できます。IPv4 アドレスの例は 192.0.2.1 です。それに対し、IPv6 アドレスは 128 ビットであり、約 340 兆個の一意の IP アドレスを使用できます。IPv6 アドレスの例は 2001:0db8:85a3:0:0:8a2e:0370:7334 のようになります。

Q.IPv6 ではどのようなことができるのですか?

Amazon CloudFront で IPv6 サポートを使用すると、IPv6 から IPv4 への変換ソフトウェアやシステムなしで、アプリケーションから Amazon CloudFront のエッジロケーションへの接続が可能になります。各国政府が設定した IPv6 の導入要件を満たすことができます。例えば、米国連邦政府をはじめとする政府が定める IPv6 採用要件を満たすことができます。また、IPv6 の拡張性、ネットワーク管理の容易さ、セキュリティに関する追加の組み込みサポートといった利点があります。

Q.IPv6 を使用すると、Amazon CloudFront のパフォーマンスが変わりますか?

いいえ。Amazon CloudFront では IPv4 と IPv6 のいずれを使用してもパフォーマンスは同じです。

Q: IPv6 で使用できない Amazon CloudFront の機能はありますか?

Amazon CloudFront の既存の機能はすべて IPv6 で使用できますが、ご利用のディストリビューションで IPv6 を有効にする前に、内部 IPv6 アドレス処理に関して 2 つの変更が必要になる場合があります。

1. Amazon CloudFront アクセスログ機能を有効にしている場合、ビューワーの IPv6 アドレスは "c-ip" フィールドに表示されるようになり、ログ処理システムが IPv6 で処理を継続できることの確認が必要な場合があります。
2. Amazon CloudFront ディストリビューションで IPv6 を有効にすると、ご利用のオリジンに送信される ‘X-Forwarded-For’ ヘッダーで IPv6 アドレスが提供されます。オリジンシステムで処理できるのが IPv4 アドレスのみである場合、オリジンシステムが IPv6 で処理を継続できることの確認が必要な場合があります。
   

また、信頼された署名者の IP ホワイトリストを使用する場合は、IP ホワイトリストによる信頼された署名者 URL 用の IPv4 専用ディストリビューションと、その他のすべてのコンテンツ用の IPv4/IPv6 ディストリビューションを使用する必要があります。このモデルによって、IPv4 アドレス経由で署名リクエストを受け取っって署名された場合に生じる問題を回避し、ホワイトリストに追加されていない別の IPv6 アドレスからのみコンテンツのリクエストを受け取ることができます。

Amazon CloudFront の IPv6 サポートの詳細については、Amazon CloudFront デベロッパーガイドのIPv6 support on Amazon CloudFrontを参照してください。

Q: IPv6 を使用する場合は、IP ホワイトリストによる信頼された署名者 URL を使用できないということですか?

いいえ。IPv6 と、IP ホワイトリストによる信頼された署名者 URL を併用する場合は、2 つの個別のディストリビューションを使用する必要があります。一方のディストリビューションは、IP ホワイトリストによる信頼された署名者 URL 専用にし、IPv6 を無効にします。もう一方のディストリビューションは、その他のすべてのコンテンツ用にし、IPv4 と IPv6 の両方に対応します。

Q.IPv6 を有効化すると、IPv6 アドレスがアクセスログに表示されますか?

はい。Amazon CloudFront のアクセスログ機能を有効にしている場合、ビューワーの IPv6 アドレスがアクセスログの "c-ip" フィールドに表示されます。ご利用のディストリビューションで IPv6 を有効にする前に、ログ処理システムが IPv6 アドレスで処理を継続できることの確認が必要な場合があります。IPv6 トラフィックにより、アクセスログで IPv6 アドレスを処理するツールやソフトウェアの機能に影響が出ている場合は、デベロッパーサポートにお問い合わせください。 詳細については、Amazon CloudFront アクセスログのドキュメントを参照してください。

Q: 新規のディストリビューションすべてで IPv6 を無効にできますか?

はい。新規と既存の両方のディストリビューションで、Amazon CloudFront コンソールまたは API を使用して、ディストリビューションごとに IPv6 を有効または無効にすることができます。

Q: IPv6 を無効にする理由にはどのようなものがありますか?

お客様との会話を通じて当社が把握している唯一のケースは、内部 IP アドレス処理に関するものです。Amazon CloudFront ディストリビューションで IPv6 を有効にすると、詳細なアクセスログで IPv6 アドレスが提供されるのに加えて、ご利用のオリジンに送信される ‘X-Forwarded-For’ ヘッダーで IPv6 アドレスが提供されます。オリジンシステムで処理できるのが IPv6 アドレスのみである場合、ご利用のディストリビューションで IPv6 を有効にする前に、オリジンシステムが IPv6 アドレスで処理を継続できることの確認が必要な場合があります。

Q: ディストリビューションで IPv6 を有効にしましたが、DNS ルックアップで IPv6 アドレスが返されません。どういうことでしょうか?

Amazon CloudFront は世界中で多様な接続を提供していますが、まだユビキタスな IPv6 接続に対応していないネットワークも一部にあります。長期的に見てインターネットが IPv6 に移行することは明らかですが、当面はインターネットのすべてのエンドポイントで IPv4 接続が使用されるでしょう。IPv6 よりも IPv4 での接続が有利な部分があれば、IPv4 を優先して使用します。

Q: Route 53 を使用して DNS のニーズを処理しており、Amazon CloudFront ディストリビューションを指すエイリアスレコードを作成した場合、IPv6 を有効にするためにエイリアスレコードを更新する必要はありますか?

はい。IPv4 と IPv6 の両方をサポートするために、それぞれ "A" と "AAAA" のレコードタイプを使用して、Amazon CloudFront ディストリビューションを指す Route 53 エイリアスレコードを作成することができます。IPv4 のみを有効にする場合は、タイプ "A" のエイリアスレコード 1 個のみ必要です。エイリアスリソースレコードセットの詳細については、Amazon Route 53 デベロッパーガイドを参照してください。

Q.Amazon CloudFront を使用すると、どのように課金されますか?

Amazon CloudFront の料金は、データ転送（アウト）、HTTP/HTTPS リクエスト、無効リクエスト、および CloudFront ディストリビューションに関連付けられた専用 IP 独自 SSL 証明書という 4 つの領域での実際のサービス使用状況に基づいて請求されます。

AWS 無料利用枠を使うと、Amazon CloudFront を無料で開始していただけます。サインアップしていただくと、AWS の新規お客様は、Amazon CloudFront において 50GB のデータ送信（アウト）と 2,000,000 件の HTTP および HTTPS リクエストを毎月 1 年間ご利用いただけます。

• インターネットへのデータ転送 (アウト)
  Amazon CloudFront のエッジロケーションから外部に送信されるデータ量に対して、GB 単位で課金されます。Amazon CloudFront からインターネットへのデータ転送の料金は、こちらを参照してください。データ転送の使用量は、地理的リージョンごとに合計され、コストは各エリアの料金範囲に基づいて計算されることにご注意ください。他の AWS のサービスをファイルのオリジンとして使用する場合、それらのサービスの使用料金 (ストレージやコンピューティング時間を含む) は別途課金されます。2014 年 12 月 1 日より、AWS (Amazon S3、Amazon EC2 など) をオリジンとする場合、Amazon CloudFront への AWS データ転送には課金されません。これは、すべての AWS リージョンからすべてのグローバル CloudFront エッジロケーションへのデータ転送に適用されます。
• オリジンへのデータ転送 (アウト)
  Amazon CloudFront エッジロケーションからオリジン（AWS オリジンおよび他のオリジンサーバーを含む）へ転送されたデータ量に応じて、GB 単位で課金されます。オリジンへの Amazon CloudFront データ転送の料金は、こちらを参照してください。
• HTTP/HTTPS リクエスト
  コンテンツに対する Amazon CloudFront への HTTP/HTTPS リクエスト数に対して課金されます。HTTP/HTTPS リクエストの料金は、こちらを参照してください。
• 無効リクエスト
  無効リクエストに含めるパスごとに課金されます。無効リクエストにリストされるパスは、CloudFront キャッシュから無効化するオブジェクトの URL（あるいは、パスにワイルドカード文字が含まれる場合は複数の URL）を表します。Amazon CloudFront から毎月 1,000 パスまでを無償でリクエストできます。最初の 1,000 パスを超えると、無効リクエストにリストされているパスごとに課金されます。無効リクエストの料金はこちらを参照してください。
• リアルタイムログリクエスト

リアルタイムログは、生成されたログ行の数に基づいて課金されます。CloudFront がログの宛先に発行するログ 1,000,000 行あたり 0.01 USD を支払います。

• 専用 IP カスタム SSL
  独自 SSL 証明書機能の専用 IP バージョンを使用する 1 つ以上の CloudFront ディストリビューションに関連付けられた各独自 SSL 証明書ごとに、毎月 600 USD をお支払いいただきます。この月額料金は時間数で按分されます。例えば、6 月に 24 時間 (つまり 1 日) のみ、1 つ以上の CloudFront ディストリビューションに独自 SSL 証明書を関連付けていた場合、6 月における独自 SSL 証明書機能の使用料金の合計は、(1 日/30 日) * 600 USD = 20 USD となります。専用 IP の独自 SSL 証明書サポートを利用するには、SSL 証明書をアップロードし、AWS マネジメントコンソールを使用して証明書と CloudFront ディストリビューションを関連付けます。2 つ以上の独自 SSL 証明書を CloudFront ディストリビューションに関連付ける必要がある場合は、ユースケースの詳細と使用する独自 SSL 証明書の数を CloudFront 上限緩和申請フォームに入力してください。
  

データ転送の使用範囲は、地理的なリージョンごとに個別に測定されます。上記の金額には、別途記載がある場合を除いて、税金や手数料などは含まれていません。

Q: 料金は税込みですか?

別途記載がない限り、表示される料金には VAT、売上税その他取引に対して適用される一切の税金等および関税は含まれません。日本の居住者であるお客様が AWS サービスをご利用になった場合には、料金とあわせて別途消費税をご請求させていただきます。詳細はこちらをご覧ください。

Q: リアルタイムログにはどの程度の費用がかかりますか?
1 KB のログサイズで 1,000 件/秒に対応するディストリビューションをお持ちで、米国東部 (オハイオ) にシャード 2 個で Kinesis Data Stream を作成するとします。

Kinesis Data Stream の月額: こちらの Kinesis 計算ツールを使用して計算すると、47.74 USD/月 となります。

CloudFront リアルタイムログ: 1 か月あたりのリクエスト数 X リアルタイムログの料金 = 1,000 x (60 秒 x 60 分 x 24 時間 x 30 日) X (0.01 USD /1,000,000) = 25.92 USD/月

Q: 304 レスポンスに対してどのように課金されますか?

304 は条件付き GET リクエストに対するレスポンスであり、HTTP および HTTPS リクエストおよびインターネットへのデータ転送送信（アウト）に対する課金となります。304 レスポンスにはメッセージボディが含まれていませんが、HTTP ヘッダーが帯域幅の一部を消費するため、それに対して標準の CloudFront データ転送料金が課金されます。データの転送量は、オブジェクトに関連付けられたヘッダーによって決まります。

Q.低コストの Amazon CloudFront リージョンからのみコンテンツを配信することを選択できますか?

はい。「価格クラス」は、Amazon CloudFront からコンテンツを配信する際に支払う料金を軽減するためのオプションとなります。デフォルトでは、Amazon CloudFront はエンドユーザーのレイテンシーを最小にするために、世界中のエッジロケーションのネットワークからコンテンツを配信します。しかし、コストが高い地域では料金が高くなっているため、この設定では、ロケーションによってはエンドユーザーに低レイテンシーでコンテンツを配信するための料金が高額になります。料金クラスを利用して配信料金を削減するには、Amazon CloudFront のエッジロケーションのうち高コストのものを、Amazon CloudFront ディストリビューションから除外します。Amazon CloudFrontの場合は、選択された料金クラスのロケーション内のエッジロケーションからコンテンツが配信されます。お客様に請求されるデータ転送とリクエストの料金には、コンテンツの実際の配信元となったロケーションでの料金が適用されます。

パフォーマンスが最も重要な場合は何もする必要はありません。コンテンツはロケーションのネットワーク全体から配信されます。他の料金クラスを使用する場合は、AWS マネジメントコンソールまたは Amazon CloudFront API を介して配信を設定できます。お客様が選択した料金クラスに一部のロケーションしか含まれていない場合は、Amazon CloudFront のすべてのロケーションから配信するときに比べて、視聴者が体感するレイテンシーが大きくなることがあります（特に、その料金クラスに含まれていないロケーション）。

なお、Amazon CloudFrontの場合でも、お客様が選択した価格クラスに含まれないロケーションのエッジロケーションからコンテンツが配信される可能性があることをご了承ください。このことが発生したときは、お客様への請求には、選択された料金クラス内で最も低料金のロケーションの単価が適用されます。

各価格クラスに属する場所の一覧については、こちらをご覧ください。