AWS S3バケットログとAWS Cloudtrail
AWS S3ログとAWS CloudTrailの違いは何ですか？ CloudTrailのドキュメントで私はこれを見ました：
CloudTrailは、AWSによってすでに提供されているモニタリング機能に別の次元を追加します。すでに使用している可能性のあるロギング機能を変更または置き換えません。
CloudTrailは、インフラストラクチャ変更イベントのAPIアクセスを追跡します。S3では、これはバケットの作成、削除、および変更を意味します（ S3 CloudTrail docs ）。バケットを変更するAPIメソッドに重点を置いています。
S3サーバーアクセスログ S3バケット内のオブジェクトへのアクセスのWebサーバースタイルのログを提供します。このロギングはオブジェクトに対してきめ細かく、読み取り専用の操作が含まれ、静的なWebサイトの閲覧などの非APIアクセスが含まれます。
S3サーバーアクセスログではなくCloudTrailログを使用する理由は2つあります。
- バケットレベルのアクティビティロギングに関心がある。 CloudTrailにはそれがありますが、S3ログにはありません。
- CloudWatchログストリームを含むログ分析設定があります。基本的なS3ログは、ログイベントを一部のS3バケット上のファイルに保存するだけで、そこからそれらを処理する必要があります（ほとんどのログ分析サービスがこれを行うことができます）。
結論：それを必要とする特定のシナリオがある場合は、追加費用がかかるCloudTrailを使用します。それ以外の場合は、「標準」のS3サーバーアクセスログで十分です。
CloudTrail開発者ガイドから（ https://docs.aws.Amazon.com/AmazonS3/latest/dev/cloudtrail-logging.html ）：
Amazon S3サーバーアクセスログおよびCloudWatchログでCloudTrailログを使用する
AWS CloudTrailログは、Amazon S3のサーバーアクセスログと一緒に使用できます。 CloudTrailログは、Amazon S3バケットレベルおよびオブジェクトレベルの操作の詳細なAPI追跡を提供し、Amazon S3のサーバーアクセスログは、Amazon S3のデータに対するオブジェクトレベルの操作の可視性を提供します。サーバーアクセスログの詳細については、「Amazon S3サーバーアクセスログ」を参照してください。
CloudTrailログをCloudWatch for Amazon S3と一緒に使用することもできます。 CloudTrailとCloudWatchログの統合により、CloudTrailによってキャプチャされたS3バケットレベルのAPIアクティビティが、指定したCloudWatchロググループのCloudWatchログストリームに配信されます。特定のAPIアクティビティを監視するためのCloudWatchアラームを作成し、特定のAPIアクティビティが発生したときにメール通知を受信できます。特定のAPIアクティビティをモニタリングするためのCloudWatchアラームの詳細については、AWS CloudTrail User Guideを参照してください。 Amazon S3でCloudWatchを使用する方法の詳細については、「Amazon CloudWatchによるメトリクスのモニタリング」を参照してください。
この質問が行われて以来、AWSにはもう1つの機能、つまりCloudTrail Dataイベントが追加されています
現在利用可能な3つの機能があります。
- CloudTrail：バケットレベルでほぼすべてのAPI呼び出しをログに記録します Ref
- CloudTrail Data Events：オブジェクトレベルでほぼすべてのAPI呼び出しをログに記録します Ref
- S3サーバーアクセス：S3オブジェクトへのほとんどすべての（ ベストエフォートサーバーログ配信 ）アクセス呼び出しを記録します。 参照
さて、2と3は機能的には似ているように見えますが、いくつかの違いがあるため、ユーザーにどちらか一方または両方（この場合）を使用するように求める場合があります。以下は私が見つけることができる違いです：
- どちらも異なるレベルの粒度で機能します。例えばCloudTrailデータイベントは、AWSアカウントのすべてのS3バケットに対して、またはS3バケット内の一部のフォルダーに対してのみ設定できます。一方、S3サーバーアクセスログは個別のバケットレベルで設定されます。
- S3サーバーアクセスログは、BucketOwner、HTTPStatus、ErrorCodeなどのログに関するより包括的な情報を提供するようです。 完全なリスト
Cloudtrailログにはありませんが、サーバーアクセスログにはあります。 参照 ：
- ログレコードのオブジェクトサイズ、合計時間、ターンアラウンドタイム、およびHTTPリファラーのフィールド
- ライフサイクルの移行、有効期限、復元
- 一括削除操作でのキーのロギング
- 認証の失敗
- CloudTrailは、認証に失敗したリクエスト（提供された認証情報が有効でない）のログを配信しません。ただし、認証が失敗したリクエスト（AccessDenied）と匿名ユーザーによるリクエストのログは含まれます。
- リクエストが別のAWSアカウントによって行われた場合、バケットの所有者がリクエスト内のオブジェクトを所有しているか、そのオブジェクトへの完全なアクセス権を持っている場合にのみ、アカウントにCloudTrailログが表示されます。そうでない場合、ログは要求者のアカウントでのみ表示されます。ただし、同じリクエストのログは、追加の要件なしでアカウントのサーバーアクセスログに配信されます。
AWSサポートでは、CloudTrailログを使用して決定を行うことをお勧めします。CloudTrailログにはない追加情報も必要な場合は、サーバーアクセスログを使用できます。
AWS CloudTrailは、さまざまなAWSリソース上のすべてのアカウントアクティビティをログに記録するためのAWSサービスです。 IAMコンソールのログインなども追跡します。CloudTrailサービスが有効になったら、CloudTrailコンソールに移動してすべてのアクティビティを確認し、フィルターを適用することもできます。また、有効にすると、これらのアクティビティをログに記録してAWS CloudWatchにデータを送信することを選択できます。 AWS CloudWatchでは、フィルターを適用したり、特定の種類のアクティビティが発生したときに通知するアラームを作成したりできます。
S3ロギングは、S3バケット/オブジェクトの基本的なアクティビティのロギングを有効にします。
CloudTrailは、AWSアカウントにアクセスしたAPI呼び出しを記録します。これらのCloudTrailログはAmazon S3バケットに保存されます。
2つは異なるサービスを提供します。
CloudTrail Docから共有した定義：CloudTrailは、AWSによってすでに提供されているモニタリング機能に別の次元を追加します。変更または置換されませんすでに使用している可能性のあるロギング機能。
これは、ELBロギングなどの他のAWSサービスで提供される他のロギング機能のいくつかをすでにアクティブ化している可能性があることを意味します。ただし、CloudTrailモニタリングを有効にしても、以前のロギング機能は引き続きアクティブであるため、心配する必要はありません。すべてのサービスからログを受け取ります。したがって、CloudTrailのロギングを有効にしても、すでに使用している可能性のあるロギング機能は変更または置き換えられません。
それが役に立てば幸い.. ：）