Amazon CloudFront についてのよくある質問

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

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

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

Amazon CloudFront では、コンテンツ配信にエッジロケーションとリージョン別エッジキャッシュのグローバルなネットワークを使用しています。Amazon CloudFront のロケーションの詳細なリストについては、こちらをご覧ください。

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

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

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

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

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

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

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

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

CloudFront の埋め込み Point of Presence (POP) は、インターネットサービスプロバイダー (ISP) およびモバイルネットワーク事業者 (MNO) のネットワーク内で、エンドビューワーに最も近い場所にデプロイされるタイプの CloudFront インフラストラクチャです。埋め込み POP は、大規模なライブストリーミングイベント、ビデオオンデマンド (VOD)、ゲームのダウンロードを配信するためにカスタム構築されています。これらの埋め込み POP は、エンドビューワーをコンテンツソースに接続する、混雑したネットワークでのキャパシティのボトルネックを回避し、パフォーマンスを向上させるため Amazon が所有し、運用しています。また、ISP/MNO ネットワークのラストマイルにデプロイされています。

CloudFront 埋め込み POP は、デプロイされる場所と配信されるコンテンツが CloudFront POP とは異なります。CloudFront 埋め込み POP は、AWS ネットワーク内にデプロイされる CloudFront POP とは異なり、ISP および MNO ネットワークに直接デプロイされます。埋め込み POPは、ビデオストリームやゲームのダウンロードなどの大規模でキャッシュ可能なトラフィックを配信するために構築されています。一方、CloudFront POPは、キャッシュ可能なコンテンツと動的コンテンツの両方を含むさまざまなワークロードを配信するために設計されています。

CloudFront 埋め込み POP は、大規模なライブビデオストリーミング、ビデオオンデマンド、ゲームのダウンロードなど、多くのエンドビューワーが同時にアクセスするキャッシュ可能なコンテンツを配信するために設計されています。

いいえ。CloudFront 埋め込み POP の使用に対して、追加料金は発生しません。

埋め込み POP は、大規模でキャッシュ可能なトラフィックの配信を目的としたオプトイン機能です。埋め込み POP がワークロードに適しているかどうかを評価するには、AWS 営業担当者にお問い合わせください。

いいえ、埋め込み POP 用に新しいディストリビューションを作成する必要はありません。ワークロードが対象となる場合、CloudFront でリクエストに応じて既存のディストリビューションの埋め込み POP を有効にします。

コンテンツ配信の際、CloudFront 埋め込み POP と CloudFront POP のどちらかを選択する必要はありません。CloudFront ディストリビューションで埋め込み POP を有効にすると、CloudFront のルーティングシステムにより CloudFront POP と埋め込み POP の両方を動的に利用してコンテンツが配信されます。これにより、エンドユーザーへの最適なパフォーマンスが保証されます。

ネットワークへの埋め込み POP のデプロイを開始するには、当社にお問い合わせください。

埋め込み POP ポータルを使用することで、ネットワーク内にデプロイされた埋め込み POP を管理できます。埋め込み POP ポータルは AWS Interconnect Portal と統合されており、これらの POP のライフサイクル全体に関連するさまざまなタスクを簡単に実行するための統一されたインターフェイスを提供します。これには、新しいアプライアンスのリクエスト、リクエストの進捗状況の追跡、パフォーマンス統計のモニタリング、サポートのリクエストが含まれます。PeeringDB アカウントを使用してシングルサインオン (SSO) で認証することで、ポータルにアクセスできます。

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

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

Amazon CloudFront (CloudFront 埋め込み POP によるコンテンツ配信を除く) は SOC (システムおよび組織管理) 対策に準拠しています。(SOC) レポートは、重要なコンプライアンス管理および目標を AWS がどのように達成したかを実証する、独立したサードパーティーによる審査報告書です。 詳細については、「AWS SOC コンプライアンス」およびデベロッパー向けのガイドをご覧ください。

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

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

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

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

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

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

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

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

顧客が常に求めているのは、より高速で安全なアプリケーションをエンドユーザーに提供することです。インターネットの普及率が世界的に高まり、モバイルやリモートネットワークからオンラインにアクセスするユーザーが増えるのに伴って、パフォーマンスと信頼性の向上に対するニーズがこれまで以上に高まっています。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 の上に構築されています。
    

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

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 をサポートするすべての主要なブラウザによって実装されています。

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

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

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

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

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

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

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

gRPC は、長時間保持された HTTP/2 接続経由でクライアントとサーバー間の双方向通信を可能にする、最新のオープンソースリモートプロシージャコール (RPC) フレームワークです。永続的なオープン接続を使用することで、クライアントとサーバーは、クライアントが頻繁に接続を再初期化して、交換する新しいデータを確認することなく、リアルタイムデータを相互に送信できます。gRPC は、リアルタイム通信アプリケーションやオンラインゲームなど、低レイテンシーと高速転送が重要なユースケースに適しています。

gRPC は、CloudFront ディストリビューションの各キャッシュ動作で有効になっています。gRPC を有効にすることで、HTTP/2 と POST リクエストのサポートの両方もディストリビューションで有効になっているようにできます。gRPC は、HTTP/2 経由の POST メソッドのみをサポートします。

Amazon CloudFront は、次の条件が満たされた場合に gRPC 経由で通信します:

1. ディストリビューションで HTTP/2 が有効になっている
2. キャッシュ動作で POST リクエストと gRPC が有効になっている
3. クライアントが HTTP/2 接続経由で「application/grpc」の値を含む「content-type」ヘッダーを送信する

1. セキュリティ - gRPC は HTTP/2 を使用します。これにより、クライアントからオリジンサーバーまでのトラフィックがエンドツーエンドで暗号化されるようになります。さらに、gRPC を使用する場合は、追加料金なしで AWS Shield Standard を使用でき、AWS WAF を設定して gRPC トラフィックを攻撃から保護するのに役立てることができます。
2. パフォーマンスの改善 - gRPC は、プロトコルバッファと呼ばれるバイナリメッセージ形式を活用します。これは、RESTful API で使用される JSON などの従来のペイロードよりも小さいです。プロトコルバッファの解析は、データがバイナリ形式であるため CPU の負荷は少なめです。これは、メッセージの交換がより高速になることを意味します。これにより、全体的なパフォーマンスが改善します。
3. 組み込みのストリーミングサポート - ストリーミングは gRPC フレームワークに組み込まれており、クライアント側とサーバー側の両方のストリーミングセマンティクスをサポートします。これにより、ストリーミングサービスまたはクライアントの構築がはるかにシンプルになります。CloudFront での gRPC は、次のストリーミングの組み合わせをサポートしています:
   • 単項 (ストリーミングなし)
   • クライアントからサーバーへのストリーミング
   • サーバーからクライアントへのストリーミング
   • 双方向ストリーミング

現在はできません。CloudFront は HTTP/2 経由の gRPC のみをサポートします。

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

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

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

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

専用 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 のデータ転送とリクエストの料金のみでご利用いただけます。

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

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

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

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

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 で実行しているアプリケーションを標的とする大規模かつ高度な攻撃を防御できます。

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

CloudFront は、オリジンを保護するために 2 つのフルマネージドの方法を提供しています:

1. オリジンアクセスコントロール (OAC): CloudFront オリジンアクセスコントロール (OAC) は、Amazon Simple Storage Service (S3) オリジン、AWS Elemental オリジン、および Lambda 関数 URL に対するアクセスを制限し、CloudFront のみがコンテンツにアクセスできるようにするセキュリティ機能です。
2. VPC オリジン: CloudFront Virtual Private Cloud (VPC) オリジンを使用すると、Amazon CloudFront を使用して、VPC プライベートサブネットでホストされているアプリケーションからコンテンツを配信できます。CloudFront では、プライベートサブネット内の Application Load Balancer (ALB)、Network Load Balancer (NLB)、および EC2 インスタンスを VPC オリジンとして使用できます

CloudFront マネージドソリューションがユースケースの要件を満たさない場合は、代替アプローチを使用できます。以下にその一例を示します:

1. カスタムオリジンヘッダー: CloudFront を使用すると、着信リクエストにカスタムヘッダーを付加し、これらの特定のヘッダーの値を検証するようにオリジンを設定できます。これにより、CloudFront を通じてルーティングされたリクエストのみにアクセスを効果的に制限できます。この方法により、追加の認証レイヤーが作成され、オリジンに対する不正な直接アクセスのリスクが大幅に軽減されます。
2. IP 許可リスト: オリジンのセキュリティグループまたはファイアウォールを設定して、CloudFront の IP 範囲からの着信トラフィックのみを許可できます。AWS は、お客様の便宜のためにこれらの IP 範囲を維持し、定期的に更新します。IP 許可リストの実装の詳細については、次の包括的なドキュメントをご覧ください: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list。このリソースは、最適なセキュリティ設定のために AWS のマネージドプレフィックスリストを活用するためのステップバイステップのガイダンスを提供します。
3. SSL/TLS 暗号化: CloudFront を設定して、オリジンとの HTTPS 接続のみを使用することで、CloudFront ディストリビューションとオリジン間の暗号化された通信を通じてエンドツーエンドのデータ保護を実現できます。

CloudFront Virtual Private Cloud (VPC) オリジンは、CloudFront を使用して VPC プライベートサブネットでホストされているアプリケーションからコンテンツを配信できるようにする新機能です。VPC オリジンを使用すると、アプリケーションを VPC 内のプライベートサブネットに配置できます。このアプリケーションには、CloudFront ディストリビューションを通じてのみアクセスできます。これにより、オリジンのために外部的に解決可能なドメインネームサービス (DNS) 名を設定する必要がなくなります。Application Load Balancer (ALB)、Network Load Balancer (NLB)、EC2 インスタンスで実行されるアプリケーションを使用して、VPC オリジンを設定できます。VPC オリジンは AWS 商用リージョンでのみ使用可能です。サポートされている AWS リージョンの詳細なリストは、こちらでご確認いただけます。

高いパフォーマンスとグローバルなスケーラビリティを維持しながら、ウェブアプリケーションのセキュリティを強化したい場合は、CloudFront を使用して VPC オリジンを使用すべきです。VPC オリジンを使用すると、シークレットヘッダーやアクセスコントロールリストなどの複雑な設定なしで、VPC 内のオリジンに対するアクセスを CloudFront ディストリビューションのみに制限できます。また、VPC オリジンを使用すると、コストのかからない内部 IPv4 IP アドレスを使用してプライベートサブネット内のオリジンにルーティングできるため、IPv4 のコストを最適化することもできます。VPC オリジンは、複雑なセキュリティ対策の管理ではなく、コアビジネスの成長に注力できるようにしてくれるため、セキュリティ管理を合理化したい場合に最適です。

1. セキュリティ - VPC オリジンを使用すると、ロードバランサーと EC2 インスタンスをプライベートサブネットに配置して、CloudFront を唯一のイングレスポイントにすることで、アプリケーションのセキュリティ体制を強化できます。ユーザーリクエストは、プライベートで安全な接続を介して CloudFront から VPC オリジンに送信されるため、アプリケーションのセキュリティがさらに強化されます。
2. 管理 - VPC オリジンを使用すると、パブリックアクセスのないプライベートサブネットにオリジンを移動でき、アクセスコントロールリスト、シークレット共有ヘッダー、またはオリジンに対するアクセスを制限する他のメカニズムを実装する必要がなくなるため、安全な CloudFront - オリジン接続に必要な運用上のオーバーヘッドが削減されます。これにより、差別化につながらない開発作業に投資することなく、CloudFront を使用してウェブアプリケーションを簡単に保護できます。
3. スケーラブルで高性能 - VPC オリジンを使用すると、お客様は、CloudFront のグローバルエッジロケーションと AWS バックボーンネットワークを使用でき、他の既存のコンテンツ配信方法と同様のスケールとパフォーマンスを享受しながら、セキュリティ体制を強化できます。このソリューションは、セキュリティ管理を合理化しながらグローバルアプリケーションをお客様に配信するため、CloudFront をアプリケーションの単一の玄関口として使用するのが簡単になります。

CloudFront Virtual Private Cloud (VPC) オリジンを使用すると、CloudFront を使用して、Application Load Balancer、Network Load Balancer、および EC2 インスタンスを使用して、VPC プライベートサブネットでホストされているアプリケーションからコンテンツを配信できます。Amazon VPC ブロックパブリックアクセス (VPC BPA) は、AWS が提供するインターネットパスを通じた着信 (イングレス) および発信 (エグレス) VPC トラフィックを権威的にブロックする、シンプルな宣言型コントロールです。VPC オリジンを使用してサブネットで VPC BPA を有効にすると、CloudFront からのアクティブな接続はそのサブネットに対して終了します。新しい接続はサブネットに対して送信されず、BPA が有効になっていない VPC オリジンが存在する他のサブネットにルーティングされるか、または VPC オリジンが存在するすべてのサブネットで BPA が有効になっている場合はドロップされます。

VPC オリジンは、Application Load Balancer、Network Load Balancer、および EC2 インスタンスをサポートしています。

いいえ。IPv6 は VPC プライベートオリジンではサポートされていません。VPC オリジンでは、プライベート IPv4 アドレスが必要です。これは無料で、IPv4 の料金はかかりません。

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

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

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

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

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

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

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

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

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

はい。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) にアクセスしてください。

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

詳細については、AWS ライブ動画ストリーミングのページにアクセスしてください。

Media-Quality Aware Resiliency (MQAR) は Amazon CloudFront と AWS メディアサービスの統合機能であり、動的に生成される動画品質スコアに基づいて、リージョン間のオリジンの自動選択とフェイルオーバーを行います。MQAR を使用すると、冗長な AWS メディアサービスのワークフローを 2 つの異なる AWS リージョンにデプロイして、回復力のあるライブイベント配信を実現できます。ディストリビューションで MQAR 機能を有効にすると、品質スコアが最も高いと見なされるオリジンを自動的に選択する権限が CloudFront に与えられます。品質スコアは、黒いフレーム、フリーズまたはドロップしたフレーム、繰り返されるフレームなど、オリジンから確認できるメディアストリーミングの品質上の問題を表します。たとえば、AWS Elemental MediaPackage v2 オリジンが 2 つの異なる AWS リージョンにデプロイされていて、一方で他方よりも高いメディア品質スコアが報告された場合、CloudFront はスコアが高いオリジンに自動的に切り替えます。この機能は、ライブイベントや 24 時間年中無休の番組チャンネルを配信するための常時監視をシミュレートするもので、視聴者に質の高い体験を提供できるように設計されています。MQAR の詳細については、CloudFront デベロッパーガイドをご覧ください。

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

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

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

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

Amazon CloudFront のエニーキャスト静的 IP は、世界中のすべての CloudFront エッジロケーションに接続できるようにする静的 IP アドレスのセットです。これらは、適切な契約が締結されている場合に特定の IP アドレスについてネットワークプロバイダーがデータ料金を免除するゼロレート課金や、セキュリティ体制を強化するためのクライアント側の許可リスト作成などのユースケースのために使用できる、小規模で静的な IP のリストを提供します。エニーキャスト静的 IP を使用すると、許可リストや IP マッピングを常に更新するという運用上の課題がなくなります。なぜなら、同じ IP セットが CloudFront のグローバルネットワーク全体で機能し、CloudFront のすべての機能から恩恵を享受できるからです。

エニーキャスト静的 IP を有効にするには、まず AWS アカウントでエニーキャスト静的 IP リストをリクエストして作成する必要があります。リストが作成されたら、CloudFront ディストリビューションをエニーキャスト静的 IP リストに関連付けることができます。これは、AWS コンソールのエニーキャスト静的 IP セクションを通じて行うことも、各ディストリビューションを編集して、ドロップダウンメニューから目的のエニーキャスト静的 IP リストを選択することで行うこともできます。これらの変更を保存すると、ディストリビューションに関連付けられた特定の静的 IP アドレスのセットを、AWS コンソールに表示されるリストから、または API 経由で、コピーまたはダウンロードできるようになります。

CloudFront エニーキャスト静的 IP を有効にすると、IPv4 の IP アドレスを 21 個受け取ります。これらの IP アドレスをすべて、関連する許可リストに追加する必要があります。

いいえ。CloudFront エニーキャストは、地理的に分散した IP でのみ使用できます。

CloudFront が新しいエッジロケーションを追加しても、エニーキャスト静的 IP リストは引き続き有効です。必要に応じて、新しいエッジロケーションから IP をアナウンスします。

CloudFront のすべての機能はエニーキャストと連携しますが、3 つの重要な例外があります: 1) エニーキャスト静的 IP は SNI をサポートできないレガシークライアントをサポートしません。2) エニーキャスト静的 IP を使用する場合は料金クラス All を使用する必要があります。3) エニーキャスト静的 IP を使用する場合は IPv6 を無効にする必要があります。エニーキャスト静的 IP は DNS 解決段階で機能し、リクエストがホストに到達すると、既存のすべての機能と他の AWS サービスとの統合が引き続きディストリビューションで使用できるようになります。

エニーキャスト静的 IP は複数のディストリビューションで使用できますが、それらは同じアカウント内にある必要があります。CloudFront エニーキャスト静的 IP は、アカウント内の複数のディストリビューションに関連付けることができます。エニーキャスト静的 IP ポリシーに関連付けられた任意の数のディストリビューションから正しい証明書が返されるように、CloudFront エニーキャスト静的 IP は Server Name Indication (SNI) をサポートします。アカウント内の複数のディストリビューションのために個別の静的 IP を設定したい場合は、追加のエニーキャスト静的 IP リストを作成し、それらを特定のディストリビューションに関連付けることができます。

エニーキャスト静的 IP が有効になっているアカウントで新しいディストリビューションを作成する場合は、新しいディストリビューションを既存のエニーキャスト静的 IP リストに明示的に関連付ける必要があります。デフォルトでは、静的 IP リストにリンクするまで、動的 IP アドレスが使用されます。

はい。こちらで制限の引き上げリクエストを完了してください。その後、当社は 2 営業日以内にお客様のアカウントにキャパシティをさらに追加します。

AWS アカウントごとに作成できるディストリビューション数の現在の制限については、「Amazon Web Services 全般のリファレンス」の「Amazon CloudFront Limits」をご覧ください。制限の引き上げをリクエストするには、CloudFront 制限引き上げフォームにアクセスしてください。

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

1. 標準ログ (アクセスログ) CloudFront 標準ログは、ディストリビューションに対して実行されたあらゆるリクエストに関する詳細な記録を提供します。これらのログは、セキュリティやアクセス監査など、多くのシナリオで役立ちます。
2. リアルタイムログ CloudFront リアルタイムログは、ディストリビューションに対して実行されたリクエストに関する情報をリアルタイムで提供します (ログレコードは、リクエストを受信してから数秒以内に配信されます)。リアルタイムログのサンプリング率、すなわち、リアルタイムのログレコードを受信するリクエストの割合を選択できます。
3. エッジ関数のログ記録: Amazon CloudWatch Logs を使用して、Lambda@Edge と CloudFront Functions の両方のエッジ関数のログを取得できます。CloudWatch コンソールまたは CloudWatch Logs API を使用してログにアクセスできます。詳細については、「エッジ関数のログ」をご覧ください。
4. サービスアクティビティのログ記録: AWS CloudTrail を使用して、AWS アカウントの CloudFront サービスアクティビティ (API アクティビティ) をログ記録できます。CloudTrail は、CloudFront でユーザー、ロール、または AWS サービスによって実行された API アクションのレコードを提供します。CloudTrail によって収集された情報を使用して、CloudFront に対して実行された API リクエスト、リクエスト元の IP アドレス、リクエストを実行したユーザー、リクエストが実行された日時、および他の詳細を特定できます。詳細については、「AWS CloudTrail を使用した Amazon CloudFront API コールのログ記録」をご覧ください。

• CloudFront 標準ログは、任意の Amazon S3 バケット、Amazon CloudWatch ログ、Amazon Data Firehose に配信されます。詳細については、「Use standard logs (access logs)」をご覧ください。
• CloudFront リアルタイムログは、Amazon Kinesis Data Streams の任意のデータストリームに配信されます。CloudFront は、Kinesis Data Streams の使用に対して生じる料金に加えて、リアルタイムログの料金を請求します。詳細については、「リアルタイムログを使用する」をご覧ください。
• CloudFront エッジ関数ログ (Lambda@Edge および CloudFront Functions) は、Amazon CloudWatch ログに配信されます

CloudFront の標準アクセスログは、Amazon S3、Amazon CloudWatch、Amazon Data Firehose に配信できます。出力ログの形式 (プレーン、w3c、JSON、csv、parquet) を選択できます。ログ記録するフィールドと、それらのフィールドをログに含める順序を選択できます。S3 に配信されるログの場合、S3 に配信されるログのパーティショニングを有効にすることもできます。すなわち、ログが 1 時間ごとまたは 1 日ごとに自動的にパーティショニングされるように設定します。また、AWS リージョンのオプトインで、標準アクセスログを S3 バケットに配信することもできます。詳細については、「CloudFront デベロッパーガイド」の「Standard Access logs」セクションをご覧ください。

CloudFront では、標準ログを有効にするのに料金はかかりませんが、ログの配信先に応じて、ログの配信、保存、アクセスに料金がかかります。詳細については、CloudFront の料金ページの「追加機能」セクションをご覧ください。

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

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

はい。アカウントで実行した Amazon CloudFront API コールの履歴を取得するために必要なのは、CloudTrail の AWS マネジメントコンソールで AWS CloudTrail をオンにすることだけです。詳細については、AWS CloudTrail のホームページにアクセスしてください。

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

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

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 エンドポイントへのデータ配信に対応しています。

シャードの必要数を見積もるには、次の手順を使用してください。

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 個のシャードを作成するようにしてください。

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

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

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

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

CloudFront KeyValueStore は、グローバルで低レイテンシーのフルマネージド型のキーバリューデータストアです。KeyValueStore を使用すると、CloudFront Functions 内からキー値データを取得できるため、独立したデータ更新が可能になり、機能をさらにカスタマイズできます。キー値データへはすべての CloudFront エッジロケーションからアクセスでき、CloudFront Functions 内からの高速読み取りが可能で非常に効率的なインメモリキー値ストアを提供します。

CloudFront KeyValueStore は、次のように、エッジロケーションでの頻繁な読み取りや、低頻度の更新には理想的です。

• URL の書き換えとリダイレクトを管理: 位置情報に基づいてユーザーを特定の国のサイトにリダイレクトします。これらの地理ベースの URL を KeyValueStore に保存して更新すると、URL の管理が簡単になります。
• A/B テストと機能フラグ: あるバージョンのウェブサイトに一定割合のトラフィックを割り当てて、実験を実行します。テストウェイトは、関数コードや CloudFront ディストリビューションを更新せずに更新できます。
• アクセス認可: HMAC トークンや JSON ウェブトークン (JWT) などのユーザー生成トークンを作成して検証し、リクエストを許可または拒否することで、CloudFront を通じて配信されるコンテンツへのアクセスコントロールと認可を実装します。 

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

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

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 分離ベースのモデルよりも安全であると考えられています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

継続的デプロイ機能は、すべての CloudFront エッジロケーションで追加コストなしで利用できます。

インターネットに接続されるすべてのサーバーとデバイスは、数値のインターネットプロトコル (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 のようになります。

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

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

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を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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 上限引き上げフォームに入力してください。

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

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

1 KB のログサイズで 1,000 件/秒に対応するディストリビューションをお持ちで、米国東部 (オハイオ) にシャード 2 個で Kinesis Data Stream を作成するとします。

Kinesis Data Stream の 1 か月あたりのコスト: こちらの 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/月

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

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

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

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

各料金クラスを構成する場所の一覧については、こちらをご覧ください。

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 を購入して、使用量の増分に対して割引を適用することができます。 

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

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

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

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

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

毎月の確約料金は、請求書の別の CloudFront Security Bundle セクションに表示されます。  CloudFront Security Bundle のコスト削減でカバーされる使用は、標準の使用料を相殺するためのクレジットとして、請求書の CloudFront 部分と WAF 部分の両方に表示されます。  

はい。AWS Budgets を使用することで、コストと使用量のしきい値を設定し、実際の料金または予測料金がしきい値を超えたときに、E メールまたは Amazon SNS トピックで通知を受け取ることができます。  CloudFront サービス用にフィルタリングされたカスタム AWS Budgets を作成し、予算のしきい値を CloudFront Security Savings Bundle 対象範囲内の CloudFront オンデマンド使用量に設定して、しきい値を超えたときに通知を受信することができます。   予算の詳細については、AWS Billing and Cost Management ユーザーガイドの「AWS Budgets によるコストの管理」と「予算の作成」をご覧ください。 

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

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

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