# アクセスログ (標準ログ)
CloudFront で受信するすべてのユーザー (ビューワー) リクエストに関する詳細情報を含むログファイルを作成するように CloudFront を設定できます。これらは、*アクセスログ*と呼ばれます。また、*標準ログ*とも呼ばれています。
各ログには、リクエストの受信時刻、処理時間、リクエストパス、サーバーレスポンスなどの情報が含まれます。これらのアクセスログを使用して、応答時間の分析や問題のトラブルシューティングを行うことができます。
次の図は、オブジェクトのリクエストに関する情報が CloudFront によってログ記録されるしくみを示しています。この例では、Amazon S3 バケットにアクセスログを送信するようにディストリビューションを設定しています。
![\[アクセスログの基本フロー\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/images/Logging.png)
1. この例には、2 つのウェブサイト (A、B) と 2 つの対応する CloudFront ディストリビューションがあります。ユーザーは、ディストリビューションに関連付けられている URL を使用してオブジェクトをリクエストします。
1. CloudFront は、各リクエストを適切なエッジロケーションにルーティングします。
1. CloudFront は、各リクエストに関するデータを、そのディストリビューション専用のログファイルに書き込みます。この例では、ディストリビューション A に関連するリクエストの情報はディストリビューション A のログファイルに書き込まれます。ディストリビューション B に関連するリクエストの情報はディストリビューション B のログファイルに書き込まれます。
1. ログ記録を有効にした際に指定した Amazon S3 バケットに、ディストリビューションのログファイルが CloudFront によって定期的に保存されます。後続のリクエストに関する情報は、CloudFront によってディストリビューションの新しいログファイルに保存されます。
ビューワーが、特定の時間内にコンテンツにアクセスしなかった場合、その時間内のログファイルは受信しません。
**注記**
ログは、すべてのリクエストを完全に課金するためのものではなく、コンテンツに対するリクエストの本質を把握するものとして使用することをお勧めします。CloudFront はベストエフォートベースでアクセスログを提供します。特定のリクエストのログエントリが、リクエストが実際に処理されてからかなり後に配信されることも、(まれに) 一切配信されないこともあります。ログエントリをアクセスログから省略すると、アクセスログ内のエントリ数は AWS の請求と使用状況レポートに表示される使用量と一致しなくなります。
CloudFront は、2 つのバージョンの標準ログ記録をサポートしています。標準ログ記録 (レガシー) は、Amazon S3 *のみ*へのアクセスログの送信をサポートしています。標準ログ記録 (v2) は、その他の配信先もサポートしています。ディストリビューションには、両方またはいずれかのログ記録オプションを設定できます。詳細については、以下の各トピックを参照してください。
**Topics**
+ [
# 標準ログ記録 (v2) を設定する
](standard-logging.md)
+ [
# 標準ログ記録 (レガシー) を設定する
](standard-logging-legacy-s3.md)
+ [
# 標準ログ記録リファレンス
](standard-logs-reference.md)
**ヒント**
CloudFront は、リアルタイムのアクセスログも提供します。これにより、ディストリビューションに対して行われたリクエストに関する情報がリアルタイムで提供されます (ログはリクエストを受信してから数秒以内に配信されます)。リアルタイムのアクセスログを使用して、コンテンツ配信のパフォーマンスに基づいて監視、分析、アクションを実行できます。詳細については、「[リアルタイムのアクセスログを使用する](real-time-logs.md)」を参照してください。
# 標準ログ記録 (v2) を設定する
ディストリビューションを作成または更新するとき、アクセスログ (標準ログ) を有効にできます。標準ログ記録 (v2) には、以下の機能が含まれています。
+ アクセスログを Amazon CloudWatch Logs、Amazon Data Firehose、Amazon Simple Storage Service (Amazon S3) に送信します。
+ 必要なログフィールドを選択します。[リアルタイムのアクセスログフィールドのサブセット](#standard-logging-real-time-log-selection)を選択することもできます。
+ 追加の[出力ログファイル](#supported-log-file-format)形式を選択します。
Amazon S3 を使用している場合は、以下のオプション機能を利用できます。
+ ログをオプトイン AWS リージョン に送信します。
+ パーティショニングを使用してログを整理します。
+ Hive 互換ファイル名を有効にします。
詳細については、「[Amazon S3 にログを送信する](#send-logs-s3)」を参照してください。
標準ログ記録の使用を開始するには、次の手順を実行します。
1. ログの受信先として指定する AWS のサービスに必要なアクセス許可を設定します。
1. CloudFront コンソールまたは CloudWatch API を使用して標準ログ記録を設定します。
1. アクセスログを表示します。
**注記**
標準ログ記録 (v2) を有効にしても、標準ログ記録 (レガシー) には影響や変更はありません。標準ログ記録 (v2) を使用しながら、標準ログ記録 (レガシー) も引き続きディストリビューションで使用できます。詳細については、「[標準ログ記録 (レガシー) を設定する](standard-logging-legacy-s3.md)」を参照してください。
標準ログ記録 (レガシー) を既に有効にしていて、Amazon S3 への標準ログ記録 (v2) を有効にする場合は、*別の* Amazon S3 バケットを指定するか、同じバケット内の*別のパス*を使用する (例: ログプレフィックスやパーティショニングを使用する) ことをお勧めします。これにより、どのログファイルがどのディストリビューションに関連付けられているかを追跡し、ログファイルが互いに上書きされるのを防ぐことができます。
## アクセス許可
CloudFront は CloudWatch 提供のログを使用してアクセスログを配信します。そのためには、ログ記録を配信できるように、指定した AWS のサービスへのアクセス許可が必要です。
各ログ記録先への必要なアクセス許可を確認するには、「*Amazon CloudWatch Logs User Guide*」の以下のトピックから選択します。
+ [CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs)
+ [Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-Firehose) –
+ [Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-S3)
ログ記録先へのアクセス許可を設定したら、ディストリビューションの標準ログ記録を有効にできます。
**注記**
CloudFront は、複数の異なる AWS アカウント (クロスアカウント) へのアクセスログの送信をサポートしています。クロスアカウント配信を有効にするには、両方のアカウント (自分のアカウントと受信アカウント) に該当するアクセス許可が必要です。詳細については、「[クロスアカウント配信の標準ログ記録を有効にする](#enable-standard-logging-cross-accounts)」セクションまたは「*Amazon CloudWatch Logs User Guide*」の「[Cross-account delivery example](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#vended-logs-crossaccount-example)」を参照してください。
## 標準ログ記録を有効にする
標準ログ記録を有効にするには、CloudFront コンソールまたは CloudWatch API を使用できます。
**Contents**
+ [
### 標準ログ記録を有効にする (CloudFront コンソール）
](#access-logging-console)
+ [
### 標準ログ記録を有効にする (CloudWatch API)
](#enable-access-logging-api)
### 標準ログ記録を有効にする (CloudFront コンソール）
**CloudFront ディストリビューションの標準ログ記録を有効にするには (コンソール)**
1. CloudFront コンソールを使用して、[既存のディストリビューションを更新します](HowToUpdateDistribution.md#HowToUpdateDistributionProcedure)。
1. **[Logging]** (ログ) タブを選択します。
1. **[追加]** を選択し、ログを受信するサービスを選択します。
+ CloudWatch Logs
+ Firehose
+ Amazon S3
1. **[送信先]** で、サービスのリソースを選択します。リソースをまだ作成していない場合は、**[作成]** を選択するか、次のドキュメントを参照することができます。
+ CloudWatch Logs の場合は、**[[ロググループ名]](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)** に入力します。
+ Firehose の場合は、**[[Firehose 配信ストリーム]](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html)** に入力します。
+ Amazon S3 の場合は、**[[バケット名]](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)** に入力します。
**ヒント**
プレフィックスを指定するには、バケット名の後にプレフィックスを入力します (例: `amzn-s3-demo-bucket.s3.amazonaws.com/MyLogPrefix`)。プレフィックスを指定しないと、CloudFront が自動的にプレフィックスを追加します。詳細については、「[Amazon S3 にログを送信する](#send-logs-s3)」を参照してください。
1. **[追加設定 – *オプション*]** で、以下のオプションを指定できます。
1. **[フィールド選択]** で、送信先に配信するログのフィールド名を選択します。[アクセスログフィールド](standard-logs-reference.md#BasicDistributionFileFormat)と、[リアルタイムアクセスログフィールド](#standard-logging-real-time-log-selection)のサブセットを選択できます。
1. (Amazon S3 のみ) **[パーティショニング]** で、ログファイルデータをパーティション分割するパスを指定します。
1. (Amazon S3 のみ) **[Hive 互換ファイル形式]** でチェックボックスをオンにして、Hive 互換 S3 パスを使用できます。これにより、Hive 互換ツールへの新しいデータのロードを簡素化できます。
1. **[出力形式]** で、希望する形式を指定します。
**注記**
**[Parquet]** を選択した場合、このオプションではアクセスログを Apache Parquet に変換するための CloudWatch 料金が発生します。詳細については、[「CloudWatch 料金表」の「Vended Logs」セクション](https://aws.amazon.com/cloudwatch/pricing/)を参照してください。
1. **[フィールド区切り文字]** で、ログフィールドを区切る方法を指定します。
1. ディストリビューションを更新または作成するステップを完了します。
1. 別の送信先を追加するには、ステップ 3～6 を繰り返します。
1. **[ログ]** ページで、標準ログのステータスが、ディストリビューションの横で **[有効]** になっていることを確認します。
1. (オプション) Cookie ログ記録を有効にするには、**[管理]**、**[設定]** を選択し、**[cookie ログ記録]** をオンにしてから、**[変更を保存]** を選択します。
**ヒント**
cookie ログ記録は、ディストリビューションの*すべて*の標準ログ記録に適用されるグローバル設定です。この設定を個別の配信先で上書きすることはできません。
標準ログ記録の配信とログフィールドの詳細については、「[標準ログ記録リファレンス](standard-logs-reference.md)」を参照してください。
### 標準ログ記録を有効にする (CloudWatch API)
CloudWatch API を使用して、ディストリビューションの標準ログ記録を有効にすることもできます。
**注意事項**
CloudWatch API を呼び出して標準ログ記録を有効にする場合は、別の送信先へのクロスリージョン配信を有効にするときでも、米国東部 (バージニア北部) リージョン (`us-east-1`) を指定する必要があります。例えば、アクセスログを欧州 (アイルランド) リージョン (`eu-west-1`) の S3 バケットに送信する場合、`us-east-1` リージョンで CloudWatch API を使用します。
標準ログ記録に cookie を含めるための追加オプションがあります。CloudFront API の場合、これは `IncludeCookies` パラメータです。CloudWatch API を使用してアクセスログ記録を設定し、cookie を含めるように指定する場合は、CloudFront コンソールまたは CloudFront API を使用して cookie を含めるようにディストリビューションを更新する必要があります。そうしないと、CloudFront はログ送信先に cookie を送信できません。詳細については、「[cookie のログ作成](DownloadDistValuesGeneral.md#DownloadDistValuesCookieLogging)」を参照してください。
**ディストリビューションの標準ログ記録を有効にするには (CloudWatch API)**
1. ディストリビューションを作成したら、Amazon リソースネーム (ARN) を取得します。
ARN は、CloudFront コンソールの **[ディストリビューション]** ページで見つけるか、[GetDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_GetDistribution.html) API オペレーションを使用して見つけることができます。ディストリビューション ARN は次の形式に従います: `arn:aws:cloudfront::123456789012:distribution/d111111abcdef8`
1. 次に、CloudWatch [PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) API オペレーションを使用して、ディストリビューションの配信ソースを作成します。
1. 配信ソースの名前を入力します。
1. ディストリビューションの `resourceArn` を渡します。
1. `logType` で、収集するログのタイプとして `ACCESS_LOGS` を指定します。
1.
**Example AWS CLI put-delivery-source コマンドの例**
次に示すのは、ディストリビューションの配信ソースを設定する例です。
```
aws logs put-delivery-source --name S3-delivery --resource-arn arn:aws:cloudfront::123456789012:distribution/d111111abcdef8 --log-type ACCESS_LOGS
```
**出力**:
```
{
"deliverySource": {
"name": "S3-delivery",
"arn": "arn:aws:logs:us-east-1:123456789012:delivery-source:S3-delivery",
"resourceArns": [
"arn:aws:cloudfront::123456789012:distribution/d111111abcdef8"
],
"service": "cloudfront",
"logType": "ACCESS_LOGS"
}
}
```
1. [PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) API オペレーションを使用してログの保存先を設定します。
1. `destinationResourceArn` で、送信先の ARN を指定します。これは、CloudWatch Logs ロググループ、Firehose 配信ストリーム、Amazon S3 バケットのいずれかにすることができます。
1. `outputFormat` で、ログの出力形式を指定します。
1.
**Example AWS CLI put-delivery-destination コマンドの例**
次に示すのは、Amazon S3 バケットを配信先として設定する例です。
```
aws logs put-delivery-destination --name S3-destination --delivery-destination-configuration destinationResourceArn=arn:aws:s3:::amzn-s3-demo-bucket
```
**出力**:
```
{
"name": "S3-destination",
"arn": "arn:aws:logs:us-east-1:123456789012:delivery-destination:S3-destination",
"deliveryDestinationType": "S3",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:s3:::amzn-s3-demo-bucket"
}
}
```
**注記**
ログをクロスアカウント配信する場合は、[PutDeliveryDestinationPolicy](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestinationPolicy.html) API オペレーションを使用して AWS Identity and Access Management (IAM) ポリシーを送信先アカウントに割り当てる必要があります。IAM ポリシーは、あるアカウントから別のアカウントへの配信を許可します。
1. [CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) API オペレーションを使用して、配信ソースを、前のステップで作成した送信先にリンクします。この API オペレーションは、配信ソースを最終配信先と関連付けます。
1. `deliverySourceName` で、ソース名を指定します。
1. `deliveryDestinationArn` で、配信先の ARN を指定します。
1. `fieldDelimiter` で、各ログフィールドを区切る文字列を指定します。
1. `recordFields` で、必要なログフィールドを指定します。
1. S3 を使用している場合は、`enableHiveCompatiblePath` と `suffixPath` を使用するかどうかを指定します。
**Example AWS CLI create-delivery コマンドの例**
次に示すのは、配信を作成する例です。
```
aws logs create-delivery --delivery-source-name cf-delivery --delivery-destination-arn arn:aws:logs:us-east-1:123456789012:delivery-destination:S3-destination
```
**出力**:
```
{
"id": "abcNegnBoTR123",
"arn": "arn:aws:logs:us-east-1:123456789012:delivery:abcNegnBoTR123",
"deliverySourceName": "cf-delivery",
"deliveryDestinationArn": "arn:aws:logs:us-east-1:123456789012:delivery-destination:S3-destination",
"deliveryDestinationType": "S3",
"recordFields": [
"date",
"time",
"x-edge-location",
"sc-bytes",
"c-ip",
"cs-method",
"cs(Host)",
"cs-uri-stem",
"sc-status",
"cs(Referer)",
"cs(User-Agent)",
"cs-uri-query",
"cs(Cookie)",
"x-edge-result-type",
"x-edge-request-id",
"x-host-header",
"cs-protocol",
"cs-bytes",
"time-taken",
"x-forwarded-for",
"ssl-protocol",
"ssl-cipher",
"x-edge-response-result-type",
"cs-protocol-version",
"fle-status",
"fle-encrypted-fields",
"c-port",
"time-to-first-byte",
"x-edge-detailed-result-type",
"sc-content-type",
"sc-content-len",
"sc-range-start",
"sc-range-end",
"c-country",
"cache-behavior-path-pattern"
],
"fieldDelimiter": ""
}
```
1. CloudFront コンソールの **[ログ]** ページで、ディストリビューションの横で標準ログのステータスが **[有効]** になっていることを確認します。
標準ログ記録の配信とログフィールドの詳細については、「[標準ログ記録リファレンス](standard-logs-reference.md)」を参照してください。
**注記**
AWS CloudFormation を使用して CloudFront の標準ログ記録 (v2) を有効にするには、以下の CloudWatch Logs プロパティを使用できます。
[Delivery](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-delivery.html)
[DeliveryDestination](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverydestination.html)
[DeliverySource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverysource.html)
`ResourceArn` は CloudFront ディストリビューションであり、`LogType` は `ACCESS_LOGS` をサポートされているログタイプとする必要があります。
## クロスアカウント配信の標準ログ記録を有効にする
AWS アカウントの標準ログ記録を有効にし、アクセスログを別のアカウントに配信する場合は、送信元アカウントと送信先アカウントを正しく設定します。CloudFront ディストリビューションの*送信元アカウント*は、アクセスログを*送信先アカウント*に送信します。
この手順の例では、送信元アカウント (*111111111111*) がアクセスログを送信先アカウント (*222222222222*) の Amazon S3 バケットに送信します。アクセスログを送信先アカウントの Amazon S3 バケットに送信するには、AWS CLI を使用します。
### 送信先アカウントを設定する
送信先アカウントの場合は、次の手順を実行します。
**送信先アカウントを設定するには**
1. ログ配信先を作成するには、次の AWS CLI コマンドを入力します。この例では、`MyLogPrefix` 文字列を使用してアクセスログのプレフィックスを作成します。
```
aws logs put-delivery-destination --name cloudfront-delivery-destination --delivery-destination-configuration "destinationResourceArn=arn:aws:s3:::amzn-s3-demo-bucket-cloudfront-logs/MyLogPrefix"
```
**出力**:
```
{
"deliveryDestination": {
"name": "cloudfront-delivery-destination",
"arn": "arn:aws:logs:us-east-1:222222222222:delivery-destination:cloudfront-delivery-destination",
"deliveryDestinationType": "S3",
"deliveryDestinationConfiguration": {"destinationResourceArn": "arn:aws:s3:::amzn-s3-demo-bucket-cloudfront-logs/MyLogPrefix"}
}
}
```
**注記**
プレフィックス*なし*で S3 バケットを指定すると、CloudFront は `AWSLogs//CloudFront` をプレフィックスとして自動的に追加します。このプレフィックスは S3 配信先の `suffixPath` に表示されます。詳細については、「[S3DeliveryConfiguration](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_S3DeliveryConfiguration.html)」を参照してください。
1. ログ配信先のリソースポリシーを追加して、送信元アカウントでログ配信を作成できるようにします。
次のポリシーでは、*111111111111* を送信元アカウント ID に置き換え、ステップ 1 の出力から配信先 ARN を指定します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCreateDelivery",
"Effect": "Allow",
"Principal": {"AWS": "111111111111"},
"Action": ["logs:CreateDelivery"],
"Resource": "arn:aws:logs:us-east-1:222222222222:delivery-destination:cloudfront-delivery-destination"
}
]
}
```
------
1. ファイル (`deliverypolicy.json` など) を保存します。
1. 前のポリシーを配信先にアタッチするには、次の AWS CLI コマンドを入力します。
```
aws logs put-delivery-destination-policy --delivery-destination-name cloudfront-delivery-destination --delivery-destination-policy file://deliverypolicy.json
```
1. 次のステートメントを送信先の Amazon S3 バケットポリシーに追加し、リソース ARN と送信元アカウント ID を置き換えます。このポリシーは、`delivery.logs.amazonaws.com` サービスプリンシパルに `s3:PutObject` アクションの実行を許可します。
```
{
"Sid": "AWSLogsDeliveryWrite",
"Effect": "Allow",
"Principal": {"Service": "delivery.logs.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-cloudfront-logs/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": "111111111111"
},
"ArnLike": {"aws:SourceArn": "arn:aws:logs:us-east-1:111111111111:delivery-source:*"}
}
}
```
1. バケットに AWS KMS を使用している場合は、次のステートメントを KMS キーポリシーに追加して、`delivery.logs.amazonaws.com` サービスプリンシパルにアクセス許可を付与します。
```
{
"Sid": "Allow Logs Delivery to use the key",
"Effect": "Allow",
"Principal": {"Service": "delivery.logs.amazonaws.com"},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {"aws:SourceAccount": "111111111111"},
"ArnLike": {"aws:SourceArn": "arn:aws:logs:us-east-1:111111111111:delivery-source:*"}
}
}
```
### 送信元アカウントを設定する
送信先アカウントを設定したら、次の手順に従って配信ソースを作成し、送信元アカウントでディストリビューションのログ記録を有効にします。
**送信元アカウントを設定するには**
1. CloudFront 標準ログ記録の配信ソースを作成し、ログファイルを CloudWatch Logs に送信できるようにします。
次の AWS CLI コマンドを入力できます。名前とディストリビューション ARN は置き換えます。
```
aws logs put-delivery-source --name s3-cf-delivery --resource-arn arn:aws:cloudfront::111111111111:distribution/E1TR1RHV123ABC --log-type ACCESS_LOGS
```
**出力**:
```
{
"deliverySource": {
"name": "s3-cf-delivery",
"arn": "arn:aws:logs:us-east-1:111111111111:delivery-source:s3-cf-delivery",
"resourceArns": ["arn:aws:cloudfront::111111111111:distribution/E1TR1RHV123ABC"],
"service": "cloudfront",
"logType": "ACCESS_LOGS"
}
}
```
1. 送信元アカウントのログ配信元と送信先アカウントのログ配信先をマッピングする配信を作成します。
次の AWS CLI コマンドで、[「ステップ 1: 送信先アカウントを設定する」](#steps-destination-account)の出力から配信先 ARN を指定します。
```
aws logs create-delivery --delivery-source-name s3-cf-delivery --delivery-destination-arn arn:aws:logs:us-east-1:222222222222:delivery-destination:cloudfront-delivery-destination
```
**出力**:
```
{
"delivery": {
"id": "OPmOpLahVzhx1234",
"arn": "arn:aws:logs:us-east-1:111111111111:delivery:OPmOpLahVzhx1234",
"deliverySourceName": "s3-cf-delivery",
"deliveryDestinationArn": "arn:aws:logs:us-east-1:222222222222:delivery-destination:cloudfront-delivery-destination",
"deliveryDestinationType": "S3",
"recordFields": [
"date",
"time",
"x-edge-location",
"sc-bytes",
"c-ip",
"cs-method",
"cs(Host)",
"cs-uri-stem",
"sc-status",
"cs(Referer)",
"cs(User-Agent)",
"cs-uri-query",
"cs(Cookie)",
"x-edge-result-type",
"x-edge-request-id",
"x-host-header",
"cs-protocol",
"cs-bytes",
"time-taken",
"x-forwarded-for",
"ssl-protocol",
"ssl-cipher",
"x-edge-response-result-type",
"cs-protocol-version",
"fle-status",
"fle-encrypted-fields",
"c-port",
"time-to-first-byte",
"x-edge-detailed-result-type",
"sc-content-type",
"sc-content-len",
"sc-range-start",
"sc-range-end",
"c-country",
"cache-behavior-path-pattern"
],
"fieldDelimiter": "\t"
}
}
```
1. クロスアカウント配信が成功したことを確認します。
1. *source* アカウントから、CloudFront コンソールにサインインし、ディストリビューションを選択します。**[ログ記録]** タブの **[タイプ]** に、S3 クロスアカウントログ配信用に作成されたエントリが表示されます。
1. *destination* アカウントから、Amazon S3 コンソールにサインインし、Amazon S3 バケットを選択します。バケット名にプレフィックス `MyLogPrefix` と、そのフォルダに配信されたアクセスログが表示されます。
## 出力ファイル形式
選択した配信先に応じて、ログファイルに以下のいずれかの形式を指定できます。
+ JSON
+ Plain
+ w3c
+ Raw
+ Parquet (Amazon S3 のみ）
**注記**
出力形式を設定できるのは、配信先を初めて作成するときのみです。後で更新することはできません。出力形式を変更するには、配信を削除し、別の配信を作成します。
詳細については、「*Amazon CloudWatch Logs API Reference*」の「[PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html)」を参照してください。
## 標準ログ記録設定を編集する
[CloudFront コンソール](https://console.aws.amazon.com/cloudfront/v4/home)または CloudWatch API を使用して、ログ記録を有効または無効にしたり、他のログ設定を更新したりできます。ログ作成設定の変更は 12 時間以内に有効になります。
詳細については、以下の各トピックを参照してください。
+ CloudFront コンソールを使用してディストリビューションを更新するには、「[ディストリビューションを更新する](HowToUpdateDistribution.md)」を参照してください。
+ CloudFront API を使用してディストリビューションを更新するには、「*Amazon CloudFront API Reference*」の「[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)」を参照してください。
+ CloudWatch Logs の API オペレーションの詳細については、「[Amazon CloudWatch Logs API Reference](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/Welcome.html)」を参照してください。
## アクセスログフィールド
標準ログ記録 (レガシー) がサポートしているものと同じログフィールドを選択できます。詳細については、「[ログファイルフィールド](standard-logs-reference.md#BasicDistributionFileFormat)」を参照してください。
さらに、以下の[リアルタイムのアクセスログフィールド](real-time-logs.md#understand-real-time-log-config)を選択できます。
1. `timestamp(ms)` – タイムスタンプ (ミリ秒単位)。
1. `origin-fbl` – CloudFront とオリジン間の先頭バイトのレイテンシーの秒数。
1. `origin-lbl` – CloudFront とオリジン間の最終バイトのレイテンシーの秒数。
1. `asn` – ビューワーの AS 番号 (ASN)。
1. `c-country` – ビューワーの IP アドレスによって決定される、ビューワーの地理的位置を表す国コード。国コードの一覧については、「[ISO 3166-1 alpha-2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2)」を参照してください。
1. `cache-behavior-path-pattern` – ビューワーリクエストに一致したキャッシュ動作を識別するパスパターン。
## CloudWatch Logs にログを送信する
CloudWatch Logs にログを送信するには、CloudWatch Logs ロググループを作成するか、既存のものを使用します。CloudWatch Logs ロググループの設定の詳細については、「[Working with Log Groups and Log Streams](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)」を参照してください。
ロググループを作成したら、標準ログ記録を許可するために必要なアクセス許可が必要です。必要なアクセス許可の詳細については、「*Amazon CloudWatch Logs User Guide*」の「[Logs sent to CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs)」を参照してください。
**注意事項**
CloudWatch Logs ロググループの名前を指定する場合は、正規表現パターン `[\w-]` のみを使用します。詳細については、「*Amazon CloudWatch Logs API Reference*」の「[PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html#API_PutDeliveryDestination_RequestSyntax)」 API オペレーションを参照してください。
ロググループリソースポリシーがサイズ制限を超えていないことを確認します。CloudWatch Logs トピックの「[Log group resource policy size limit considerations](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs)」セクションを参照してください。
### CloudWatch Logs に送信されたアクセスログの例
```
{
"date": "2024-11-14",
"time": "21:34:06",
"x-edge-location": "SOF50-P2",
"asn": "16509",
"timestamp(ms)": "1731620046814",
"origin-fbl": "0.251",
"origin-lbl": "0.251",
"x-host-header": "d111111abcdef8.cloudfront.net",
"cs(Cookie)": "examplecookie=value"
}
```
## Firehose にログを送信する
Firehose にログを送信するには、Firehose 配信ストリームを作成するか、既存のものを使用します。次に、Firehose 配信ストリームをログ配信先として指定します。米国東部 (バージニア北部) us-east-1 リージョンで Firehose 配信ストリームを指定する必要があります。
配信ストリームの作成の詳細については、「[Creating an Amazon Data Firehose delivery stream](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html)」を参照してください。
配信ストリームを作成したら、標準ログ記録を許可するために必要なアクセス許可が必要です。詳細については「*Amazon CloudWatch Logs User Guide*」の「[Logs sent to Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-Firehose)」を参照してください。
**注記**
Firehose ストリームの名前を指定する場合は、正規表現パターン `[\w-]` のみを使用します。詳細については、「*Amazon CloudWatch Logs API Reference*」の「[PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html#API_PutDeliveryDestination_RequestSyntax)」 API オペレーションを参照してください。
### Firehose に送信されたアクセスログの例
```
{"date":"2024-11-15","time":"19:45:51","x-edge-location":"SOF50-P2","asn":"16509","timestamp(ms)":"1731699951183","origin-fbl":"0.254","origin-lbl":"0.254","x-host-header":"d111111abcdef8.cloudfront.net","cs(Cookie)":"examplecookie=value"}
{"date":"2024-11-15","time":"19:45:52","x-edge-location":"SOF50-P2","asn":"16509","timestamp(ms)":"1731699952950","origin-fbl":"0.125","origin-lbl":"0.125","x-host-header":"d111111abcdef8.cloudfront.net","cs(Cookie)":"examplecookie=value"}
```
## Amazon S3 にログを送信する
Amazon S3 にアクセスログを送信するには、S3 バケットを作成するか、既存のものを使用します。CloudFront でログ記録を有効にする場合は、バケット名を指定します。バケットの作成方法については、「*Amazon Simple Storage Service ユーザーガイド*」の「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)」を参照してください。
バケットを作成したら、標準ログ記録を許可するために必要なアクセス許可が必要です。詳細については「*Amazon CloudWatch Logs User Guide*」の「[Logs sent to Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-S3)」を参照してください。
+ ログ記録を有効にすると、必要なバケットポリシーを AWS が自動的に追加します。
+ [オプトイン AWS リージョン](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)で S3 バケットを使用することもできます。
**注記**
標準ログ記録 (レガシー) を既に有効にしていて、Amazon S3 への標準ログ記録 (v2) を有効にする場合は、*別の* Amazon S3 バケットを指定するか、同じバケット内の*別のパス*を使用する (例: ログプレフィックスやパーティショニングを使用する) ことをお勧めします。これにより、どのログファイルがどのディストリビューションに関連付けられているかを追跡し、ログファイルが互いに上書きされるのを防ぐことができます。
**Topics**
+ [
### S3 バケットを指定する
](#prefix-s3-buckets)
+ [
### パーティション
](#partitioning)
+ [
### Hive 互換ファイル名形式
](#hive-compatible-file-name-format)
+ [
### アクセスログへのパスの例
](#bucket-path-examples)
+ [
### Amazon S3 に送信されたアクセスログの例
](#example-access-logs-s3)
### S3 バケットを指定する
S3 バケットを配信先として指定する場合は、次の点に注意してください。
S3 バケット名には正規表現パターン `[\w-]` のみを使用できます。詳細については、「*Amazon CloudWatch Logs API Reference*」の「[PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html#API_PutDeliveryDestination_RequestSyntax)」 API オペレーションを参照してください。
S3 バケットにプレフィックスを指定している場合、ログはそのパスの下に表示されます。プレフィックスを指定しない場合、CloudFront は自動的に `AWSLogs/{account-id}/CloudFront` プレフィックスを追加します。
詳細については、「[アクセスログへのパスの例](#bucket-path-examples)」を参照してください。
### パーティション
CloudFront がアクセスログを S3 バケットに送信するときに、パーティショニングを使用してアクセスログを整理できます。これにより、必要なパスに基づいてアクセスログを整理して見つけることができます。
以下の変数を使用してフォルダパスを作成できます。
+ `{DistributionId}`-または-`{distributionid}`
+ `{yyyy}`
+ `{MM}`
+ `{dd}`
+ `{HH}`
+ `{accountid}`
任意の数の変数を使用し、パスにフォルダ名を指定できます。次に、CloudFront はこのパスを使用して S3 バケットにフォルダ構造を自動的に作成します。
**例**
+ `my_distribution_log_data/{DistributionId}/logs`
+ `/cloudfront/{DistributionId}/my_distribution_log_data/{yyyy}/{MM}/{dd}/{HH}/logs `
**注記**
サフィックスパスのディストリビューション ID には、いずれかの変数を使用できます。ただし、アクセスログを AWS Glue に送信する場合は、AWS Glue がパーティション名を小文字と想定するため、`{distributionid}` 変数を使用する必要があります。CloudFront の既存のログ設定を更新して、`{DistributionId}` を `{distributionid}` に置き換えます。
### Hive 互換ファイル名形式
このオプションを使用すると、配信されたアクセスログを含む S3 オブジェクトが、Apache Hive との統合を可能にするプレフィックス構造を使用できるようになります。詳細については、[CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) API オペレーションを参照してください。
**Example 例**
```
/cloudfront/DistributionId={DistributionId}/my_distribution_log_data/year={yyyy}/month={MM}/day={dd}/hour={HH}/logs
```
パーティショニングと Hive 互換オプションの詳細については、「*Amazon CloudWatch Logs API Reference*」の「[S3DeliveryConfiguration](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_S3DeliveryConfiguration.html)」要素を参照してください。
### アクセスログへのパスの例
S3 バケットを送信先として指定する場合、以下のオプションを使用してアクセスログへのパスを作成できます。
+ Amazon S3 バケット (プレフィックス付き、またはプレフィックスなし)
+ パーティショニング (CloudFront が提供する変数を使用するか、独自の変数を入力)
+ Hive 互換オプションの有効化
以下の表は、選択したオプションに応じて、アクセスログがバケット内でどのように表示されるかを示しています。
#### Amazon S3 バケット (プレフィックス付き)
| Amazon S3 バケット名 | サフィックスパスで指定したパーティション | サフィックスパスの更新 | Hive 互換の有効化? | アクセスログの送信先 |
| --- | --- | --- | --- | --- |
| amzn-s3-demo-bucket/MyLogPrefix | なし | なし | いいえ | amzn-s3-demo-bucket/MyLogPrefix/ |
| amzn-s3-demo-bucket/MyLogPrefix | myFolderA/ | myFolderA/ | なし | amzn-s3-demo-bucket/MyLogPrefix/myFolderA/ |
| amzn-s3-demo-bucket/MyLogPrefix | myFolderA/\$1yyyy\$1 | myFolderA/\$1yyyy\$1 | はい | amzn-s3-demo-bucket/MyLogPrefix/myFolderA/year=2025 |
#### Amazon S3 バケット (プレフィックスなし)
| Amazon S3 バケット名 | サフィックスパスで指定したパーティション | サフィックスパスの更新 | Hive 互換の有効化? | アクセスログの送信先 |
| --- | --- | --- | --- | --- |
| amzn-s3-demo-bucket | なし | AWSLogs/\$1account-id\$1/CloudFront/ | いいえ | amzn-s3-demo-bucket/AWSLogs//CloudFront/ |
| amzn-s3-demo-bucket | myFolderA/ | AWSLogs/\$1account-id\$1/CloudFront/myFolderA/ | なし | amzn-s3-demo-bucket/AWSLogs//CloudFront/myFolderA/ |
| amzn-s3-demo-bucket | myFolderA/ | AWSLogs/\$1account-id\$1/CloudFront/myFolderA/ | はい | amzn-s3-demo-bucket/AWSLogs/aws-account-id=/CloudFront/myFolderA/ |
| amzn-s3-demo-bucket | myFolderA/\$1yyyy\$1 | AWSLogs/\$1account-id\$1/CloudFront/myFolderA/\$1yyyy\$1 | はい | amzn-s3-demo-bucket/AWSLogs/aws-account-id=/CloudFront/myFolderA/year=2025 |
#### パーティションとしての AWS アカウント ID
| Amazon S3 バケット名 | サフィックスパスで指定したパーティション | サフィックスパスの更新 | Hive 互換の有効化? | アクセスログの送信先 |
| --- | --- | --- | --- | --- |
| amzn-s3-demo-bucket | なし | AWSLogs/\$1account-id\$1/CloudFront/ | はい | amzn-s3-demo-bucket/AWSLogs/aws-account-id=/CloudFront/ |
| amzn-s3-demo-bucket | myFolderA/\$1accountid\$1 | AWSLogs/\$1account-id\$1/CloudFront/myFolderA/\$1accountid\$1 | はい | amzn-s3-demo-bucket/AWSLogs/aws-account-id=/CloudFront/myFolderA/accountid= |
**注意事項**
`{account-id}` 変数は CloudFront 用に予約されています。Amazon S3 バケットをプレフィックス*なし*で指定すると、CloudFront はこの変数をサフィックスパスに自動的に追加します。ログが Hive 互換である場合、この変数は `aws-account-id` として表示されます。
`{accountid}` 変数を使用すると、CloudFront がアカウント ID をサフィックスパスに追加できます。ログが Hive 互換である場合、この変数は `accountid` として表示されます。
サフィックスパスの詳細については、「[S3DeliveryConfiguration](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_S3DeliveryConfiguration.html)」を参照してください。
### Amazon S3 に送信されたアクセスログの例
```
#Fields: date time x-edge-location asn timestamp(ms) x-host-header cs(Cookie)
2024-11-14 22:30:25 SOF50-P2 16509 1731623425421
d111111abcdef8.cloudfront.net examplecookie=value2
```
## 標準ログ記録を無効にする
不要になった場合は、ディストリビューションの標準ログ記録を無効にすることができます。
**標準ログ記録を無効にするには**
1. CloudFront コンソールにサインインします。
1. **[ディストリビューション]** を選択し、ディストリビューション ID を選択します。
1. **[ログ記録]** を選択し、**[アクセスログ送信先]** で送信先を選択します。
1. **[管理]**、**[削除]** の順に選択します。
1. 複数の標準ログ記録がある場合は、前のステップを繰り返します。
**注記**
CloudFront コンソールから標準ログ記録を削除すると、このアクションは配信と配信先のみを削除します。配信ソースは AWS アカウントから削除されません。配信ソースを削除するには、`aws logs delete-delivery-source --name DeliverySourceName` コマンドで配信ソース名を指定します。詳細については、「*Amazon CloudWatch Logs API Reference*」の「[DeleteDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliverySource.html)」を参照してください。
## トラブルシューティング
CloudFront 標準ログ記録 (v2) を使用する際の一般的な問題を修正するには、次の情報を使用します。
### 配信ソースが既に存在している
ディストリビューションの標準ログ記録を有効にすると、配信ソースが作成されます。次に、この配信ソースを使用して、必要な送信先タイプ (CloudWatch Logs、Firehose、Amazon S3) への配信を作成します。現在、配信ソースはディストリビューションごとに 1 つだけ持つことができます。同じディストリビューションに対して別の配信ソースを作成しようとすると、次のエラーメッセージが表示されます。
```
This ResourceId has already been used in another Delivery Source in this account
```
別の配信ソースを作成するには、まず既存のものを削除します。詳細については、「*Amazon CloudWatch Logs API Reference*」の「[DeleteDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliverySource.html)」を参照してください。
### サフィックスパスを変更したら、Amazon S3 バケットがログを受信できなくなった
標準ログ記録 (v2) を有効にし、プレフィックスなしでバケット ARN を指定すると、CloudFront はサフィックスパスに以下のデフォルトを追加します。`AWSLogs/{account-id}/CloudFront`。CloudFront コンソールまたは [UpdateDeliveryConfiguration](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_UpdateDeliveryConfiguration.html) API オペレーションを使用して別のサフィックスパスを指定する場合は、同じパスを使用するように Amazon S3 バケットポリシーを更新する必要があります。
**Example 例: サフィックスパスの更新**
1. デフォルトのサフィックスパスは `AWSLogs/{account-id}/CloudFront` で、`myFolderA` に置き換えます。
1. 新しいサフィックスパスは Amazon S3 バケットポリシーで指定されたパスとは異なるため、アクセスログは配信されません。
1. 次のいずれかの手順を実行します。
+ Amazon S3 バケットのアクセス許可を `amzn-s3-demo-bucket/AWSLogs//CloudFront/*` から `amzn-s3-demo-bucket/myFolderA/*` に更新します。
+ ログ記録設定を更新して、デフォルトのサフィックス (`AWSLogs/{account-id}/CloudFront`) を再度使用します。
詳細については、「[アクセス許可](#permissions-standard-logging)」を参照してください。
## ログファイルを削除する
CloudFront は、送信先からログファイルを自動的には削除しません。ログファイルの削除方法については、以下のトピックを参照してください。
**Amazon S3**
+ 「*Amazon Simple Storage Service Console ユーザーガイド*」の「[オブジェクトの削除](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjects.html)」
**CloudWatch Logs**
+ 「*Amazon CloudWatch Logs User Guide*」の「[Working with log groups and log streams](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)」
+ 「*Amazon CloudWatch Logs API Reference*」の「[DeleteLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteLogGroup.html)」
**Firehose**
+ 「*Amazon Data Firehose API Reference*」の「[DeleteDeliveryStream](https://docs.aws.amazon.com/firehose/latest/APIReference/API_DeleteDeliveryStream.html)」
## 料金
CloudFront では、標準ログの有効化には料金がかかりません。ただし、選択したログ配信先によっては、配信、取り込み、ストレージ、またはアクセスに対して料金が発生する場合があります。詳細については、「[Amazon CloudWatch Logs 料金表](https://aws.amazon.com/cloudwatch/pricing/)」を参照してください。**[有料利用枠]** で **[ログ]** タブを選択し、次に **[Vended Logs]** で各配信先に関する情報を確認します。
各 AWS のサービスの料金の詳細については、以下のトピックを参照してください。
+ [Amazon CloudWatch Logs 料金](https://aws.amazon.com/cloudwatch/pricing/)
+ [Amazon Data Firehose 料金](https://aws.amazon.com/kinesis/data-firehose/pricing/)
+ [Amazon S3 料金](https://aws.amazon.com/s3/pricing/)
**注記**
Amazon S3 へのログ配信に追加料金はかかりませんが、ログファイルの保存とアクセスには Amazon S3 料金が発生します。**[Parquet]** オプションを有効にしてアクセスログを Apache Parquet に変換すると、このオプションには CloudWatch 料金が発生します。詳細については、[「CloudWatch 料金表」の「Vended Logs」セクション](https://aws.amazon.com/cloudwatch/pricing/)を参照してください。
# 標準ログ記録 (レガシー) を設定する
**注意事項**
このトピックでは、以前のバージョンの標準ログ記録について説明します。最新バージョンについては、「[標準ログ記録 (v2) を設定する](standard-logging.md)」を参照してください。
標準ログ記録 (レガシー) を既に有効にしていて、Amazon S3 への標準ログ記録 (v2) を有効にする場合は、*別の* Amazon S3 バケットを指定するか、同じバケット内の*別のパス*を使用する (例: ログプレフィックスやパーティショニングを使用する) ことをお勧めします。これにより、どのログファイルがどのディストリビューションに関連付けられているかを追跡し、ログファイルが互いに上書きされるのを防ぐことができます。
標準ログ記録 (レガシー) を開始するには、次の手順を実行します。
1. ログを受信する Amazon S3 バケットを選択し、必要なアクセス許可を追加します。
1. CloudFront コンソールまたは CloudFront API を使用して標準ログ記録 (レガシー) を設定します。ログの受信先として Amazon S3 バケットのみを選択できます。
1. アクセスログを表示します。
## 標準ログ用の Amazon S3 バケットを選択する
ディストリビューションのログ記録を有効にする際には、CloudFront でログファイルを保存する Amazon S3 バケットを指定します。オリジンとして Amazon S3 を使用する場合は、ログファイル用に別のバケットを使用することをお勧めします。**
CloudFront でアクセスログを保存する先の Amazon S3 バケット (例: `amzn-s3-demo-bucket.s3.amazonaws.com`) を指定します。
複数のディストリビューションのログファイルを同じバケットに保存することもできます。ログ記録を有効にする際には、ファイル名のプレフィックスをオプションで指定できます。これにより、どのログファイルがどのディストリビューションに関連しているか追跡できます。
**S3 バケットの選択について**
バケットでは、アクセスコントロールリスト (ACL) が有効になっている必要があります。CloudFront コンソールで ACL を有効にしていないバケットを選択すると、エラーメッセージが表示されます。「[アクセス許可](#AccessLogsBucketAndFileOwnership)」を参照してください。
**強制を行ったバケット所有者**に設定される [S3 オブジェクトの所有権](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html)を使用して Amazon S3 バケットを選択してはいけません。この設定では、バケットとその中のオブジェクトの ACL が無効になり、CloudFront によるバケットへのログファイルの配信を阻止します。[標準ログ記録 V2](standard-logging.md)[AWS リージョン](https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html)
## アクセス許可
**重要**
2023 年 4 月以降、CloudFront 標準ログで使用する新しい S3 バケットでは S3 の ACL を有効にする必要があります。ACL は、[バケットを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-ownership-new-bucket.html)ときに有効にするか、[既存のバケット](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-ownership-existing-bucket.html)に対して有効にすることができます。
変更の詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[新しい S3 バケットのデフォルト設定に関するよくある質問](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-faq.html)」と、「*AWS ニュースブログ*」の「[注意喚起: 2023 年 4 月に予定されている Amazon S3 のセキュリティ変更](https://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/)」を参照してください。
AWS アカウントには、ログファイル用に指定するバケットに対して以下のアクセス許可が必要です。
+ バケットの ACL は `FULL_CONTROL` をユーザーに付与する必要があります バケット所有者のアカウントには、デフォルトでこのアクセス許可があります。権限がない場合、バケット所有者はバケットの ACL を更新する必要があります。
+ `s3:GetBucketAcl`
+ `s3:PutBucketAcl`
**バケットの ACL**
ディストリビューションを作成または更新してロギングを有効にすると、CloudFront はこれらのアクセス許可を使用してバケットの ACL を更新し、`awslogsdelivery` アカウントに `FULL_CONTROL` のアクセス許可を付与します。`awslogsdelivery` アカウントはログファイルをバケットに書き込みます。アカウントに ACL を更新するために必要なアクセス許可がない場合、ディストリビューションの作成または更新は失敗します。
状況によっては、バケットを作成するリクエストをプログラムで送信したが、指定した名前のバケットが既に存在する場合、S3 ではバケットのアクセス許可をデフォルト値にリセットします。アクセスログを S3 バケットに保存するように CloudFront を設定した後で、そのバケットでのログ受信を中止する場合は、バケットのアクセス許可をチェックして CloudFront に必要なアクセス許可があることを確認します。
**バケットの ACL を復元する**
`awslogsdelivery` アカウントのアクセス許可を削除すると、CloudFront はログを S3 バケットに保存できません。CloudFront がディストリビューションのログ保存を再開するには、次のいずれかの操作を行って ACL アクセス許可を復元します。
+ CloudFront ディストリビューションのログ記録を無効化してから、再度有効にします。詳細については、「[標準ログ記録](DownloadDistValuesGeneral.md#DownloadDistValuesLoggingOnOff)」を参照してください。
+ Amazon S3 コンソールで S3 バケットに移動してアクセス許可を追加することで、`awslogsdelivery` の ACL アクセス許可を手動で追加します。`awslogsdelivery` の ACL を追加するには、アカウントの正規 ID を入力する必要があります。これは次のとおりです。
`c4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0`
ACL を S3 バケットに追加する方法の詳細については、「Amazon Simple Storage Service コンソールユーザーガイド」の「[ACL の設定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/managing-acls.html)」を参照してください。**
**各ログファイルの ACL**
バケットの ACL に加えて、各ログファイルの ACL があります。バケット所有者にはログファイルに対する `FULL_CONTROL` アクセス許可があり、ディストリビューション所有者 (バケット所有者と異なる場合) にはアクセス許可がありません。`awslogsdelivery` アカウントには読み取りアクセス許可と書き込みアクセス許可があります。
**ログ記録の無効化**
ログ記録を無効にしても、CloudFront ではバケットやログファイルの ACL が削除されません。ACL は、必要に応じて削除できます。
### SSE-KMS バケット必須のキーポリシー
標準ログ用の S3 バケットで、カスタマーマネージド型キーを使用する AWS KMS keys (SSE-KMS) を用いたサーバー側の暗号化が使用されている場合は、カスタマーマネージド型キーのキーポリシーに次のステートメントを追加する必要があります。これにより、CloudFront はログファイルをバケットに書き込むことができます。AWS マネージドキー で SSE-KMS を使用することはできません (CloudFront はログファイルをバケットに書き込むことができないため)。
```
{
"Sid": "Allow CloudFront to use the key to deliver logs",
"Effect": "Allow",
"Principal": {
"Service": "delivery.logs.amazonaws.com"
},
"Action": "kms:GenerateDataKey*",
"Resource": "*"
}
```
標準ログの S3 バケットで [S3 バケットキー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-key.html)を有する SSE-KMS を使用する場合は、ポリシーステートメントに `kms:Decrypt` 許可を追加する必要もあります。この場合、完全なポリシーステートメントは次のようになります。
```
{
"Sid": "Allow CloudFront to use the key to deliver logs",
"Effect": "Allow",
"Principal": {
"Service": "delivery.logs.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "*"
}
```
**注記**
S3 バケットで SSE-KMS を有効にするときは、カスタマーマネージドキーの完全な ARN を指定します。詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[AWS KMS keys (SSE-KMS) によるサーバー側の暗号化の指定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/specifying-kms-encryption.html)」を参照してください。
## 標準ログ記録 (レガシー) を有効にする
標準ログを有効にするには、CloudFront コンソールまたは CloudFront API を使用します。
**Contents**
+ [
### 標準ログ記録 (レガシー) を有効にする (CloudFront コンソール）
](#standard-logs-legacy-enable-console)
+ [
### 標準ログ記録 (レガシー) を有効にする (CloudFront API)
](#standard-logs-legacy-enable-api)
### 標準ログ記録 (レガシー) を有効にする (CloudFront コンソール）
**CloudFront ディストリビューションの標準ログを有効にするには (コンソール）**
1. CloudFront コンソールを使用して、[新しいディストリビューションを作成](distribution-web-creating-console.md)するか、[既存のディストリビューションを更新](HowToUpdateDistribution.md#HowToUpdateDistributionProcedure)します。
1. **[標準ログ記録]** セクションの **[ログ配信]** で、**[オン]** を選択します。
1. (オプション) **[cookie ログ記録]** で、ログに cookie を含める場合は **[オン]** を選択します。詳細については、「[cookie のログ作成](DownloadDistValuesGeneral.md#DownloadDistValuesCookieLogging)」を参照してください。
**ヒント**
cookie ログ記録は、ディストリビューションの*すべて*の標準ログに適用されるグローバル設定です。この設定を個別の配信先で上書きすることはできません。
1. **[配信先]** セクションで、**[Amazon S3 (レガシー)]** を指定します。
1. Amazon S3 バケットを指定します。バケットがまだない場合は、**[作成]** を選択するか、ドキュメントを参照して[バケットを作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)できます。
1. (オプション) **[ログプレフィックス]** で、このディストリビューションのアクセスログファイル名の先頭に CloudFront で追加する文字列 (ある場合) を指定します (例: `exampleprefix/`)。末尾のスラッシュ (/) はオプションですが、ログファイルの参照を容易にするためにこれを使用することをお勧めします。詳細については、「[ログのプレフィックス](DownloadDistValuesGeneral.md#DownloadDistValuesLogPrefix)」を参照してください。
1. ディストリビューションを更新または作成する手順を完了します。
1. **[ログ]** ページで、標準ログのステータスが、ディストリビューションの横で **[有効]** になっていることを確認します。
標準ログ記録の配信とログフィールドの詳細については、「[標準ログ記録リファレンス](standard-logs-reference.md)」を参照してください。
### 標準ログ記録 (レガシー) を有効にする (CloudFront API)
CloudFront API を使用して、ディストリビューションの標準ログを有効にすることもできます。
**ディストリビューションの標準ログを有効にするには (CloudFront API)**
+ [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) または [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) API オペレーションを使用して、[LoggingConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_LoggingConfig.html) オブジェクトを設定します。
## 標準ログ記録設定を編集する
ログ記録の有効化および無効化、ログを保存する Amazon S3 バケットの変更、ログファイルのプレフィックスの変更は、[CloudFront コンソール](https://console.aws.amazon.com/cloudfront/v4/home)または CloudFront API を使用して行うことができます。ログ作成設定の変更は 12 時間以内に有効になります。
詳細については、以下のトピックを参照してください。
+ CloudFront コンソールを使用してディストリビューションを更新するには、「[ディストリビューションを更新する](HowToUpdateDistribution.md)」を参照してください。
+ CloudFront API を使用してディストリビューションを更新する方法については、*Amazon CloudFront API リファレンス*の「[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)」を参照してください。
## ログを Amazon S3 に送信する
ログを Amazon S3 に送信すると、ログは次の形式で表示されます。
### ファイル名の形式
CloudFront が Amazon S3 バケットに保存する各ログファイルの名前には、次のファイル名形式が使用されます。
`/.YYYY-MM-DD-HH.unique-ID.gz`
日付と時刻は協定世界時 (UTC) です。
たとえば、`example-prefix` をプレフィックスとして使用している場合に、ディストリビューション ID が `EMLARXS9EXAMPLE` であれば、ファイル名は次のようになります。
`example-prefix/EMLARXS9EXAMPLE.2019-11-14-20.RT4KCN4SGK9.gz`
ディストリビューションのログ記録を有効にする際には、ファイル名のプレフィックスをオプションで指定できます。これにより、どのログファイルがどのディストリビューションに関連しているか追跡できます。ログファイルのプレフィックスの値を指定した場合、プレフィックスがスラッシュ (`/`) で終わらない場合は、CloudFront によって自動的に追加されます。プレフィックスがスラッシュで終わる場合、CloudFront はスラッシュを追加しません。
ファイル名の末尾にある `.gz` は、CloudFront によってログファイルが gzip で圧縮されたことを示しています。
## 標準ログファイル形式
ログファイルには、1 つのビューワーリクエストの詳細が 1 エントリとして記録されます。ログファイルの特性は次のとおりです。
+ [W3C 拡張ログファイル形式](https://www.w3.org/TR/WD-logfile.html)を使用します。
+ タブ区切りの値が含まれます。
+ レコードが必ずしも時系列順に含まれているとは限りません。
+ 2 つのヘッダー行が含まれます。1 つのヘッダー行にファイル形式のバージョンが示され、もう 1 つのヘッダー行に、各レコードに含まれる W3C フィールドが示されます。
+ フィールド値に URL エンコードされたスペースおよび特定の他の文字を含めます。
URL エンコードされた同等の文字は、次の文字に使用されます。
+ ASCII 文字コード 0～32 以内
+ ASCII 文字コード 127 以上
+ 次の表のすべての文字
URL エンコーディング標準は [RFC 1738](https://tools.ietf.org/html/rfc1738.html) で定義されています。
| URL エンコードされた値 | 文字 |
| --- | --- |
| %3C | < |
| %3E | > |
| %22 | " |
| %23 | \$1 |
| %25 | % |
| %7B | \$1 |
| %7D | \$1 |
| %7C | \$1 |
| %5C | \$1 |
| %5E | ^ |
| %7E | \$1 |
| %5B | [ |
| %5D | ] |
| %60 | ` |
| %27 | ' |
| %20 | スペース |
## ログファイルを削除する
CloudFront は、Amazon S3 バケットからログファイルを自動的には削除しません。Amazon S3 バケットからログファイルを削除する方法については、「*Amazon Simple Storage Service コンソールユーザーガイド*」の「[オブジェクトの削除](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjects.html)」を参照してください。
## 料金
標準ログ記録は、CloudFront のオプション機能です。CloudFront では、標準ログの有効化には料金がかかりません。ただし、Amazon S3 でのファイルの保存とアクセスには通常の Amazon S3 料金が発生します。ファイルはいつでも削除できます。
Amazon S3 の料金に関する詳細については、「[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/)」を参照してください。
CloudFront の料金の詳細については、「[CloudFront の料金](https://aws.amazon.com/cloudfront/pricing/)」を参照してください。
# 標準ログ記録リファレンス
以下のセクションは、標準ログ記録 (v2) と標準ログ記録 (レガシー) の両方に該当します。
**Topics**
+ [
## ログファイル配信のタイミング
](#access-logs-timing)
+ [
## リクエスト URL またはヘッダーが最大のサイズを超えた場合にリクエストがどのようにログに記録されるか
](#access-logs-request-URL-size)
+ [
## ログファイルのフィールド
](#BasicDistributionFileFormat)
+ [
## ログを分析する
](#access-logs-analyzing)
## ログファイル配信のタイミング
CloudFront は、ディストリビューションのログを 1 時間に最大で数回配信します。一般的に、ログファイルには、一定期間内に CloudFront が受信したリクエストに関する情報が含まれています。CloudFront は通常、その期間のログファイルを、ログにイベントが表示されてから 1 時間以内に送信先に配信します。ただし、ある期間のログファイルエントリの一部またはすべてが、最大で 24 時間遅れることもあります。ログエントリが遅れた場合、CloudFront はこれらをログファイルに保存します。ファイル名には、ファイルの配信日時ではなく、リクエストが*発生した*期間の日時が使用されます。
CloudFront は、ログファイルを作成する場合、ログファイルに対応する期間中にオブジェクトについてリクエストを受信したすべてのエッジロケーションから、ディストリビューションの情報を集約します。
CloudFront は、ディストリビューションに関連付けられているオブジェクトについて CloudFront が受信したリクエストの数により、1 つの期間に対して複数のファイルを保存することもできます。
CloudFront によるアクセスログの出力が確実に行われるのは、ログ記録が有効になって約 4 時間後からです。この時間以前にも少しのアクセスログを取得できる場合もあります。
**注記**
期間中にオブジェクトに対してユーザーによるリクエストがなければ、その期間のログファイルは配信されません。
## リクエスト URL またはヘッダーが最大のサイズを超えた場合にリクエストがどのようにログに記録されるか
クッキーを含むすべてのリクエストヘッダーの合計サイズが 20 KB を超える場合、または URL が 8192 バイトの URL サイズ制限を超える場合、CloudFront ではリクエストを完全に解析できないため、リクエストをログに記録できません。リクエストがログ記録されないため、返された HTTP エラーステータスコードをログファイルで表示できません。
リクエストボディが最大サイズを超えると、HTTP エラー状態コードを含むリクエストがログに記録されます。
## ログファイルのフィールド
ディストリビューションのログファイルには、33 のフィールドが含まれています。次のリストは、各フィールド名と、そのフィールドに保持される情報の説明を順番に示しています。
1. **`date`**
イベントが発生した日付。`YYYY-MM-DD` 形式です。例えば、`2019-06-30`。日付と時刻は協定世界時 (UTC) です。WebSocket 接続の場合、これは接続が閉じた日付です。
1. **`time`**
CloudFront サーバーがリクエストへの対応を完了した時刻 (UTC) (`01:42:39` など)。WebSocket 接続の場合、これは接続を閉じる時間です。
1. **`x-edge-location`**
リクエストを処理したエッジロケーション。各エッジロケーションは、3 文字コードと、割り当てられた任意の数字で識別されます (例: DFW3)。通常、この 3 文字コードは、エッジロケーションの地理的場所の近くにある空港の、国際航空運送協会 (IATA) の空港コードに対応します。(これらの略語は今後変更される可能性があります)。
1. **`sc-bytes`**
サーバーがリクエストに応じてビューワーに送信したデータ (ヘッダーを含む) のバイトの合計数。WebSocket および gRPC 接続の場合、これは接続を経由してサーバーからクライアントに送信した合計バイト数です。
1. **`c-ip`**
リクエスト元のビューワーの IP アドレス (`192.0.2.183` または `2001:0db8:85a3::8a2e:0370:7334` など)。ビューワーが HTTP プロキシまたはロードバランサーを使用してリクエストを送った場合、このフィールドの値はプロキシまたはロードバランサーの IP アドレスです。`x-forwarded-for` フィールドも参照してください。
1. **`cs-method`**
ビューワーから受信した HTTP リクエストメソッド。
1. **`cs(Host)`**
CloudFront ディストリビューションのドメイン名 (d111111abcdef8.cloudfront.net など)。
1. **`cs-uri-stem`**
パスとオブジェクトを識別するリクエスト URL の部分 (`/images/cat.jpg` など)。URL 内の疑問符 (?) およびクエリ文字列はログに含まれません。
1. **`sc-status`**
次のいずれかの値が含まれます。
+ サーバーのレスポンスの HTTP ステータスコード (例: `200`)。
+ `000`。この値は、サーバーがリクエストに応答する前に、ビューワーが接続を閉じたことを示します。サーバーがレスポンスの送信を開始した後にビューワーが接続を閉じた場合、このフィールドには、サーバーが送信を開始したレスポンスの HTTP ステータスコードが含まれます。
1. **`cs(Referer)`**
リクエスト内の `Referer` ヘッダーの値。これはリクエスト元のドメインの名前です。一般的なリファラーとして、検索エンジン、オブジェクトに直接リンクされた他のウェブサイト、ユーザー自身のウェブサイトなどがあります。
1. **`cs(User-Agent)`**
リクエスト内の `User-Agent` ヘッダーの値。`User-Agent` ヘッダーでリクエスト元 (リクエスト元のデバイスとブラウザのタイプなど) が識別されます。リクエスト元が検索エンジンの場合は、どの検索エンジンかも識別されます。
1. **`cs-uri-query`**
リクエスト URL のクエリ文字列の部分 (ある場合)。
URL にクエリ文字列が含まれない場合、このフィールドの値はハイフン (-) です。詳細については、「[クエリ文字列パラメータに基づいてコンテンツをキャッシュする](QueryStringParameters.md)」を参照してください。
1. **`cs(Cookie)`**
名前と値のペアおよび関連属性を含む、リクエスト内の `Cookie` ヘッダー。
Cookie のログ作成を有効にした場合は、どの Cookie についてオリジンの転送を指定したかに関係なく、CloudFront ではすべてのリクエスト内の Cookie がログに記録されます。リクエストに Cookie ヘッダーが含まれていない場合、このフィールドの値はハイフン (-) です。Cookie の詳細については、「[Cookie に基づいてコンテンツをキャッシュする](Cookies.md)」を参照してください。
1. **`x-edge-result-type`**
サーバーが、最後のバイトを渡した後で、レスポンスを分類した方法。場合によっては、サーバーがレスポンスを送る準備ができたときから、サーバーがレスポンスを送り終わるまでの間に、結果タイプが変わることがあります。`x-edge-response-result-type` フィールドも参照してください。
例えば、HTTP ストリーミングで、サーバーがキャッシュ内でストリームのセグメントを検出するとします。そのシナリオでは、このフィールドの値は、通常 `Hit` になります。この場合、サーバーがセグメント全体を配信する前にビューワーが接続を閉じると、最終結果タイプ (およびこのフィールドの値) は `Error` になります。
WebSocket および gRPC 接続の場合、コンテンツがキャッシュ可能ではなく、オリジンに直接プロキシされるため、このフィールドの値は `Miss` になります。
以下に示しているのは、可能な値です。
+ `Hit` – サーバーがキャッシュからビューワーにオブジェクトを渡しました。
+ `RefreshHit` – サーバーはキャッシュ内でオブジェクトを検出しましたが、オブジェクトの有効期限が切れていたため、サーバーはオリジンに問い合わせて、キャッシュ内に最新バージョンのオブジェクトがあるかどうかを確認しました。
+ `Miss` – キャッシュ内のオブジェクトでリクエストに対応できなかったため、サーバーはリクエストをオリジンに転送して結果をビューワーに返しました。
+ `LimitExceeded` – CloudFront クォータ (以前は制限と呼ばれていました) を超えたため、リクエストは拒否されました。
+ `CapacityExceeded` – リクエストの受信時にサーバーの容量不足でオブジェクトを渡すことができなかったために、サーバーから HTTP 503 ステータスコードが返されました。
+ `Error` – 通常、これはリクエストがクライアントエラーとなった (`sc-status` フィールドが `4xx` 範囲内の値となる)、またはサーバーエラーになった (`sc-status` フィールドが `5xx` 範囲内の値となる) ことを意味します。`sc-status` フィールドの値が `200` であるか、このフィールドの値が `Error` で、`x-edge-response-result-type` フィールドの値が `Error` でない場合は、HTTP リクエストは成功したが、クライアントがすべてのバイトを受信する前に切断されたことを意味します。
+ `Redirect` – サーバーは、ディストリビューション設定に従って HTTP から HTTPS にビューワーをリダイレクトしました。
+ `LambdaExecutionError` – ディストリビューションに関連付けられた Lambda@Edge 関数は、不正な関連付け、関数のタイムアウト、AWS の依存関係の問題、または別の一般的な可用性の問題が原因で完了しませんでした。
1. **`x-edge-request-id`**
リクエストを一意に識別する不透明な文字列。CloudFront では、この文字列を `x-amz-cf-id` レスポンスヘッダーでも送信します。
1. **`x-host-header`**
ビューワーが、このリクエストの `Host` ヘッダーに追加した値。オブジェクトの URL に CloudFront ドメイン名を使用している場合 (d111111abcdef8.cloudfront.net など)、このフィールドにはそのドメイン名が含まれます。代替ドメイン名 (CNAME) をオブジェクト URL (www.example.com) に使用している場合、このフィールドにはその代替ドメイン名が含まれます。
代替ドメイン名を使っている場合には、フィールド 7 の `cs(Host)` で、ユーザーのディストリビューションに関連するドメイン名を確認します。
1. **`cs-protocol`**
ビューワーリクエストのプロトコル (`http`、`https`、`grpcs`、`ws`、または `wss`)。
1. **`cs-bytes`**
ビューワーがリクエストに含めたデータ (ヘッダーを含む) のバイトの合計数。WebSocket および gRPC 接続の場合、これは接続を経由してクライアントからサーバーに送信した合計バイト数です。
1. **`time-taken`**
サーバーが、ビューワーのリクエストを受信してからレスポンスの最後のバイトを出力キューに書き込むまでの秒数。サーバーで 1,000 分の 1 秒単位まで測定されます (例: 0.082)。ビューワーから見た場合、レスポンス全体を取得する合計所要時間は、ネットワークのレイテンシーと TCP バッファリングにより、この値よりも長くなります。
1. **`x-forwarded-for`**
ビューワーが HTTP プロキシまたはロードバランサーを使用してリクエストを送信した場合、`c-ip` フィールドの値はプロキシまたはロードバランサーの IP アドレスです。この場合、このフィールドはリクエスト元のビューワーの IP アドレスです。このフィールドには、複数の IP アドレスをカンマで区切って含めることができます。各 IP アドレスは、IPv4 アドレス (`192.0.2.183` など) または IPv6 アドレス (`2001:0db8:85a3::8a2e:0370:7334` など) にすることができます。
ビューワーが HTTP プロキシまたはロードバランサーを使用しなかった場合、このフィールドの値はハイフン (-) です。
1. **`ssl-protocol`**
リクエストが HTTPS を使用した場合、このフィールドには、リクエストとレスポンスを送信するためにビューワーとサーバーがネゴシエートした SSL/TLS プロトコルが含まれます。指定可能な値のリストについては、[ビューワーと CloudFront との間でサポートされているプロトコルと暗号](secure-connections-supported-viewer-protocols-ciphers.md) でサポートされている SSL/TLS プロトコルを参照してください。
フィールド 17 の `cs-protocol` が `http` である場合、このフィールドの値はハイフン (-) です。
1. **`ssl-cipher`**
リクエストが HTTPS を使用した場合、このフィールドには、リクエストとレスポンスを暗号化するためにビューワーとサーバーがネゴシエートした SSL/TLS 暗号が含まれます。使用できる値のリストについては、「[ビューワーと CloudFront との間でサポートされているプロトコルと暗号](secure-connections-supported-viewer-protocols-ciphers.md)」で、サポートされている SSL/TLS 暗号化を参照してください。
フィールド 17 の `cs-protocol` が `http` である場合、このフィールドの値はハイフン (-) です。
1. **`x-edge-response-result-type`**
ビューワーにレスポンスを返す直前にサーバーがレスポンスを分類した方法。`x-edge-result-type` フィールドも参照してください。以下に示しているのは、可能な値です。
+ `Hit` – サーバーがキャッシュからビューワーにオブジェクトを渡しました。
+ `RefreshHit` – サーバーはキャッシュ内でオブジェクトを検出しましたが、オブジェクトの有効期限が切れていたため、サーバーはオリジンに問い合わせて、キャッシュ内に最新バージョンのオブジェクトがあるかどうかを確認しました。
+ `Miss` – キャッシュ内のオブジェクトでリクエストに対応できなかったため、サーバーはリクエストをオリジンサーバーに転送して結果をビューワーに返しました。
+ `LimitExceeded` – CloudFront クォータ (以前は制限と呼ばれていました) を超えたため、リクエストは拒否されました。
+ `CapacityExceeded` – リクエストの受信時にサーバーの容量不足でオブジェクトを渡すことができなかったために、サーバーから 503 エラーが返されました。
+ `Error` – 通常、これはリクエストがクライアントエラーとなった (`sc-status` フィールドが `4xx` 範囲内の値となる)、またはサーバーエラーになった (`sc-status` フィールドが `5xx` 範囲内の値となる) ことを意味します。
`x-edge-result-type` フィールドの値が `Error` であり、このフィールドの値が `Error` でない場合、ダウンロードが完了する前にクライアントが切断されました。
+ `Redirect` – サーバーは、ディストリビューション設定に従って HTTP から HTTPS にビューワーをリダイレクトしました。
+ `LambdaExecutionError` – ディストリビューションに関連付けられた Lambda@Edge 関数は、不正な関連付け、関数のタイムアウト、AWS の依存関係の問題、または別の一般的な可用性の問題が原因で完了しませんでした。
1. **`cs-protocol-version`**
ビューワーがリクエストで指定した HTTP バージョン。指定できる値には、`HTTP/0.9`、`HTTP/1.0`、`HTTP/1.1`、`HTTP/2.0`および `HTTP/3.0` などがあります。
1. **`fle-status`**
[フィールドレベル暗号化](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html)がディストリビューション用に設定されている場合、このフィールドにはリクエストボディが正常に処理されたかどうかを示すコードが含まれます。サーバーがリクエストボディを正常に処理し、指定したフィールドの値を暗号化してリクエストをオリジンに転送すると、このフィールドの値は `Processed` になります。`x-edge-result-type` の値は、この場合でもクライアント側またはサーバー側のエラーを示すことができます。
このフィールドで使用できる値は次のとおりです。
+ `ForwardedByContentType` – コンテンツタイプが設定されていないため、サーバーは解析や暗号化を行わずにリクエストをオリジンに転送しました。
+ `ForwardedByQueryArgs` – フィールドレベル暗号化の設定にないクエリ引数がリクエストに含まれているため、サーバーは解析や暗号化を行わずにリクエストをオリジンに転送しました。
+ `ForwardedDueToNoProfile` – フィールドレベル暗号化の設定でプロファイルを指定しなかったため、サーバーは解析や暗号化を行わずにリクエストをオリジンに転送しました。
+ `MalformedContentTypeClientError` `Content-Type` – ヘッダーの値が無効な形式であるため、サーバーはリクエストを拒否し、HTTP 400 ステータスコードをビューワーに返しました。
+ `MalformedInputClientError` – リクエストボディが無効な形式であるため、サーバーはリクエストを拒否し、HTTP 400 ステータスコードをビューワーに返しました。
+ `MalformedQueryArgsClientError` – クエリ引数が空であるか無効な形式であるため、サーバーはリクエストを拒否し、HTTP 400 ステータスコードをビューワーに返しました。
+ `RejectedByContentType` – フィールドレベル暗号化の設定でコンテンツタイプを指定しなかったため、サーバーはリクエストを拒否し、HTTP 400 ステータスコードをビューワーに返しました。
+ `RejectedByQueryArgs` – フィールドレベル暗号化の設定でクエリ引数を指定しなかったため、サーバーはリクエストを拒否し、HTTP 400 ステータスコードをビューワーに返しました。
+ `ServerError` – オリジンサーバーがエラーを返しました。
リクエストがフィールドレベル暗号化のクォータ (以前は制限と呼ばれていました) を超えた場合、このフィールドには次のいずれかのエラーコードが含まれ、サーバーは HTTP ステータスコード 400 をビューワーに返します。フィールドレベル暗号化に関する最新のクォータのリストについては、「[フィールドレベル暗号化のクォータ](cloudfront-limits.md#limits-field-level-encryption)」を参照してください。
+ `FieldLengthLimitClientError` – 暗号化されるように設定されているフィールドが最大の長さを超えています。
+ `FieldNumberLimitClientError` – ディストリビューションによって暗号化されるように設定されているリクエストがフィールド数の制限を超えています。
+ `RequestLengthLimitClientError` – フィールドレベル暗号化が設定されている場合にリクエストボディが最大の長さを超えています。
フィールドレベル暗号化がディストリビューション用に設定されていない場合、このフィールドの値はハイフン (-) です。
1. **`fle-encrypted-fields`**
サーバーが暗号化してオリジンに転送した[フィールドレベル暗号化](field-level-encryption.md)フィールドの数。CloudFront サーバーは処理されたリクエストをオリジンにストリーミングするときにデータを暗号化するため、`fle-status` の値がエラーであっても、このフィールドに値が渡されている場合があります。
フィールドレベル暗号化がディストリビューション用に設定されていない場合、このフィールドの値はハイフン (-) です。
1. **`c-port`**
閲覧者からのリクエストのポート番号。
1. **`time-to-first-byte`**
サーバー上で測定される、要求を受信してから応答の最初のバイトを書き込むまでの秒数。
1. **`x-edge-detailed-result-type`**
このフィールドには、以下の場合を除き、`x-edge-result-type` フィールドと同じ値が含まれます。
+ オブジェクトが [Origin Shield](origin-shield.md) レイヤーからビューワーに渡された場合、このフィールドには `OriginShieldHit` が含まれています。
+ オブジェクトが CloudFront キャッシュに存在せず、レスポンスが[オリジンリクエストの Lambda@Edge 関数](lambda-at-the-edge.md)によって生成された場合、このフィールドには `MissGeneratedResponse` が含まれます。
+ `x-edge-result-type` フィールドの値が `Error` の場合、このフィールドにはエラーに関する詳細情報を含む次のいずれかの値が含まれます。
+ `AbortedOrigin` – サーバーでオリジンに関する問題が発生しました。
+ `ClientCommError` – サーバーとビューワーとの通信の問題により、ビューワーへのレスポンスが中断されました。
+ `ClientGeoBlocked` – ディストリビューションは、ビューワーの地理的位置からのリクエストを拒否するように設定されています。
+ `ClientHungUpRequest` – リクエストの送信中にビューワーが途中で停止しました。
+ `Error` – エラータイプが他のどのカテゴリにも適合しないエラーが発生しました。このエラータイプは、キャッシュからのエラーレスポンスをサーバーが渡すときに発生する可能性があります。
+ `InvalidRequest` – サーバーがビューワーから無効なリクエストを受信しました。
+ `InvalidRequestBlocked` – 要求されたリソースへのアクセスがブロックされます。
+ `InvalidRequestCertificate` – ディストリビューションが、HTTPS 接続の確立に使用した SSL/TLS 証明書と一致しません。
+ `InvalidRequestHeader` – リクエストに無効なヘッダーが含まれていました。
+ `InvalidRequestMethod` – ディストリビューションは、使用された HTTP リクエストメソッドを処理するように設定されていません。これは、ディストリビューションがキャッシュ可能なリクエストのみをサポートしている場合に発生します。
+ `OriginCommError` — オリジンに接続中、またはオリジンからデータを読み取るときに、リクエストがタイムアウトしました。
+ `OriginConnectError` – サーバーがオリジンに接続できませんでした。
+ `OriginContentRangeLengthError` – オリジンのレスポンスの `Content-Length` ヘッダーが、`Content-Range` ヘッダーの長さと一致しません。
+ `OriginDnsError` – サーバーがオリジンのドメイン名を解決できませんでした。
+ `OriginError` – オリジンが誤ったレスポンスを返しました。
+ `OriginHeaderTooBigError` – オリジンから返されたヘッダーが大きすぎてエッジサーバーで処理できません。
+ `OriginInvalidResponseError` – オリジンが無効なレスポンスを返しました。
+ `OriginReadError` – サーバーがオリジンから読み取れませんでした。
+ `OriginWriteError` – サーバーがオリジンに書き込めませんでした。
+ `OriginZeroSizeObjectError` – オリジンから送信されたサイズゼロのオブジェクトがエラーになりました。
+ `SlowReaderOriginError` – オリジンエラーの原因となったメッセージの読み取りに時間がかかりました。
1. **`sc-content-type`**
レスポンスの HTTP `Content-Type` ヘッダーの値。
1. **`sc-content-len`**
レスポンスの HTTP `Content-Length` ヘッダーの値。
1. **`sc-range-start`**
レスポンスに HTTP `Content-Range` ヘッダーが含まれている場合、このフィールドには範囲の開始値が含まれます。
1. **`sc-range-end`**
レスポンスに HTTP `Content-Range` ヘッダーが含まれている場合、このフィールドには範囲の終了値が含まれます。
1. **`distribution-tenant-id`**
ディストリビューションテナントの ID。
1. **`connection-id`**
TLS 接続の一意の識別子です。
このフィールドの情報を取得する前に、ディストリビューションの mTLS を有効にする必要があります。詳細については、「[CloudFront による相互 TLS 認証 (Viewer mTLS)オリジンの相互 TLS と CloudFront](mtls-authentication.md)」を参照してください。
ディストリビューションのログファイルの例を以下に示します。
```
#Version: 1.0
#Fields: date time x-edge-location sc-bytes c-ip cs-method cs(Host) cs-uri-stem sc-status cs(Referer) cs(User-Agent) cs-uri-query cs(Cookie) x-edge-result-type x-edge-request-id x-host-header cs-protocol cs-bytes time-taken x-forwarded-for ssl-protocol ssl-cipher x-edge-response-result-type cs-protocol-version fle-status fle-encrypted-fields c-port time-to-first-byte x-edge-detailed-result-type sc-content-type sc-content-len sc-range-start sc-range-end
2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit SOX4xwn4XV6Q4rgb7XiVGOHms_BGlTAC4KyHmureZmBNrjGdRLiNIQ== d111111abcdef8.cloudfront.net https 23 0.001 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.001 Hit text/html 78 - -
2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit k6WGMNkEzR5BEM_SaF47gjtX9zBDO2m349OY2an0QPEaUum1ZOLrow== d111111abcdef8.cloudfront.net https 23 0.000 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.000 Hit text/html 78 - -
2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit f37nTMVvnKvV2ZSvEsivup_c2kZ7VXzYdjC-GUQZ5qNs-89BlWazbw== d111111abcdef8.cloudfront.net https 23 0.001 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.001 Hit text/html 78 - -
2019-12-13 22:36:27 SEA19-C1 900 192.0.2.200 GET d111111abcdef8.cloudfront.net /favicon.ico 502 http://www.example.com/ Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Error 1pkpNfBQ39sYMnjjUQjmH2w1wdJnbHYTbag21o_3OfcQgPzdL2RSSQ== www.example.com http 675 0.102 - - - Error HTTP/1.1 - - 25260 0.102 OriginDnsError text/html 507 - -
2019-12-13 22:36:26 SEA19-C1 900 192.0.2.200 GET d111111abcdef8.cloudfront.net / 502 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Error 3AqrZGCnF_g0-5KOvfA7c9XLcf4YGvMFSeFdIetR1N_2y8jSis8Zxg== www.example.com http 735 0.107 - - - Error HTTP/1.1 - - 3802 0.107 OriginDnsError text/html 507 - -
2019-12-13 22:37:02 SEA19-C2 900 192.0.2.200 GET d111111abcdef8.cloudfront.net / 502 - curl/7.55.1 - - Error kBkDzGnceVtWHqSCqBUqtA_cEs2T3tFUBbnBNkB9El_uVRhHgcZfcw== www.example.com http 387 0.103 - - - Error HTTP/1.1 - - 12644 0.103 OriginDnsError text/html 507 - -
```
## ログを分析する
1 時間ごとに複数のアクセスログが配信される可能性があるため、特定の期間に対して受信したすべてのログファイルをまとめて 1 つのファイルにしておくことをお勧めします。これにより、その期間のデータをより正確かつ完全に分析することができます。
アクセスログを分析する方法の 1 つとして [Amazon Athena](https://aws.amazon.com/athena/) を使用する方法があります。Athena は、CloudFront を含めた AWS のサービスのデータを分析するために役立つインタラクティブなクエリサービスです。詳細については、*Amazon Athena ユーザーガイド*の「[ Amazon CloudFront ログのクエリ](https://docs.aws.amazon.com/athena/latest/ug/cloudfront-logs.html)」を参照してください。
さらに、次の AWS ブログ投稿では、アクセスログを分析するいくつかの方法について説明しています。
+ [ Amazon CloudFront Request Logging](https://aws.amazon.com/blogs/aws/amazon-cloudfront-request-logging/) (HTTP 経由で配信するコンテンツの場合)
+ [強化された CloudFront ログにクエリ文字列機能を追加](https://aws.amazon.com/blogs/aws/enhanced-cloudfront-logs-now-with-query-strings/)