メニュー
Amazon Simple Storage Service
開発者ガイド (API Version 2006-03-01)

Amazon S3 イベント通知の設定

Amazon S3 通知機能により、バケット内で特定のイベントが発生したときに、通知を受けることができます。通知を有効にするには、まず通知設定を追加して、Amazon S3 で発行する必要のあるイベントと、Amazon S3 がそのイベント通知を送信する宛先を指定します。この設定は、バケットに関連付けられた notification サブリソースに保存します(「バケット設定オプション」を参照)。Amazon S3 は、このサブリソースを管理するための API も提供します。

概要

現在、Amazon S3 は次のイベントを発行できます。

  • 新しいオブジェクトの作成イベント - Amazon S3 ではオブジェクトを作成するために複数の API をサポートします。特定の API が使用されたときのみ通知をリクエストする(たとえば s3:ObjectCreated:Put)か、ワイルドカードを使用して(たとえば s3:ObjectCreated:*)、API にかかわらずオブジェクトが作成されたときに通知をリクエストできます。

  • オブジェクト削除イベント - Amazon S3 は、バージョニングが有効なオブジェクトとバージョニングが無効なオブジェクトの削除をサポートしています。オブジェクトのバージョニングについては、「オブジェクトのバージョニング」と「バージョニングの使用」を参照してください。

    s3:ObjectRemoved:Delete イベントタイプを使用することで、オブジェクトが削除されたとき、またはバージョニングが有効なオブジェクトが完全に削除されたときに通知が送信されるようにリクエストできます。または、s3:ObjectRemoved:DeleteMarkerCreated を使用することで、バージョニングが有効なオブジェクトに対して削除マーカーが作成されたとき通知が送信されるようにリクエストできます。ワイルドカードとして s3:ObjectRemoved:* を使用することで、オブジェクトが削除されるたびに通知が送信されるようにリクエストできます。バージョニングが有効なオブジェクトの削除については、「オブジェクトバージョンの削除」を参照してください。

  • 低冗長化ストレージ (RRS) オブジェクト消失イベント - Amazon S3 は RRS ストレージクラスのオブジェクトが消失したことを検出すると、通知メッセージを送信します。

サポートされるイベントタイプのリストについては、「サポートされるイベントタイプ」を参照してください。

Amazon S3 は、次の宛先に対してイベントを発行できます。

  • Amazon Simple Notification Service (Amazon SNS) トピック

    Amazon SNS は、柔軟性に優れたフルマネージド型のプッシュメッセージングサービスです。このサービスを使用すると、モバイルデバイスまたは分散サービスにメッセージをプッシュすることができます。SNS を使用すれば、一度メッセージを発行するだけで、何回も配信できます。SNS トピックは、受取人がイベント通知を受け取るために動的にサブスクライブできるアクセスポイントです。SNS の詳細については、Amazon SNS の製品詳細ページを参照してください。

  • Amazon Simple Queue Service (Amazon SQS) キュー

    Amazon SQS は、スケーラブルな、フルマネージド型のメッセージキューサービスです。SQS を使用すると、どのような量のデータでも転送することができ、他のサービスが常に利用可能である必要もありません。通知設定で、Amazon S3 が SQS キューにイベントを発行するようにリクエストすることができます。SQS の詳細については、Amazon SQS の製品詳細ページを参照してください。

  • AWS Lambda

    AWS Lambda は、新しい情報に迅速に対応できるアプリケーションを容易に構築できるコンピューティングサービスです。AWS Lambda は、イメージのアップロード、アプリ内のアクティビティ、ウェブサイトのクリック、接続されたデバイスからの出力などのイベントに対する応答としてコードを実行します。AWS Lambda を使用して、他の AWS サービスをカスタムロジックで拡張したり、AWS のスケール、パフォーマンス、セキュリティで動作する独自のバックエンドを作成したりすることができます。AWS Lambda を使用すると、必要なときだけ実行される個別のイベント駆動型アプリケーションを簡単に作成し、1 日あたり数回のリクエストから 1 秒あたり数千のリクエストまで自動的にスケーリングできます。

    AWS Lambda は、Amazon S3 バケットのイベントに対する応答としてカスタムコードを実行できます。カスタムコードを AWS Lambda にアップロードして、いわゆる Lambda 関数を作成します。Amazon S3 は特定のタイプのイベント(たとえば、オブジェクトが作成したイベント)を検出すると、そのイベントを AWS Lambda に発行し、Lambda で関数を呼び出します。それに応じて、AWS Lambda が関数を実行します。詳細については、AWS Lambda の製品詳細ページを参照してください。

次のセクションでは、バケットでイベント通知を有効化する方法について説明します。サブトピックでは、通知機能について学習するのに役立つチュートリアル例を提供します。

イベント通知を有効にする方法

通知の有効化はバケットレベルのオペレーションです。つまり、通知設定情報は、バケットに関連付けられた notification サブリソースに保存します。次のいずれかの方法を使用して通知設定の管理を行います。

  • Amazon S3 コンソールを使用して

    コンソール UI では、コードを記述しなくても、バケットの通知設定を指定できます。手順については、「S3 バケットのイベント通知を有効化および設定する方法」(Amazon Simple Storage Service コンソールユーザーガイド) を参照してください。

  • プログラムで AWS SDK を使用して

    注記

    必要に応じて、コードから直接 Amazon S3 REST API を呼び出すこともできます。ただし、この方法は、リクエストを認証するためのコードを作成する必要があるため面倒な場合もあります。

    内部的には、コンソールも SDK も Amazon S3 REST API を呼び出して、バケットに関連付けられた notification サブリソースを管理します。AWS SDK を使用する通知設定の例は、前のセクションで紹介したチュートリアルのリンクを参照してください。

    使用する方法にかかわらず、Amazon S3 は通知設定を XML として、バケットに関連付けられた notification サブリソースに格納します。バケットのサブリソースの詳細ついては、「バケット設定オプション」を参照してください。デフォルトでは、通知はどのタイプのイベントにも有効になりません。したがって、最初は notification サブリソースに空の設定が格納されています。

    Copy
    <NotificationConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> </NotificationConfiguration>

    特定のタイプのイベントに対して通知を有効にするには、XML を、Amazon S3 がパブリッシュするイベントのタイプとパブリッシュ先を識別する適切な設定に置き換えます。各宛先には、対応する XML 設定を追加します。(例:

    • イベントメッセージを SQS キューに発行する - SQS キューを 1 つ以上のイベントタイプの通知の宛先として設定するには、QueueConfiguration を追加します。

      Copy
      <NotificationConfiguration> <QueueConfiguration> <Id>optional-id-string</Id> <Queue>sqs-queue-arn</Queue> <Event>event-type</Event> <Event>event-type</Event> ... </QueueConfiguration> ... </NotificationConfiguration>
    • SNS トピックにイベントメッセージを発行する - SNS トピックを特定のイベントタイプの通知の宛先として設定するには、TopicConfiguration を追加します。

      Copy
      <NotificationConfiguration> <TopicConfiguration> <Id>optional-id-string</Id> <Topic>sns-topic-arn</Topic> <Event>event-type</Event> <Event>event-type</Event> ... </TopicConfiguration> ... </NotificationConfiguration>
    • AWS Lambda 関数を呼び出し、引数としてイベントメッセージを指定します。Lambda 関数を、特定のイベントタイプの通知送信先として設定するには、CloudFunctionConfiguration を追加します。

      Copy
      <NotificationConfiguration> <CloudFunctionConfiguration>    <Id>optional-id-string</Id>    <Cloudcode>cloud-function-arn</Cloudcode>         <Event>event-type</Event>       <Event>event-type</Event>       ...   </CloudFunctionConfiguration> ... </NotificationConfiguration>

    バケットに設定されたすべての通知を削除するには、notification サブリソースに空の <NotificationConfiguration/> エレメントを保存します。

    Amazon S3 は、特定のタイプのイベントを検出すると、そのイベント情報を含むメッセージをパブリッシュします。詳細については、「イベントメッセージの構造」を参照してください。

イベント通知のタイプおよび送信先

このセクションでは、Amazon S3 でサポートされているイベント通知のタイプと、通知のパブリッシュ先のタイプについて説明します。

サポートされるイベントタイプ

Amazon S3 は、次のタイプのイベントを発行できます。通知設定で、これらのイベントタイプを指定します。

イベントタイプ 説明

s3:ObjectCreated:*

s3:ObjectCreated:Put

s3:ObjectCreated:Post

s3:ObjectCreated:Copy

s3:ObjectCreated:CompleteMultipartUpload

PUT、POST、COPY などの Amazon S3 API はオブジェクトを作成できます。これらのイベントタイプを使用すると、特定の API を使用してオブジェクトが作成されたときに通知を有効化できます。また、s3:ObjectCreated:* イベントタイプを使用すると、オブジェクトを作成するために使用された API にかかわらず通知をリクエストすることができます。

失敗したオペレーションについてはイベント通知を受け取りません。

s3:ObjectRemoved:*

s3:ObjectRemoved:Delete

s3:ObjectRemoved:DeleteMarkerCreated

[ObjectRemoved] イベントタイプを使用することで、1 つ以上のオブジェクトがバケットから削除されたときに通知が送信されるように設定できます。

[s3:ObjectRemoved:Delete] イベントタイプを使用することで、オブジェクトが削除されたとき、またはバージョニングが有効なオブジェクトが完全に削除されたときに通知が送信されるようにリクエストできます。または、[s3:ObjectRemoved:DeleteMarkerCreated] を使用することで、バージョニングが有効なオブジェクトに対して削除マーカーが作成されたとき通知が送信されるようにリクエストできます。バージョニングが有効なオブジェクトの削除については、「オブジェクトバージョンの削除」を参照してください。ワイルドカードとして s3:ObjectRemoved:* を使用することで、オブジェクトが削除されるたびに通知が送信されるようにリクエストできます。

ライフサイクルポリシーからの自動削除または失敗したオペレーションについてはイベント通知を受け取りません。

s3:ReducedRedundancyLostObject このイベントタイプを使用して、Amazon S3 が RRS ストレージクラスのオブジェクトが失われたことを検出したときに、通知メッセージを送信するように Amazon S3 にリクエストできます。

サポートされる宛先

Amazon S3 は、次の宛先にイベントの通知メッセージを送信できます。通知設定でこれらの宛先の ARN 値を指定します。

  • イベントメッセージを Amazon Simple Notification Service (Amazon SNS) トピックに発行する

  • イベントメッセージを Amazon Simple Queue Service (Amazon SQS) キューに発行する

    注記

    現時点で S3 は、サーバー側暗号化 (SSE) が有効になっていないスタンダード SQS キューのみをサポートします。

  • Lambda 関数を呼び出し、引数としてイベントメッセージを指定することによって、イベントメッセージを AWS Lambda に発行する

Amazon SNS トピックまたは Amazon SQS キューにメッセージを投稿するためのアクセス許可を Amazon S3 に付与する必要があります。また、代わりに AWS Lambda 関数を呼び出す場合も Amazon S3 アクセス権限を付与する必要があります。これらのアクセス許可の付与については、「宛先にイベント通知メッセージを発行するためのアクセス権限の付与」を参照してください。

オブジェクトキー名によるフィルタリングを使用した通知の設定

通知がオブジェクトのキー名のプレフィックスまたはサフィックスでフィルタリングされるように設定できます。たとえば、".jpg" 拡張子の付いたイメージファイルがバケットに追加されたときにのみ通知が送信されるように設定できます。または、"images/" というプレフィックスの付いたオブジェクトがバケットに追加されたときに Amazon SNS トピックに通知が送信されるように設定したり、同じバケットにある "logs/" というプレフィックスの付いたオブジェクトが AWS Lambda 関数に渡されたときに通知が送信されるように設定したりできます。

Amazon S3 コンソールで、AWS SDK で Amazon S3 API を使用して、または直接 REST API を使用して、オブジェクトキー名によるフィルタリングを使用する通知設定をセットアップできます。コンソール UI を使用してバケットでの通知を設定する方法については、「S3 バケットのイベント通知を有効化および設定する方法」(Amazon Simple Storage Service コンソールユーザーガイド) を参照してください。

Amazon S3 は、「イベント通知を有効にする方法 」で説明されているように、バケットに関連付けられている notification サブリソースに通知設定を XML 形式で保存します。Filter XML 構造を使用して、オブジェクトキー名のプレフィックスまたはサフィックスでフィルタリングされる通知のルールを定義します。Filter XML の構造の詳細については、『Amazon Simple Storage Service API Reference』の「PUT Bucket 通知」を参照してください。

Filter を使用する通知設定では、プレフィックスの重複、サフィックスの重複、またはプレフィックスとサフィックスの重複があるフィルタリングルールを定義できません。以下のセクションでは、オブジェクトキー名によるフィルタリングを使用した通知設定の例と、プレフィックスまたはサフィックスが重複しているため無効である通知設定の例を示します。

オブジェクトキー名によるフィルタリングを使用した有効な通知設定の例

次の通知設定には、Amazon SQS キューを識別するキュー設定が含まれており、これにより Amazon S3 は s3:ObjectCreated:Put タイプのイベントをパブリッシュできます。イベントは、images/ というプレフィックスと jpg というサフィックスの付いたオブジェクトがバケットに PUT(作成)されるたびにパブリッシュされます。

Copy
<NotificationConfiguration> <QueueConfiguration> <Id>1</Id> <Filter> <S3Key> <FilterRule> <Name>prefix</Name> <Value>images/</Value> </FilterRule> <FilterRule> <Name>suffix</Name> <Value>jpg</Value> </FilterRule> </S3Key> </Filter> <Queue>arn:aws:sqs:us-west-2:444455556666:s3notificationqueue</Queue> <Event>s3:ObjectCreated:Put</Event> </QueueConfiguration> </NotificationConfiguration>

次の通知設定には、複数の重複していないプレフィックスがあります。この設定では、images/ フォルダー内の PUT リクエストの通知は queue-A に送信され、logs/ フォルダー内の PUT リクエストの通知は queue-B に送信されるように定義されています。

Copy
<NotificationConfiguration> <QueueConfiguration> <Id>1</Id> <Filter> <S3Key> <FilterRule> <Name>prefix</Name> <Value>images/</Value> </FilterRule> </S3Key> </Filter> <Queue>arn:aws:sqs:us-west-2:444455556666:sqs-queue-A</Queue> <Event>s3:ObjectCreated:Put</Event> </QueueConfiguration> <QueueConfiguration> <Id>2</Id> <Filter> <S3Key> <FilterRule> <Name>prefix</Name> <Value>logs/</Value> </FilterRule> </S3Key> </Filter> <Queue>arn:aws:sqs:us-west-2:444455556666:sqs-queue-B</Queue> <Event>s3:ObjectCreated:Put</Event> </QueueConfiguration> </NotificationConfiguration>

次の通知設定には、複数の重複していないサフィックスがあります。この設定では、バケットに新しく追加される .jpg イメージはすべて Lambda の cloud-function-A によって処理され、新しく追加される .png イメージはすべて cloud-function-B によって処理されるように定義されています。.png と .jpg は、末尾の 1 文字が同じであっても、重複していると見なされません。文字列が両方のサフィックスで終わる可能性がある場合には、重複していると見なされます。文字列が .png と .jpg の両方で終わることはないので、この設定例の 2 つのサフィックスは重複していません。

Copy
<NotificationConfiguration> <CloudFunctionConfiguration> <Id>1</Id> <Filter> <S3Key> <FilterRule> <Name>suffix</Name> <Value>.jpg</Value> </FilterRule> </S3Key> </Filter> <Cloudcode>arn:aws:lambda:us-west-2:444455556666:cloud-function-A</Cloudcode> <Event>s3:ObjectCreated:Put</Event> </CloudFunctionConfiguration> <CloudFunctionConfiguration> <Id>2</Id> <Filter> <S3Key> <FilterRule> <Name>suffix</Name> <Value>.png</Value> </FilterRule> </S3Key> </Filter> <Cloudcode>arn:aws:lambda:us-west-2:444455556666:cloud-function-B</Cloudcode> <Event>s3:ObjectCreated:Put</Event> </CloudFunctionConfiguration> </NotificationConfiguration>

Filter を使用する通知設定では、同じイベントタイプのプレフィックスが重複しているフィルタリングルールを定義できません。プレフィックスが重複していても、サフィックスが重複していない場合は、これに該当しません。次の設定例は、プレフィックスは重複しており、サフィックスは重複していないオブジェクトがどのように別々の場所に送られるかを示しています。

Copy
<NotificationConfiguration> <CloudFunctionConfiguration> <Id>1</Id> <Filter> <S3Key> <FilterRule> <Name>prefix</Name> <Value>images</Value> </FilterRule> <FilterRule> <Name>suffix</Name> <Value>.jpg</Value> </FilterRule> </S3Key> </Filter> <Cloudcode>arn:aws:lambda:us-west-2:444455556666:cloud-function-A</Cloudcode> <Event>s3:ObjectCreated:Put</Event> </CloudFunctionConfiguration> <CloudFunctionConfiguration> <Id>2</Id> <Filter> <S3Key> <FilterRule> <Name>prefix</Name> <Value>images</Value> </FilterRule> <FilterRule> <Name>suffix</Name> <Value>.png</Value> </FilterRule> </S3Key> </Filter> <Cloudcode>arn:aws:lambda:us-west-2:444455556666:cloud-function-B</Cloudcode> <Event>s3:ObjectCreated:Put</Event> </CloudFunctionConfiguration> </NotificationConfiguration>

無効なプレフィックス/サフィックスが重複している通知設定の例

Filter を使用する通知設定では、通常、同じイベントタイプのプレフィックスが重複している、サフィックスが重複している、またはプレフィックスとサフィックスの組み合わせが重複しているフィルタリングルールを定義できません。サフィックスが重複していなければ、プレフィックスが重複していても問題ありません。その例については、「オブジェクトキー名によるフィルタリングを使用した通知の設定」を参照してください。

イベントタイプが異なれば、重複しているオブジェクトキー名フィルタを使用できます。たとえば、ObjectCreated:Put イベントタイプにプレフィックス image/ を使用すると同時に、ObjectDeleted:* イベントタイプにプレフィックス image/ を使用する通知設定を作成できます。

AWS Amazon S3 コンソールまたは Amazon S3 API を使用しているときに、同じイベントタイプに対して無効な重複しているオブジェクトキー名フィルタを使用する通知設定を保存しようとすると、エラーが発生します。このセクションでは、オブジェクトキー名フィルタが重複しているため無効である通知設定の例を示します。

既存の通知設定ルールのデフォルトのプレフィックスまたはサフィックスが、他のプレフィックスまたはサフィックスと一致する可能性があります。次の通知設定は、重複しているプレフィックスがある、つまりルートプレフィックスが他のプレフィックスと重複しているため無効です。この例でプレフィックスではなくサフィックスを使用する場合も無効です。ルートサフィックスが他のサフィックスと重複します。

Copy
<NotificationConfiguration> <TopicConfiguration> <Topic>arn:aws:sns:us-west-2:444455556666:sns-notification-one</Topic> <Event>s3:ObjectCreated:*</Event> </TopicConfiguration> <TopicConfiguration> <Topic>arn:aws:sns:us-west-2:444455556666:sns-notification-two</Topic> <Event>s3:ObjectCreated:*</Event> <Filter> <S3Key> <FilterRule> <Name>prefix</Name> <Value>images</Value> </FilterRule> </S3Key> </Filter> </TopicConfiguration> </NotificationConfiguration>

次の通知設定は、重複しているサフィックスがあるため無効です。文字列が両方のサフィックスで終わる可能性がある場合には、重複していると見なされます。文字列が jpgpg の両方で終わる可能性があるため、サフィックスは重複しています。これはプレフィックスについても同じであり、文字列が両方のプレフィックスで始まる可能性があれば、プレフィックスは重複していると見なされます。

Copy
<NotificationConfiguration> <TopicConfiguration> <Topic>arn:aws:sns:us-west-2:444455556666:sns-topic-one</Topic> <Event>s3:ObjectCreated:*</Event> <Filter> <S3Key> <FilterRule> <Name>suffix</Name> <Value>jpg</Value> </FilterRule> </S3Key> </Filter> </TopicConfiguration> <TopicConfiguration> <Topic>arn:aws:sns:us-west-2:444455556666:sns-topic-two</Topic> <Event>s3:ObjectCreated:Put</Event> <Filter> <S3Key> <FilterRule> <Name>suffix</Name> <Value>pg</Value> </FilterRule> </S3Key> </Filter> </TopicConfiguration> </NotificationConfiguration

次の通知設定は、重複しているプレフィックスとサフィックスがあるため無効です。

Copy
<NotificationConfiguration> <TopicConfiguration> <Topic>arn:aws:sns:us-west-2:444455556666:sns-topic-one</Topic> <Event>s3:ObjectCreated:*</Event> <Filter> <S3Key> <FilterRule> <Name>prefix</Name> <Value>images</Value> </FilterRule> <FilterRule> <Name>suffix</Name> <Value>jpg</Value> </FilterRule> </S3Key> </Filter> </TopicConfiguration> <TopicConfiguration> <Topic>arn:aws:snsus-west-2:444455556666:sns-topic-two</Topic> <Event>s3:ObjectCreated:Put</Event> <Filter> <S3Key> <FilterRule> <Name>suffix</Name> <Value>jpg</Value> </FilterRule> </S3Key> </Filter> </TopicConfiguration> </NotificationConfiguration>

宛先にイベント通知メッセージを発行するためのアクセス権限の付与

Amazon S3 が宛先にメッセージを発行できるようにするには、該当する API を呼び出して、SNS トピック、SQS キュー、または Lambda 関数にメッセージを発行するために必要なアクセス権限を事前に Amazon S3 プリンシパルに付与しておく必要があります。

AWS Lambda 関数を呼び出すためのアクセス権限の付与

Amazon S3 は Lambda 関数を呼び出してイベントメッセージを AWS Lambda に発行し、イベントメッセージを引数として指定します。

Amazon S3 コンソールを使用して、Lambda 関数で Amazon S3 バケットのイベント通知を設定する場合、Amazon S3 コンソールは Lambda で必要なアクセス権限を設定し、Amazon S3 がバケットから関数を呼び出すアクセス権限を持つようにします。詳細については、「S3 バケットのイベント通知を有効化および設定する方法」(Amazon Simple Storage Service コンソールユーザーガイド) を参照してください。

AWS Lambda から Amazon S3 アクセス権限を付与して、Lambda 関数を呼び出すこともできます。詳細については、「AWS Lambda Developer Guide」の「チュートリアル: Amazon S3 で AWS Lambda を使用する」を参照してください。

SNS トピックまたは SQS キューにメッセージを発行するためのアクセス権限の付与

IAM ポリシーを宛先の SNS トピックまたは SQS キューにアタッチして、SNS トピックまたは SQS キューにメッセージを発行する Amazon S3 アクセス権限を付与します。

宛先の SNS トピックにアタッチする IAM ポリシーの例。

Copy
{ "Version": "2008-10-17", "Id": "example-ID", "Statement": [ { "Sid": "example-statement-ID", "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com" }, "Action": [ "SNS:Publish" ], "Resource": "SNS-ARN", "Condition": { "ArnLike": {         "aws:SourceArn": "arn:aws:s3:*:*:bucket-name" } } } ] }

宛先の SQS キューにアタッチする IAM ポリシーの例。

Copy
{ "Version": "2008-10-17", "Id": "example-ID", "Statement": [ { "Sid": "example-statement-ID", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "SQS:SendMessage" ], "Resource": "SQS-ARN", "Condition": { "ArnLike": {         "aws:SourceArn": "arn:aws:s3:*:*:bucket-name" } } } ] }

Amazon SNS および Amazon SQS IAM ポリシーの両方について、ArnLike 条件の代わりに StringLike 条件をポリシーで指定できます。

Copy
"Condition": {        "StringLike": {         "aws:SourceArn": "arn:aws:s3:*:*:bucket-name"        } }

SNS トピックまたは SQS キューにポリシーをアタッチする方法の例については、「チュートリアル例 1: バケットを通知用に設定する(メッセージの宛先: SNS トピックおよび SQS キュー)」を参照してください。

アクセス権限の詳細については、次のトピックを参照してください。