AWS Lambda + SQSで発生する意外なランニングコスト

事象

AWS LambdaのイベントソースにSQSを指定していた時、メッセージ数の有無に関わらずSQSに $0.01/日 のコストが発生していました。

SQSに流れるメッセージ数を調査したところ無料枠を超える件数はなかったため、このコストの正体が分からず、原因を突き止めるのに時間がかかりました。

コストの詳細

コストエクスプローラにて確認します。
フィルタ条件は以下の通り。

• Group by: API Operation
• Filters
  • Service: SQS
  • Usage Type: APN1-Requests-Tier1 (Requests)

毎日 ReceiveMessage と GetQueueAttributes のAPIを大量に実行しています。

• ReceiveMessage は1日あたり約21,580回（1時間あたり約900回、1分あたり約15回）
• GetQueueAttributes は1日あたり約1,440回（1時間あたり約60回）

メッセージの受信有無に関わらず、一定間隔で実行されているものと思われます。

原因

ずばり、以下の記事で言及されていました。

AWS Lambda Adds Amazon Simple Queue Service to Supported Event Sources

Additional Information

There are no additional charges for this feature, but because the Lambda service is continuously long-polling the SQS queue the account will be charged for those API calls at the standard SQS pricing rates.

ざっくり翻訳してみます。

この機能（SQSをイベントソースとすること）自体に追加料金はかかりませんが、LambdaはSQSキューを継続的にポーリングしているため、それらのAPI呼び出しは標準のSQS価格レートにて課金されます。

つまり、Lambda + SQS の構成を組む場合は内部的なAPI呼び出しが発生し、構成の数や内容によっては無料枠を超えてコストが発生するということでした。

今回私の環境では $0.01/日 でしたが、構成によってはもっとかかるかもしれません。

対処

いくつか考えられます。ざっと思いつくのは以下2案。

1. 必要経費としてこのままで行くか
2. Lambda + SQS ではない別の組み合わせで実現するか

今回は要件的に必ずしも前者である必要がなかったため、別の構成で作り変えることで対応しました（SQSによるリアルタイム処理ではなく、CloudWatchEventsによる定期実行に変更した）。

要件によって適切な構成は異なるので、どうしても Lambda + SQS で処理しなければならない場合は、必要経費として割り切りましょう。最初から予算に組み込んでおくと、後から慌てなくてよいと思います。

所感

ランニングコストのモニタリングは必ず行い、おかしいと思ったら必ず調査しましょう。