はじめに
S3にファイルをアップロードする場合、アップロードしたファイルは完全に操作が完了したタイミングでS3側に反映をされるため、アップロードを中断しても断片的なファイルがアップロードされるということはありません。
単一のキーに対する更新はアトミックです。例えば、あるスレッドから既存のキーに PUT リクエストを実行し、同時に同じキーに対して別のスレッドから GET リクエストを実行すると、古いデータまたは新しいデータを取得できますが、データの一部分だけが取得されることも、破損することもありません。
ですが、Trnasfer Familyを経由してS3にファイルをアップロードする際、アップロードを中断をすると中断時点の断片的なファイルがそのままS3にアップロードする挙動をします。
問題点
例えば、以下のようなS3にアップロードしたファイルをトリガーに起動するLambda関数があるとします。
S3-Lambdaのみの構成であればS3イベント通知かEventBridge RuleでS3のオブジェクト作成イベントをトリガーにすることが一般的です。
何らかの理由でアップロードが中断した場合も断片的なファイルがS3にアップロードされることはなく、オブジェクト作成イベントもトリガーすることはありません。
次に、以下のようなTrnasfer Family経由でS3にアップロードしたファイルをトリガーに発火するLambda関数があるとします。
Trnasfer Family経由の構成でS3のオブジェクト作成イベントをトリガーにしてしまうと、断片的なファイルがS3にアップロードされた場合も後続のLambda関数が起動することになります。
このような断片的なファイルをトリガーに後続の処理を起動したくない場合は以下の対処法を参考にしてください。
対処法
S3イベントではなくEventBridge RuleにあるTransfarのイベントパターンをトリガーにします。
SFTPであれば[SFTP Server File Upload Completed]のイベントタイプをトリガーにすることでアップロード中断された際に後続の処理がトリガーされることはなくなります。
さいごに
なんらかの事情でFTP/SFTPを避けることができない場合にTransfer Familyはとても重宝します。
Transfer Familyを経由するかしないかでS3へのファイル更新の挙動が異なる点は理解しておきましょう。