Amazon CloudWatch Logs の PutLogEvents API の単一ログストリームあたりのリクエストクォータがなくなり制限が緩和されました

Amazon CloudWatch Logs の PutLogEvents API の単一ログストリームあたりのリクエストクォータがなくなり制限が緩和されました

Clock Icon2023.01.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2022/11/4 のアップデートにより、AWS CloudWatch Logs の PutLogEvents API のクォータに単一ログストリームあたり秒間5リクエストまでの制限がなくなりました。加えて、PutLogsEvents API コール時に必須だったシーケンストークン付与が必須ではなくなりました。

なにがうれしいのか

単一ログストリームあたりのリクエスト数制限がなくなった

単一のログストリームにハイスループットでログを送信してもクォータに引っかかる可能性が減りました。しかし、引き続きリージョンレベルのクォータは有効です。制限に引っかることがなくなったわけではありませんが大幅に制限緩和され、CloudWatch Logs のクォータの考慮点がひとつ減りシンプルに利用できるようになりました。

従来は単一ログストリームあたり秒間5リクエストまでの制限がありました。以下の構成の様に複数の FireLens(Fluent Bit)コンテナから同じログストリームへログを送信すると従来の制限に引っかかりやすかったです。n個の Fluent Bit から 1ログストリームへですから無理もないですよね。ちなみに制限を超過するとThrottlingExceptionエラーが記録されます。

以前、FireLens(Fluent Bit)を利用したログルーティングで CloudWatch Logs へログを保存する際に秒間5リクエストのクォータに引っかかりThrottlingExceptionエラーを発生させた経験があります。

ログの送信先(保存先)を複数のログストリームにしてもThrottlingExceptionエラー発生する可能性はあります。ですが、単一のログストリームを指定してログを送信するよりはThrottlingExceptionエラーを防ぐ対策としては有効でした。1 Fluent Bitあたり1ログストリームですからね。

今回のアップデートで単一ログストリームのリクエスト制限がなくなりました。よりハイスループットでログを CloudWatch Logs のログストリームに送信しても安心です。ですが、引き続きリージョンレベルのクォータが有効です。とはいえログストリームへのログ送信量の制限は格段に引き上がありました。

ひとつのAWSアカウントに多数のシステムが稼働しており、CloudWatch Logs へ高頻度で大量のログを保存する必要がある場合はアカウントレベル、リージョンレベルで有効なサービスクォータを気にしつつ設計する必要があります。

CloudWatch Logs のクォータについては最新情報を確認しておくとよいです。

シーケントークンが必須ではなくなった

シーケンストークンが必須ではなくなりました。従来は PutLogEvents をコールするたびに CloudWatch から発行されるシーケンストークンが必要でした。予期していないシーケンストークンを受け取るとInvalidSequenceTokenエラーが発生します。InvalidSequenceTokenのエラー解消方法については以下の記事が詳しいのご参照ください。

2023/1/11追記
InvalidSequenceTokenエラーが発生しなくなったため、エラー対処のページが削除されていました。存在していたときの該当ページを画像で残しておきます。

以下の構成を例にすると FireLens で起動している Fluent Bitコンテナなどの複数のソースから単一のログストリームへログを送信時にInvalidSequenceTokenエラーが発生しがちな状況です。

後方互換を維持のために仮にシーケンストークンを付与、無効なシーケンストークンを付与してもInvalidSequenceTokenエラーを返さないようになったとのことです。

おわりに

ThrottlingExceptionエラーの件は複数のログストリームに分けても秒間5リクエスト制限が気がかりだったのですが、今回のアップデートでリージョンレベルのクォータを気にするだけで良くなりました。大幅な制限緩和な嬉しいアップデートでした。ということを共有したかったので図を書いた次第です。CloudWatch Logs の構成要素であるログストリームが一体どこの部分かきっとわかりにくいですから。InvalidSequenceTokenエラーの件は今まで直接確認したことはなかったのですが、シーケンストークンが必須ではなくなり考慮する事項がひとつ減りユーザーには嬉しいアップデートではないでしょうか。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.