Amazon S3 サーバーアクセスのログ記録 - Amazon Simple Storage Service

Amazon S3 サーバーアクセスのログ記録

サーバーアクセスのログには、バケットに対するリクエストの詳細が記録されます。サーバーアクセスのログは、多くのアプリケーションに役立ちます。たとえば、アクセスのログ情報は、セキュリティやアクセスの監査に役立ちます。また、顧客基盤について知り、Amazon S3 の請求を理解することにも役立ちます。

注記

サーバーアクセスログには、2019 年 3 月 20 日より後に開設されたリージョンで発生するリージョン違いによるリダイレクトエラーに関する情報は記録されません。リージョン違いによるリダイレクトエラーは、オブジェクトまたはバケットに対するリクエストがそのバケットがあるリージョン以外で行われた場合に発生します。

サーバーアクセスのログ記録を有効にする方法

バケットへのアクセスのリクエストを追跡するため、サーバーアクセスのログ記録を有効にすることができます。アクセスログのレコードごとに 1 つのアクセスリクエストの詳細として、リクエスタ、バケット名、リクエスト時刻、リクエストアクション、レスポンスのステータス、エラーコード (存在する場合) などの情報が取り込まれます。

Amazon S3 バケットでサーバーアクセスログを有効にしても追加料金は発生しません。また、ログがバケットに PUT されても料金は発生しません。ただし、システムからお客様のバケットに配信されるいずれのログファイルの保存に対しても通常の料金が発生します。これらのログファイルはいつでも削除できます。これらのログファイルに対する以降の読み取りやその他のリクエストに対しては、他のオブジェクトに対してと同様、通常どおり、データ転送料金などの料金が発生します。

ログ記録はデフォルトでは無効になっています。ログ記録が有効になっている場合、ログはソースバケットと同じ AWS リージョンのバケットに保存されます。

ログ記録を有効にするには、次の手順に従います。

  1. モニタリングする Amazon S3 バケットのログ記録を有効にします。このバケットをソースバケットと呼びます。

  2. アクセスログの保存先のバケットに対する書き込みアクセス許可を Amazon S3 ログ配信グループに付与します。このバケットをターゲットバケットと呼びます。

注記
  • Amazon S3 では、バケットのアクセスコントロールリスト (ACL) を使用してアクセスログを配信するアクセス許可を付与できますが、バケットポリシーでは付与できません。

  • バケットポリシーに拒否の条件を追加すると、Amazon S3 からアクセスログを配信できなくなる場合があります。

  • ターゲットバケットのデフォルトの暗号化は、AES256 (SSE-S3) が選択されている場合にのみ使用できます。SSE-KMS 暗号化はサポートされていません。

  • S3 オブジェクトロックをターゲットバケットで有効にすることはできません。

ログの配信を有効にするには、次の手順に従います。

  1. Amazon S3 でアクセスログをオブジェクトとして保存するターゲットバケットの名前を指定します。ソースバケットとターゲットバケットの両方が同じ AWS リージョンにあり、同じアカウントによって所有されている必要があります。

    ログの保存先のバケットとして、ソースバケットと同じリージョンにあるユーザー所有のバケットを指定できます。これにはソースバケット自体も含まれます。ただし、ログを管理しやすくするため、アクセスログは別のバケットに保存することをお勧めします。

    ソースバケットとターゲットバケットが同じである場合、バケットに書き込まれるログに関する追加のログが作成されます。これは、ストレージの請求額がいくらか増える可能性があるため、望ましくない場合があります。また、ログに関する追加のログのために、必要なログを見つけにくくなります。アクセスログの保存先をソースバケットにする場合は、ログオブジェクトを簡単に区別できるように、すべてのログオブジェクトキーにプレフィックスを指定し、オブジェクト名を共通の文字列で始めてください。

    キープレフィックスは、複数のバケットが同じターゲットバケットにログを記録する場合に、ソースバケットを区別するためにも役立ちます。

  2. (オプション) Amazon S3 のすべてのログオブジェクトのキーにプレフィックスを割り当てます。プレフィックスを使用すると、ログオブジェクトを見つけやすくなります。例えば、プレフィックスの値として logs/ を指定すると、Amazon S3 で作成する各ログオブジェクトのキーの先頭に logs/ というプレフィックスが付きます。

    logs/2013-11-01-21-32-16-E568B2907131C0C0

    キープレフィックスは、ログを削除するときにも役立ちます。たとえば、Amazon S3 のライフサイクル設定ルールを指定し、特定のキープレフィックスを持つオブジェクトを削除できます。詳細については、「Amazon S3 ログファイルの削除」を参照してください。

  3. (オプション) 作成されたログを他のユーザーが利用するためのアクセス許可を設定します。デフォルトでは、バケット所有者のみにログオブジェクトへのフルアクセスが許可されます。

サーバーアクセスのログ記録を有効にする方法の詳細については、「コンソールを使用したログ記録の有効化」と「プログラムでのログ記録の有効化」を参照してください。

ログオブジェクトのキーフォーマット

Amazon S3 では、ターゲットバケットにログオブジェクトをアップロードする際に、以下のオブジェクトキーフォーマットを使用します。

TargetPrefixYYYY-mm-DD-HH-MM-SS-UniqueString/

このキーで、YYYYmmDDHHMMSS は、ログファイルを配信した年、月、日、時、分、秒をそれぞれ表す数字です。これらの日付と時刻は協定世界時 (UTC) です。

ある時点で配信されたログファイルには、その時点より前に書き込まれたレコードが含まれます。特定の期間のすべてのログレコードが配信されたかどうかを知る方法はありません。

キーの UniqueString コンポーネントは、ファイルの上書きを防止するためのものです。意味はないため、ログ処理ソフトウェアでは無視されます。

プレフィックスの末尾であることを示すには、末尾のスラッシュ / が必要です。

ログを配信する方法

Amazon S3 は、アクセスログレコードを定期的に収集してログファイルにまとめ、そのログファイルをログオブジェクトとしてターゲットバケットにアップロードします。複数のソースバケットでログ記録の配信先が同じターゲットバケットである場合、これらのすべてのソースバケットのアクセスログがターゲットバケットに収容されます。ただし、各ログオブジェクトは、ソースバケット別にアクセスログレコードをレポートします。

Amazon S3 は、ログ配信グループと呼ばれる特別なログ配信アカウントを使用してアクセスログを書き込みます。このような書き込みは、通常のアクセスコントロールの制約に従います。ログ配信グループにターゲットバケットへの書き込みアクセス許可を付与するには、ターゲットバケットのアクセスコントロールリスト (ACL) に付与エントリを追加する必要があります。Amazon S3 コンソールを使用してバケットへのログ記録を有効にすると、コンソールは、ソースバケットでのログ記録の有効化とターゲットバケットでの ACL の更新の両方を行って、ログ配信グループに書き込みアクセス許可を付与します。

ベストエフォート型のサーバーログ配信

サーバーアクセスログレコードの配信は、ベストエフォートで行われます。ログ記録用に適切にバケットを設定した場合、そのバケットへのほとんどのリクエストについてログレコードが配信されます。ほとんどのログレコードは、記録された時間から数時間以内に配信されますが、配信間隔は短くなる場合もあります。

サーバーログの完全性や適時性は保証されません。リクエストのログレコードが、リクエストが実際に処理されてからかなり後に配信されたり、配信すらされないこともあり得ます。サーバーログの目的は、バケットに対するトラフィックの特性を理解することです。ログレコードが失われることはまれですが、すべてのリクエストが完全に報告されるとは限りません。

サーバーのログ作成機能はベストエフォート型であるため、AWS ポータルで利用できる使用状況レポート (AWS マネジメントコンソール でレポートされる請求およびコスト管理レポート) には、サーバーログに記録されていないアクセスリクエストが含まれる場合があります。

バケットのログ記録ステータスの変更が有効になるまでには時間がかかる

バケットのログ記録ステータスの変更がログファイルの配信に反映されるまでには時間がかかります。たとえば、バケットのログを有効にする場合、その後数時間に行われるリクエストは記録されることもあれば、されないこともあります。ログ記録のターゲットバケットをバケット A からバケット B に変更すると、その後 1 時間は一部のログがバケット A に引き続き配信されたり、新しいターゲットバケット B に配信されたりします。いずれにしても、最終的に新しい設定が有効になるため、ユーザー側の操作は一切不要です。