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 のリージョン別エッジキャッシュとは何ですか?

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

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

Amazon CloudFront は、グローバルに分散した複数のリージョン別エッジキャッシュ (REC) を持ち、エンドユーザーの近くに追加のキャッシングレイヤーを提供します。これらは、オリジンウェブサーバーと、ユーザーに直接コンテンツを配信する AWS エッジロケーションの間にあります。キャッシュされたオブジェクトの人気が落ちるにつれて、個々のエッジロケーションはこれらのオブジェクトを削除してより一般的に要求されるコンテンツのために場所を空けることができます。リージョン別エッジキャッシュは、個々のどのエッジロケーションよりも大きなキャッシュ幅を持っているため、オブジェクトはより長くキャッシュされます。このことは、より多くのコンテンツを視聴者の近くに保ち、CloudFront がオリジンウェブサーバーに戻る必要性を減少させて、視聴者に対する全体的なパフォーマンスを向上させるのに役立ちます。例えば、欧州の CloudFront エッジロケーションが、フランクフルトのリージョン別エッジキャッシュに行ってオブジェクトを取得してからオリジンウェブサーバーに戻ることができます。リージョン別エッジキャッシュのロケーションは、S3、EC2、カスタムオリジンなど、任意のオリジンで使用できます。REC は、現在アプリケーションのオリジンをホストしているリージョンではスキップされます。

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.HTTP/3 とは何ですか?

HTTP/3 は、ハイパーテキスト転送プロトコルの 3 番目のメジャーバージョンです。HTTP/3 は、ユーザーデータグラムプロトコル (UDP) ベースのストリーム多重化された安全なトランスポートプロトコルである QUIC を使用します。これは、既存の伝送制御プロトコル (TCP)、TLS、および HTTP/2 の機能を組み合わせ、改善するものです。HTTP/3 には、応答時間の短縮、セキュリティの向上など、以前の HTTP バージョンを上回るいくつかの利点があります。

Q.QUIC とは何ですか?

HTTP/3 は、QUIC という新しい、高パフォーマンスで弾力性があり、安全なインターネットトランスポートプロトコルを搭載しています。CloudFront の HTTP/3 サポートは、Rust による新しいオープンソースの QUIC プロトコル実装である s2n-quic の上に構築されています。QUIC の詳細については、「s2n-quic の紹介」ブログを参照してください。 

Q.Amazon CloudFront で HTTP/3 を使用する主な利点は何ですか?

顧客が常に求めているのは、より高速で安全なアプリケーションをエンドユーザーに提供することです。インターネットの普及率が世界的に高まり、モバイルやリモートネットワークからオンラインにアクセスするユーザーが増えるのに伴って、パフォーマンスと信頼性の向上に対するニーズがこれまで以上に高まっています。HTTP/3 は、以前の HTTP バージョンと比較して、いくつかのパフォーマンス改善を提供するため、これを可能にします。

1. より高速で信頼性の高い接続 - CloudFront は HTTP/3 の TLS ハンドシェイクに 1-RTT を使用し、以前の HTTP バージョンと比較して接続確立時間を短縮し、それに伴いハンドシェイクの失敗も減少しています。
2. ウェブパフォーマンスの向上 - CloudFront の HTTP/3 実装はクライアントサイドの接続移行をサポートし、クライアントアプリケーションが接続不良から最小限の中断で回復することを可能にします。TCP とは異なり、QUIC はロスレスではないので、パケットロスが多く混雑したネットワークに適しています。また、QUIC は Wifi や携帯電話のハンドオフ時に、より高速な再接続を可能にします。
   
3. セキュリティ - HTTP/3 は、TLS ハンドシェイク中に交換されるパケットを暗号化することにより、HTTP の以前のバージョンと比較してより包括的なセキュリティを提供します。これは、ミドルボックスによる検査を困難にし、さらなるプライバシーを提供し、マンインザミドル攻撃を低減します。CloudFront の HTTP/3 サポートは、効率とパフォーマンスに強く重点を置いた s2n-quic と Rust の上に構築されています。
   

Q.CloudFront ディストリビューションで HTTP/3 を有効にするにはどうすればいいですか?

CloudFront コンソール、UpdateDistribution API アクション、または Cloudformation テンプレートを使用して、新規および既存の Amazon CloudFront ディストリビューションの HTTP/3 をオンにすることができます。コンソールで、[Distribution Configuration] ページから [Supported HTTP Versions] に移動します。 そこで、[HTTP/3、HTTP/2、HTTP/1.1、または HTTP/1.0] を選択できます。

Q.HTTP/3 を有効にする前にアプリケーションを変更する必要がありますか?

CloudFront ディストリビューションで HTTP/3 を有効にすると、CloudFront は HTTP/3 サポートが利用できることを宣伝するために使用する Alt-Svc ヘッダーを自動的に追加するので、Alt-Svc ヘッダーを手動で追加する必要はありません。私たちは、お客様がアプリケーションが HTTP/3 接続の確立に失敗した場合、HTTP /1.1 または HTTP/2 にフォールバックするように、アプリケーションで複数のプロトコルのサポートを有効にされることを期待しています。HTTP/3 をサポートしていないクライアントは、HTTP/1.1 または HTTP/2 を使用して、依然として HTTP/3 が有効な CloudFront ディストリビューションと通信することができます。フォールバックサポートは HTTP/3 仕様の必須項目であり、HTTP/3 をサポートするすべての主要なブラウザによって実装されています。

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

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

Q.Amazon CloudFront の TLS セキュリティポリシーは、HTTP/3 とどのように相互作用するのでしょうか?

HTTP/3 は QUIC を使用しており、TLSv1.3 が必要です。したがって、選択したセキュリティポリシーとは無関係に、TLSv1.3 とサポートされている TLSv1.3 暗号スイートのみが HTTP/3 接続の確立に使用できます。詳細は CloudFront デベロッパーガイドのビューワーと CloudFront セクションの間でサポートしているプロトコルおよび暗号を参照してください。

Q.HTTP/3 を有効にするために、別途料金がかかりますか?

いいえ、Amazon CloudFront ディストリビューションで HTTP/3 を有効にするために別途料金がかかることはありません。HTTP/3 のリクエストは、お客様の料金プランに応じたリクエスト料金レートで課金されます。

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 ヘッダー、独自 URI 文字列に基づいてルールを設定して、ウェブアプリケーションを攻撃から守ることができます。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 では、動画コンテンツをオンデマンドで配信するためのオプションを複数用意しています。Simple Storage Service (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 を介して配信することができる単一ファイルの最大サイズは 30 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: CloudFront Functions とは?

CloudFront Functions は、サーバーレスエッジコンピューティング機能であり、225 以上の CloudFront エッジロケーションで JavaScript コードを実行して、軽量の HTTP の変換と操作を行うことができます。Functions は、最新のウェブアプリケーションに必要なパフォーマンスとセキュリティを備えた完全なプログラミング環境の柔軟性を顧客に提供する目的で設計されています。AWS Lambda@Edge の数分の 1 の料金で、お客様は手頃な価格ですぐに 1 秒あたり数百万のリクエストをサポートできます。

Q: CloudFront Functions を使用してコンテンツをどのようにカスタマイズできますか?

CloudFront Functions は CloudFront にネイティブに組み込まれているため、お客様は同じサービス内で関数を簡単に構築、テスト、デプロイできます。GitHub リポジトリを使用すれば、関数を構築するための開始点として使用できるサンプルコードの大規模なコレクションを提供しており、デベロッパーが簡単に開始することができます。IDE を使用して CloudFront コンソールで、または CloudFront API/CLI を使用して関数を構築できます。コードを作成したら、本稼働用の CloudFront ディストリビューションに対して関数をテストし、デプロイ後に関数が正しく実行されることを確認できます。コンソールのテスト機能は、テストイベントをすばやく作成し、関数を検証するためのビジュアルエディタを提供します。CloudFront ディストリビューションに関連付けられると、コードはグローバルに分散された AWS エッジロケーションのネットワークにデプロイされ、CloudFront リクエストに応答して実行されます。

Q: CloudFront Functions のユースケースには何がありますか?

CloudFront Functions は、次のような軽量で実行時間の短い関数に最適です。

• キャッシュキーの正規化: HTTP リクエスト属性 (ヘッダー、クエリ文字列、Cookie、さらにはリクエスト URL の相対パス) を変換して、最適なキャッシュキーを作成できます。これにより、キャッシュのヒット率を向上させることができます。
• ヘッダー操作: リクエストまたは応答で HTTP ヘッダーを挿入、変更、または削除できます。たとえば、HTTP strict transport security (HSTS) またはクロスオリジンリソースシェアリング (CORS) ヘッダーをすべての応答に追加できます。
• URL リダイレクトまたは書き換え: リクエスト内の情報に基づいてビューワーを他のページにリダイレクトしたり、すべてのリクエストをあるパスから別のパスにリダイレクトしたりできます。
• リクエストの承認: 承認ヘッダーやその他のリクエストメタデータを調べることで、JSON ウェブトークン (JWT) などの承認トークンを検証できます。

上記のさまざまなユースケースのすべての関数例は、CloudFront Functions GitHub リポジトリにあるため、すぐに使用することができます。

Q: CloudFront Functions は Lambda@Edge に置き換えることができますか?

いいえ、CloudFront Functions は、Lambda@Edge を補完するためのものであり、置き換えるためのものではありません。Lambda@Edge と CloudFront Functions の組み合わせにより、ジョブに適したツールを選択できます。CloudFront ディストリビューションの同じキャッシュ動作内にある異なるイベントトリガーで CloudFront Functions と Lambda@Edge の両方を使用するよう選択することができます。例として、Lambda@Edge を使用して、ストリーミングマニフェストファイルをオンザフライで操作し、カスタムトークンを挿入してライブストリームを保護できます。CloudFront Functions を使用して、ユーザーがマニフェストからセグメントをリクエストしたときに、これらのトークンを検証できます。

Q: CloudFront Functions または Lambda@Edge を使用する利点は何ですか?

CloudFront Functions と Lambda@Edge の組み合わせにより、CloudFront イベントに応答してコードを実行するための強力で柔軟なオプションが 2 つ提供されます。どちらも、インフラストラクチャを管理することなく、CloudFront イベントに応答してコードを実行する安全な方法を提供します。CloudFront Functions は、軽量かつ大規模で、レイテンシーに敏感なリクエスト/レスポンスの変換と操作に向けて設計されました。Lambda@Edge は、幅広いコンピューティングのニーズとカスタマイズをサポートする汎用ランタイムを使用します。Lambda@Edge は、コンピューティングが多い操作に使用する必要があります。これは、完了に時間がかかる (数ミリ秒～数秒)、外部のサードパーティライブラリと依存関係にある、他の AWS のサービス (S3、DynamoDB など) との統合が必要、またはデータ処理のためのネットワーク呼び出しが必要といったコンピューティングである可能性があります。よく見られる高度な Lambda@Edge ユースケースには、HLS ストリーミングマニフェストの操作、サードパーティ承認やボット検出サービスとの統合、エッジでのシングルページアプリ (SPA) のサーバー側レンダリング (SSR) などがあります。詳細については、Lambda@Edge のユースケースページを参照してください。

Q: AWS は CloudFront Functions をどうやって安全に保ちますか?

CloudFront Functions は、期待できるパフォーマンス、スケール、費用対効果を提供しますが、Functions コード間の厳密な分離境界を提供する独自のセキュリティモデルを備えています。共有のマルチテナントコンピューティング環境でカスタムコードを実行する場合、安全性の高い実行環境を維持することが重要です。悪意のある攻撃者は、ランタイム、ライブラリ、または CPU に存在するバグを悪用して、サーバーまたは別の顧客の機能から機密データを漏洩させる可能性があります。関数コード間の厳密な分離障壁がなければ、これらの悪用が可能になります。AWS Lambda と Lambda@Edge はどちらも、Firecracker ベースの VM 分離によってすでにこのセキュリティ分離を実現しています。CloudFront Functions を使用して、Spectre や Meltdown などのサイドチャネル攻撃、タイミングベースの攻撃、またはその他のコードの脆弱性に対して同じセキュリティバーを提供するプロセスベースの分離モデルを開発しました。CloudFront Functions は、他の顧客に属するデータにアクセスしたり、データを変更したりすることはできません。これを行うには、専用の CPU で専用プロセスで関数を実行します。CloudFront Functions は、一度に 1 人の顧客にのみサービスを提供するプロセスワーカーで実行され、実行する間にすべての顧客の固有データがクリア (フラッシュ) されます。

CloudFront Functions は、JavaScript エンジンとして V8 を使用しません。Functions のセキュリティモデルとは異なり、他のベンダーが提供する v8 分離ベースのモデルよりも安全であると考えられています。

Q: CloudFront Function が正常に実行されていることを確認するには、どうすればよいですか?

組み込みのテスト機能を使用して、任意の機能をテストできます。関数をテストすると、CloudFront ディストリビューションに対してコードが実行され、関数が期待される結果を返すことを検証します。コードの実行を検証することに加えて、コンピューティング使用率メトリックも提供されます。計算使用率メトリックは、関数が実行時間制限にどれだけ近いかを示すパーセンテージを示します。たとえば、計算使用率が 30 の場合、関数が合計許容実行時間の 30% を使用していることを意味します。テストオブジェクトは、ビジュアルエディタを使用して作成できるため、オブジェクトごとにクエリ文字列、ヘッダー、URL、HTTP メソッドを簡単に追加できます。また、リクエストまたはレスポンスの JSON 表現を使用してテストオブジェクトを作成することもできます。テストが実行されると、結果と計算使用率メトリックは、同じビジュアルエディタスタイルで、または JSON 応答を表示することで確認できます。関数が正常に実行され、コンピューティング使用率メトリックが 100 に近くない場合、CloudFront ディストリビューションに関連付けられたときに関数が機能することがわかります。

Q: CloudFront Function をモニターするにはどうすればよいですか?

CloudFront Functions は、メトリックと実行ログの両方を出力して、関数の使用状況とパフォーマンスを監視します。メトリックスは関数の呼び出しごとに生成され、CloudFront または CloudWatch コンソールで各関数からのメトリックを個別に確認できます。メトリックには、呼び出しの数、計算の使用率、検証エラー、および実行エラーが含まれます。関数の結果が検証エラーまたは実行エラーになった場合、エラーメッセージは CloudFront アクセスログにも表示され、関数が CloudFront トラフィックにどのように影響するかをより明確に把握できます。メトリックに加えて、関数コード内に console.log() ステートメントを含めることで実行ログを生成することもできます。ログステートメントは、CloudWatch に送信される CloudWatch ログエントリを生成します。ログとメトリックは、CloudFront Functions 料金の一部として含まれています。 

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

Lambda@Edge は、AWS Lambda の拡張機能であり、サーバーをプロビジョニングまたは管理することなく、グローバルエッジロケーションでコードを実行できます。Lambda@Edge は、複雑な機能と完全なアプリケーションロジックを視聴者に近づけるための強力で柔軟なサーバーレスコンピューティングを提供します。Lambda@Edge 関数は、Node.js または Python 環境で実行されます。関数を単一の AWS リージョンに公開し、その関数を CloudFront ディストリビューションに関連付けると、Lambda@Edge はコードを世界中に自動的に複製します。Lambda@Edge は、1 日あたり数リクエストから 1 秒あたり数千リクエストまで自動的にスケーリングします。

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

Lambda@Edge は、CloudFront の特定のキャッシュ動作に対して関数を関連付けることで実行されます。CloudFront リクエストまたはレスポンス処理のどの時点で関数を実行するかを指定することもできます (つまり、視聴者のリクエストが到着したとき、リクエストが発信元に転送されたか受信されたとき、またはエンドビューワーに応答する直前)。Lambda コンソール、API から Node.js または Python を使用するか、サーバーレスアプリケーションモデル (SAM) などのフレームワークを使用してコードを記述します。関数をテストしたら、選択した CloudFront キャッシュの動作とイベントトリガーに関連付けます。一度保存さえしておけば、次にリクエストが CloudFront ディストリビューションに実行される際、この関数が CloudFront エッジに伝達され、必要に応じてスケールおよび実行されます。詳細についてはドキュメントを参照してください。

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

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

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

Q: CloudFront の継続的デプロイとは何ですか?

CloudFront での継続的デプロイは、すべてのビューワーに変更をデプロイする前に、ライブトラフィックの一部を使用して設定の変更をテストおよび検証する機能を提供します。

CloudFront を使用した継続的デプロイにより、デプロイの安全性を高いレベルで実現します。ブルー、グリーンという 2 つの独立した同一環境をデプロイできるようになりました。また、ドメインネームシステム (DNS) を変更せずにリリースを段階的に展開する機能を使用して、継続的インテグレーションおよびデリバリー (CI/CD) パイプラインに簡単に統合できます。ビューワーセッションを同じ環境にバインドすることで、セッション維持機能によりビューワーが一貫した体験を得られるようにします。さらに、標準ログとリアルタイムログを監視することで変更のパフォーマンスを比較できます。その変更がサービスに悪影響を与える場合は、以前の設定にすばやく戻すことが可能です。 

Q: CloudFront で継続的デプロイを設定する方法は?

CloudFront コンソール、SDK、コマンドラインインターフェイス (CLI)、または CloudFormation テンプレートから、ステージングディストリビューションをプライマリディストリビューションに関連付けることで、継続的デプロイを設定することができます。その後、クライアントヘッダーを設定したり、ステージングディストリビューションでテストするトラフィックの割合をダイヤルアップすることで、トラフィックを分割するルールを定義することができます。一度セットアップすれば、必要な変更を加えてステージング設定を更新することができます。CloudFront はユーザーへのトラフィックの分割を管理し、関連する分析を提供して、デプロイを継続するかロールバックするかを決定するのに役立ちます。ステージングディストリビューションでのテストが検証されたら、メインディストリビューションに変更をマージすることができます。

この機能の詳細については、ドキュメントをご覧ください。

Q: 継続的デプロイの結果はどのように測定するのですか?

Q: 継続的デプロイでは、実際のウェブトラフィックを通じて実際のユーザーをモニタリングすることができます。CloudFront コンソール、CloudFront API、CLI、CloudWatch などの既存の利用可能なモニタリング方法を利用して、プライマリディストリビューションとステージングディストリビューションの運用メトリクスを個別に測定することができます。2 つのディストリビューション間のスループット、レイテンシー、および可用性メトリクスを測定し、比較することによって、特定のアプリケーションの成功基準を測定することができます。

Q: 既存のディストリビューションを使用できますか?

はい、ステージングディストリビューションを作成し、変更を導入してテストするためのベースラインとして、既存の任意のディストリビューションを使用することができます。

Q: CloudFront Functions と Lambda@Edge を使った継続的デプロイはどのように機能しますか?

継続的デプロイでは、プライマリディストリビューションとステージングディストリビューションに異なる関数を関連付けることができます。また、同じ関数を両方のディストリビューションで使用することもできます。両方のディストリビューションで使用されている関数を更新すると、両方のディストリビューションが更新を受け取ります。

Q: AWS CloudFormation で継続的デプロイのディストリビューションを使用するにはどうすればいいですか?

CloudFormation スタック内の各リソースは、特定の AWS リソースにマッピングされます。ステージングディストリビューションは、独自のリソース ID を持ち、他の AWS リソースのように動作します。そのリソースを作成/更新するために、CloudFormation を使用することができます。

Q: CloudFront での継続的デプロイは、どのようにセッションスティッキネスをサポートしますか?

ウェイトベースの設定を使用してステージングディストリビューションにトラフィックをルーティングするとき、CloudFront が同じビューワーからのリクエストを単一のセッションとして扱うことを確認するのに役立つセッションスティッキネスも有効にすることができます。セッションスティッキネスを有効にすると、CloudFront はクッキーを設定し、単一セッションにおける同じビューワーからのすべてのリクエストが、プライマリまたはステージングのどちらかのディストリビューションによって提供されるようにします。

Q: このサービスのコストはいくらですか?

継続的デプロイ機能は、すべての 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 アドレスが提供されます。オリジンシステムで処理できるのが IPv4 アドレスのみである場合、ご利用のディストリビューションで 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 の AWS 無料利用枠では、どのような使用方法が対象となっていますか?

2021 年 12 月 1 日以降、すべての AWS のお客様は、1 TB のデータ転送 (アウト)、10,000,000 の HTTP/HTTPS リクエスト、および毎月 2,000,000 件の CloudFront Functions の呼び出しを無料でご利用いただけます。他のすべての使用タイプ (無効化、プロキシリクエスト、Lambda@edge、オリジンシールド、オリジンへのデータ転送など) は無料利用枠の対象外です。

Q: 一括請求 (コンソリデーティッドビリング) にサインアップする場合、各アカウントについて AWS 無料利用枠が適用されますか?

いいえ。複数のアカウントのお支払いを統合する一括請求 (コンソリデーティッドビリング) をご利用のお客様も、ご利用いただける無料利用枠は 1 つの組織につき 1 つのみです。

Q: 複数のリージョンにわたって使用しており、無料利用枠を超えた場合はどうなりますか?

1 TB のデータ転送と 1,000 万件の Get リクエストは、すべてのエッジロケーションにおける毎月の無料利用枠の制限です。使用量が毎月の無料利用枠の制限を超える場合は、各リージョンの AWS の標準オンデマンドサービス料金をお支払いいただきます。料金の詳細については、AWS CloudFront の料金のページをご覧ください。

Q: 無料利用枠の使用状況はどのように知ることができますか?

現在および過去の使用アクティビティをリージョン別に確認するには、アカウントにログインし、請求とコスト管理のダッシュボードにアクセスします。ダッシュボードからは、AWS Budgets を使用したコストおよび使用状況の管理、Cost Explorer を使用したコストドライバーや使用状況の傾向の可視化、Cost and Usage Reports を使用したコストの詳細な分析が可能です。 AWS コストを管理する方法の詳細については、AWS コストの管理の 10 分間のチュートリアルをご覧ください。

Q: 無料利用枠は CloudFront Security Savings バンドルにサブスクライブしているお客様に適用されますか?

CloudFront Security Savings バンドルにサブスクライブしているお客様も、無料利用枠の恩恵を受けることができます。無料利用枠に照らして CloudFront Security Savings バンドルに対するコミットメントを引き下げる必要があると思われる場合は、カスタマーサービスまでお問い合わせいただければ、当社で変更のリクエストを評価します。これについては、数日中に詳細をお知らせします。続報をお待ちください。 

その他の質問については、https://aws.amazon.com/free/free-tier-faqs/ をご覧ください。

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

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

AWS 無料利用枠を使用すると、Amazon CloudFront の使用を無料で開始し、使用量を増やしながら料金を抑えることができます。すべての CloudFront のお客様は、これらの制限を超えた場合でも、1 TB のデータ転送 (アウト) と 10,000,000 件の HTTP および HTTPS リクエスト (Amazon CloudFront 向け) を無料でご利用いただけます。以下の各場合をご覧ください。 

• インターネットへのデータ転送 (アウト)
  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の場合でも、お客様が選択した価格クラスに含まれないロケーションのエッジロケーションからコンテンツが配信される可能性があることをご了承ください。このことが発生したときは、お客様への請求には、選択された料金クラス内で最も低料金のロケーションの単価が適用されます。

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

Q:CloudFront Security Savings Bundle とは何ですか?

CloudFront Security Savings Bundle は、柔軟なセルフサービスの料金プランであり、1 年間の月額使用量 (例: 100 USD/月) を一定にすることと引き換えに、CloudFront の請求額を最大 30% 節約できます。  追加のベネフィットとして、CloudFront リソースを保護するための AWS WAF (Web Application Firewall) の使用量 (確約プラン量の最大 10%) が追加料金なしで含まれています。 たとえば、月額 100 USD の CloudFront 使用量を確約量に指定すると、142.86 USD 相当の CloudFront 使用量が対象範囲となり、標準料金と比べて 30% を節約できます。さらに、毎月追加料金なしで CloudFront リソースを保護するための AWS WAF 使用量が最大 10 USD 含まれています (CloudFront 確約量の最大 10%)。  標準の CloudFront および AWS WAF の料金は、毎月の支出確約量の対象範囲となる金額を超えて使用する場合に適用されます。  使用量が増えるにつれて、追加の Savings Bundle を購入して、使用量の増分に対して割引を適用することができます。 

Q: CloudFront Security Savings Bundle の対象となる使用法の種類には何がありますか?

CloudFront Security Savings Bundle を購入すると、毎月の請求書の CloudFront サービス部分に表示される金額の 30% を節約できます。これにより、データ転送、オリジンへのデータ転送、HTTP/S リクエスト料金、フィールドレベルの暗号化リクエスト、オリジンシールド、無効化、専用 IP カスタム SSL、Lambda@Edge 料金などの CloudFront 請求使用タイプが相殺されます。  また、CloudFront ディストリビューションに関連する AWS WAF の使用が対象範囲となる追加のベネフィットも提供されます。 

Q: CloudFront Security Savings Bundle を使用するにはどうすればよいですか?
CloudFront コンソールにアクセスして CloudFront と AWS WAF の過去の使用量に基づいた確約量に関する推奨事項を確認するか、独自の推定月間使用量を入力することで、CloudFront Security Savings Bundle の使用を開始できます。CloudFront Security Savings Bundle の月額費用とオンデマンド費用を比べ、推定節約額を確認して、ニーズに合った適切なプランに決めてください。  Savings Bundle にサインアップすると、毎月の確約量が請求され、CloudFront と WAF の使用料を相殺するクレジットが表示されます。  標準サービス料金は、毎月の支出確約量の対象範囲となる金額を超えて使用する場合に適用されます。 

Q: CloudFront Security Savings Bundle 契約が 1 年後に期限切れになるとどうなりますか?

CloudFront Security Savings Bundle の期間が満了すると、CloudFront と AWS WAF の使用に標準サービス料金が適用されます。   毎月の Savings Bundle 確約量は請求されなくなり、Savings Bundle のベネフィットが適用されなくなります。  バンドル期間が満了する前であればいつでも、CloudFront Security Savings Bundle をさらに 1 年間自動更新するようにオプトインを選択できます。

Q: CloudFront Security Savings Bundle は AWS Organizations/一括請求 (コンソリデーティッドビリング) とどのように連携しますか?

CloudFront Security Savings Bundle は、AWS Organizations/一括請求 (コンソリデーティッドビリング) ファミリー内の任意のアカウントで購入できます。  CloudFront Security Savings Bundle のベネフィットは、請求書のクレジットとして適用されます。Savings Bundle によって提供されるベネフィットは、デフォルトで AWS Organizations/一括請求 (コンソリデーティッドビリング) ファミリー内のすべてのアカウントでの使用に適用され (クレジット共有がオンになっている)、その詳細はサブスクライブするアカウントが組織に参加または退会する時期によって異なります。  AWS クレジットが単一アカウントおよび複数のアカウントにどのように適用されるかについては、AWS クレジットをご覧ください。

Q: 複数の CloudFront Security Savings Bundle を同時にアクティブにすることはできますか?

はい、使用量が増えるにつれて追加の CloudFront Security Savings Bundle を購入して、使用量の増分に割引を適用することができます。   AWS の請求額を計算する際には、アクティブな CloudFront Security Savings Bundle がすべて考慮されます。

Q: CloudFront Security Savings Bundle は請求書にどのように表示されますか?

毎月の確約料金は、請求書の別の CloudFront Security Bundle セクションに表示されます。  CloudFront Security Bundle の節約対象となる使用量は、標準の使用料を相殺するためのクレジットとして、請求書の CloudFront 部分と WAF 部分の両方に表示されます。

Q: 使用量が CloudFront Security Savings Bundle の毎月の確約量を超えた場合に通知を受け取ることはできますか?

はい。AWS Budgets を使用すれば、コストと使用量のしきい値を設定し、実際の料金または予測料金がしきい値を超えたときに、E メールまたは Amazon SNS トピックで通知を受け取ることができます。  CloudFront サービス用にフィルタリングされたカスタム AWS Budgets を作成し、予算のしきい値を CloudFront Security Savings Bundle 対象範囲内の CloudFront オンデマンド使用量に設定して、しきい値を超えたときに通知を受信することができます。   予算の詳細については、AWS 請求情報とコスト管理のユーザーガイドから Managing your costs with AWS Budgets と Creating a budget を参照してください。

Q: WAF 請求書のどの部分が CloudFront Security Savings Bundle の対象になりますか?

CloudFront Security Savings Bundle の追加のベネフィットとして、CloudFront リソースを保護するための AWS WAF の使用量 (確約プラン量の最大 10%) が追加料金なしで含まれています。CloudFront Security Savings Bundle の対象範囲を超えて使用する場合は、標準の CloudFront および AWS WAF 料金が適用されます。  AWS Marketplace を通じてサブスクライブされたマネージド WAF ルールは、CloudFront Security Savings Bundle の対象外です。

Q: CloudFront のカスタム料金契約を既に締結している場合、CloudFront Security Savings Bundle もサブスクライブできますか?

どちらか一方のみをサブクライブできます。  カスタム料金の契約についてご質問がある場合は、AWS アカウントマネージャーにお問い合わせください。

Q: API を介して CloudFront Security Savings Bundle をサブスクライブできますか?

CloudFront Security Savings Bundle は、CloudFront コンソールからのみサブスクライブできます。  将来の拡張機能として、API を通じての利用を評価する予定です。