AWSは2026年9月9日の公式技術記事で、API Gateway REST APIの実行ログをCloudWatch Logs deliveryで配信する仕組みを紹介しました。従来の自動管理ロググループだけでなく、S3やAmazon Data Firehoseにも直接配信でき、イベント上限は1KBから最大1MBになります。

APIの失敗原因を調べる際、ログの途中切り詰めは重要な情報を失わせます。しかし容量拡大は、リクエスト本文に含まれる機密情報の保存量も増やします。今回の更新は、可観測性だけでなく情報管理と監視移行の課題です。

3行で分かる変更

• 実行ログの配信先を自分で管理するCloudWatch Logs、S3、Firehoseから選べます。
• 1イベントの上限は従来1KBから最大1MBへ拡大します。
• 配信を切り替えると従来ロググループへの流入が止まるため、既存アラームを先に移行します。

アクセスログと実行ログは別物

アクセスログはリクエストごとの要約で、ステータス、時間、送信元などを指定形式で記録します。実行ログは認証、検証、バックエンド呼び出し、マッピング、エラー処理といったAPI Gateway内部の経過を記録します。

今回変わるのはREST APIの実行ログ配信です。アクセスログのaccessLogSettings、X-Ray、スロットリング、キャッシュなどの設定は変わりません。HTTP APIへ同じ機能が適用されると読み替えないでください。

仕組み：Source、Destination、Delivery

DeliverySourceはAPIステージに結び付く配信元、DeliveryDestinationは保存先、Deliveryは両者をつなぐ接続です。1つのSourceに複数のDeliveryを作れます。

ログを生成するかは従来どおり`loggingLevel`の`INFO`／`ERROR`／`OFF`と`dataTraceEnabled`が決めます。配信先を作っても`OFF`ならログは出ません。 ## 実践：カスタムロググループへ配信 事前にREST APIをステージへデプロイし、実行ログを`INFO`または`ERROR`に設定します。アカウントレベルのCloudWatch Logs IAMロールも必要です。以下は検証環境用の架空IDです。 ```bash aws logs create-log-group --log-group-name /my-api/execution-logs aws logs put-retention-policy \ --log-group-name /my-api/execution-logs --retention-in-days 30 aws logs put-delivery-source \ --name my-apigw-execution-logs \ --resource-arn arn:aws:apigateway:us-east-1:111122223333:/restapis/abc123/stages/prod \ --log-type EXECUTION_LOGS aws logs put-delivery-destination \ --name my-execution-log-destination \ --delivery-destination-configuration \ destinationResourceArn=arn:aws:logs:us-east-1:111122223333:log-group:/my-api/execution-logs aws logs create-delivery \ --delivery-source-name my-apigw-execution-logs \ --delivery-destination-arn arn:aws:logs:us-east-1:111122223333:delivery-destination:my-execution-log-destination aws logs describe-deliveries ``` コマンド例は公式記事に沿っています。利用リージョン、CLI、IAM権限を確認し、実環境のARNへ置き換えてください。設定後はテストリクエストを送り、到着時刻、エラー内容、保持期間を確認します。 ## S3とFirehoseの使い分け S3は長期保管やAthena分析に向きます。配信先バケットはAPIと同一リージョンが必要です。Firehoseは外部SIEMやリアルタイム分析基盤への接続に向き、転送用LambdaやLogs subscription filterを別途維持する構成を減らせます。 同じSourceから複数先へ配信する場合、各保存先は同じイベントを受け取ります。**保存先ごとに自動で内容を削減してくれるわけではありません。**必要ならLogs側のsubscription filterなどで後段の選別を設計します。 ## 監視を壊さない移行手順 1. 従来の`API-Gateway-Execution-Logs_{rest-api-id}/{stage_name}`を参照するアラーム、ダッシュボード、Contributor Insightsを棚卸しする。 2. 新ロググループに保持期間、暗号化、アクセス権を設定する。 3. メトリクスフィルターと監視参照先を移行する。 4. テストステージでDeliveryを作り、正常・異常リクエストを確認する。 5. 本番切り替え後、監視が実際に発火するか確認する。 既存ロググループを配信先の1つに指定する方法もあります。ただし新方式は`resource_arn`、`event_timestamp`、`api_id`、`stage`、`payload`などの構造化フィールドを加えるため、既存パーサーやフィルターの互換性も試験してください。 ## 機密情報：1MB化は安全性の判断でもある `dataTraceEnabled=true`では本文を含む詳細データがログへ入り、個人情報、認証情報、業務機密が保存される可能性があります。容量拡大を理由に本番で常時有効化するのは危険です。 - 本文トレースは検証ステージや特定メソッドだけで有効にする - 保存先の暗号化、最小権限、保持期限を設定する - 個人情報や秘密情報がログへ出ないか、実際のサンプルをレビューする - マスキング設計は各ログ経路で検証する。マッピング変更だけで全ログが安全になると仮定しない - 複数配信先に同じ機密データが複製されることを情報管理台帳へ記載する ## 費用と欠損の限界 Vended logs料金が適用されますが、単純に従来より安いと断定できません。イベントが大きくなり、複数先へ配信すると、取り込み、保存、Firehose、Athenaの走査費用が増える可能性があります。実データ量から試算してください。 また、公式記事は配信が**ベストエフォート**であると明記しています。稀に未配信のイベントがあるため、法的に完全な監査証跡が必要な取引では実行ログだけを正本にせず、アプリ側の取引台帳や突合処理を用意します。 ## ロールバック ```bash aws logs delete-delivery --id YOUR_DELIVERY_ID ``` 公式記事によるとDeliveryを削除すると従来の自動管理ログへ戻ります。SourceとDestinationは独立オブジェクトとして残ります。複数Deliveryがある場合は構成全体を確認し、切り戻し後のログ到着と監視を必ず確認してください。 ## 今後注目すべき点 障害解析の詳細ログと長期保存を、同じAPIステージから分離して運用できるようになります。導入では容量上限よりも、パーサー互換性、機密情報の扱い、監視切り替え、欠損時の突合を優先して検証することが重要です。 ## 参照元 - [AWS Compute Blog：Customize Amazon API Gateway destinations for execution logs](https://aws.amazon.com/blogs/compute/customize-amazon-api-gateway-destinations-for-execution-logs/) - [AWS CLI：create-delivery](https://docs.aws.amazon.com/cli/latest/reference/logs/create-delivery.html) - [Amazon CloudWatch料金](https://aws.amazon.com/cloudwatch/pricing/) 最終確認日：2026年9月16日