REST API の実行ログが1KBで途切れて調査が止まった運用者向けに、自前の CloudWatch Logs・S3・Data Firehose へ最大1MBで送る配信設定の従来との違い、構成例、料金と対象範囲の確認点を整理する。
1MB REST API 実行ログ 1イベントの上限 従来は API Gateway 管理のロググループで1KBに切り詰め。自前の CloudWatch Logs・S3・Data Firehose へ配信する場合（AWS What's New、2026年9月10日）
REST API の実行ログを CloudWatch Logs で開くと、リクエストやレスポンスの中身が途中で切れている。原因だった上限に、2026年9月10日付の AWS の告知で変更が入った。実行ログを自前の CloudWatch Logs ロググループ、Amazon S3 バケット、Amazon Data Firehose ストリームへ、1イベント最大1MBで送れるようになり、複数の配信先へ同時に流すこともできる。対象は REST API の実行ログだ。
告知は従来の挙動をこう書いている。実行ログは API Gateway が管理する単一の CloudWatch Logs ロググループに配信され、ログイベントは1KBで切り詰められていた。その結果、リクエストとレスポンスのデータが見えにくかったというのが AWS 自身の説明である。
切れていたのはログが配信される時点での話で、Logs Insights のクエリを工夫しても、届いていない部分は取り戻せない。配信先も API Gateway 管理のロググループ1つに決まっていて、実行ログを別の保存先へ回す選択肢はなかった。
| 項目 | 従来 | 新しい配信設定 |
|---|---|---|
| 配信先 | API Gateway 管理の CloudWatch Logs ロググループ（単一） | 自前の CloudWatch Logs ロググループ、S3 バケット、Data Firehose ストリーム |
| ログイベントの大きさ | 1KBで切り詰め | 最大1MB |
| 複数の配信先 | 不可（単一の配信先） | 同時に配信できる |
| 料金 | 告知に記載なし | vended logs の料金 |
| 設定手段 | 告知に記載なし | API Gateway コンソール、AWS CLI、AWS CloudFormation |
出典：AWS What’s New「Amazon API Gateway now supports 1 MB execution logs with configurable delivery destinations」（2026年9月10日）
告知が構成例として挙げているのは、2つの配信先を同時に使う形だ。S3 には Apache Parquet 形式で送り、低コストで長期保存しながら Amazon Athena で分析する。同じ実行ログを CloudWatch Logs には構造化 JSON で送り、リアルタイムのアラートに使う。
後から掘り返すためのログと、いま異常に気づくためのログを、1本の流れから分岐させる考え方である。1KBの上限が外れるので、これまで途中で消えていたリクエストやレスポンスの部分も、1イベント1MBまでは S3 側に残る。障害の後で「あのとき何が返っていたか」を Athena で確かめる、という使い方が現実的になる。
例では S3 が Parquet、CloudWatch Logs が JSON と、配信先ごとに形式が違う。ただ、どの配信先でどの形式を選べるのか、組み合わせの全体は告知からは分からない。3つ目の配信先である Data Firehose も、告知の構成例には登場しない。
まず対象範囲を見ると、告知が扱っているのは REST API の実行ログで、HTTP API や WebSocket API には触れていない。提供リージョンは API Gateway の REST API が使えるすべてのリージョンで、AWS GovCloud (US) リージョンも含まれる。
次に料金。この仕組みで配信した実行ログは vended logs の料金で課金され、詳細は Amazon CloudWatch の料金ページを見るよう告知は案内している。金額は告知に書かれていない。ここからは推測だが、1イベントの上限が1KBから1MBへ広がる以上、リクエストやレスポンスが大きい API ではログの量が増えて請求に響く可能性がある。複数の配信先へ同時に送る場合も、配信先ごとの課金がどうなるかは料金ページで見積もってから決めたい。
最後に既存の設定との関係で、ここは切り替える前に必ず押さえておきたい。告知には書かれていないが、AWS が2026年9月9日に公開したブログ記事によると、新しい配信を作ると実行ログは自前の配信先へ置き換わって流れ、API Gateway 管理のロググループ（API-Gateway-Execution-Logs_ に REST API ID とステージ名が続くもの）には届かなくなる。従来のロググループへの出力が並行して続くわけではない。
そのロググループを参照している CloudWatch のアラームやダッシュボード、Contributor Insights のルールは、配信を作った時点で動かなくなる。ブログは、配信を作る前にこれらの参照先を新しいロググループへ移すよう求めている。配信を削除すれば、実行ログは管理ロググループへの出力に戻る。
いまの実行ログで調査に困っていないなら、急いで切り替える材料は告知にはない。1KBの切り詰めで原因を追えなかった経験があるなら、設定はコンソール、AWS CLI、CloudFormation のいずれかでできる。インフラをコードで管理しているチームは CloudFormation で揃えるのが自然だろう。
進め方の一案としては、アラート用の CloudWatch Logs ロググループを1つ自前で用意して上限が1MBになったことを確かめ、料金の見積もりが済んでから S3 への Parquet 配信を足す順番がある。最初から複数の配信先を並べるより、ログ量の変化を一段ずつ見られる。
