s3:ObjectCreatedをイベントソースにするLambdaはオブジェクト作成時のメソッドに気をつける

2016.05.13

丹内です。S3へのオブジェクト作成で起動するLambdaと関わるRailsアプリを作るときに、すこしハマりました。

背景

carrierwaveuploader/carrierwave gemは、Ruby製webアプリからファイルをクラウドにアップロードする際によく使われる便利なgemです。
S3へアップロードさせたいときは、ストレージアダプタとしてsorentwo/carrierwave-awsfog/fogが使われることが多いと思います。
今回のアプリでは、最初carrierwave-awsを使っていましたが、諸事情によりfogへ切り替えたのですが、その時に問題が起こりました。

s3:ObjectCreated

「S3にオブジェクトが作成されたとき」というよくあるLambdaのイベントソースは、以下のものがあります。

  • s3:ObjectCreated:*
  • s3:ObjectCreated:Put
  • s3:ObjectCreated:Post
  • s3:ObjectCreated:Copy
  • s3:ObjectCreated:CompleteMultipartUpload

それぞれPUT、POST、COPYなどのS3 APIに対応しており、指定したメソッドでのみ起動するLambda Functionを設定できます。 ワイルドカードを使うと全てのメソッドで起動するLambda Functionとすることができます。

注意点

S3バケットへのオブジェクト作成方法のうち、ここではPUTとPOSTを考えます。 どちらもオブジェクトの作成ですが、POSTを使うとサーバを介さず直接S3にオブジェクトを作成することができます。 詳細はドキュメントをご覧ください。
Lambda Functionに指定したイベントソースに一致したメソッドでオブジェクトが作成された時のみ、Lambda Functionは起動します。
gemなどサードパーティ製のライブラリを使う場合は、どちらのメソッドを使っているかを確認しないと、ライブラリを変更した時に意図せずLambda Functionが起動しなくなるかもしれません。 あるいは、s3:ObjectCreated:*とワイルドカードを指定する必要があるかもしれません。

まとめ

ライブラリ自体がプラガブルでも、隠蔽しているAWSの操作には注意が必要です。
ライブラリを変更してから突然Lambda Funcitonが起動しなくなった際には、適切なイベントソースになっているかを確認してみてください。

参考URL