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

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.thinkwithwp.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 の料金はかかりません。

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

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 アドレスが使用されます。

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 の料金ページの「追加機能」セクションをご覧ください。

ユースケースに応じて宛先を選択できます。時間に制限のあるユースケースで、数秒以内にすばやくログデータを入手する必要がある場合は、リアルタイムログを選択します。リアルタイムログのパイプラインをより安価に利用するには、特定のキャッシュ機能についてのみログを有効化する、またはサンプリングレートを低くするなどして、ログデータをフィルタリングできます。リアルタイムパイプラインは早急なデータ提供のために構築されます。そのため、データに遅延が生じると、ログレコードがドロップされることがあります。一方、リアルタイムデータを取得する必要はなく、低コストのログ処理ソリューションを必要としている場合は、現在の標準ログオプションが最適な選択肢となります。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 個のシャードを作成するようにしてください。