監査ログその２：Webサービスのログ機能を横断比較

AWS、Cloudflare、Vercel、Supabase、ヘッドレスCMSでは何が残る？

こんにちは、リベロジックでCTOをしている大塚です。

前回は、アクセスログやアプリケーションログ、監査ログの違いについて整理しました。

今回はもう少し具体的に、私たちが普段扱っているAWS、Cloudflare、Vercel、Supabase、ヘッドレスCMSでは、どのようなログが取れるのかを見ていきます。

といっても、各サービスの料金や機能を細かく比較する話ではありません。

サービスごとに「標準で何が残るのか」「あとからどこまで確認できるのか」という特徴がかなり違うので、そのあたりをざっくり整理します。

同じ「ログ機能」でも、対象となる操作や保存期間は異なります。

また、管理画面に表示されていることと、監査用として長期間保存されていることも別の話です。

AWSは一通りそろっているけれど、設定は必要

AWSは、ログに関するサービスがかなり充実しています。

例えば、LambdaやAPI Gatewayなどの実行状況はCloudWatch Logsに集められます。AWSの管理画面やAPIで行われた操作は、CloudTrailで記録できます。

ざっくり言えば、

• CloudWatch Logs：アプリケーションやAWSサービスの動作を見る
• CloudTrail：AWS環境に対して誰が何をしたかを見る
• S3：ログを長期間保管する

という役割分担です。

検索、監視、通知、長期保存までAWSの中で組み立てられるので、監査要件の強いシステムにも対応しやすい構成です。

ただし、「AWSを使っているから全部自動的に残る」というわけではありません。

利用するサービスごとにログ出力を設定し、保存期間や保存先も決める必要があります。自由度が高いぶん、きちんと設計することが前提になります。

Cloudflareは短期の調査と外部保存を分けて考える

Cloudflare Workersでは、console.log()で出力した内容やエラーをWorkers Logsで確認できます。

開発中の確認や直近の障害調査にはとても便利ですが、長期間の監査証跡を残す場合は、標準のログ画面だけで完結させないほうがよいでしょう。

長期保存が必要なログは、Logpushなどを使ってR2や外部のログ管理サービスへ送る構成を考えます。

また、Cloudflare PagesやWorkersで静的なWebサイトを配信している場合、すべてのアクセスがWorkerの実行ログに残るわけではありません。

サイトは普通に表示できているので、「当然アクセスログもあるだろう」と思ってしまうところですが、静的ファイルの配信とWorkerの実行は別のものです。

Cloudflareは比較的コンパクトな構成を作りやすい反面、どの処理がどこを通るのかを理解してログを設計する必要があります。

VercelはNext.jsのログを確認しやすい

Vercelでは、Next.jsのFunctionsやServer Actionsなどが出力したログを、管理画面から確認できます。

デプロイと実行ログが近いところにあるので、開発者にとっては分かりやすく、日常的なエラー調査もしやすい環境です。

一方で、ログを確認できる期間や、外部へ転送できる範囲はプランによって異なります。

長期間残したい場合は、Drainsを使って外部の保存先へ送るなど、別の仕組みが必要になります。

Vercelに限らず、管理画面にログが表示されていることと、監査用として長期保存されていることは別の話です。

この2つは分けて確認しておく必要があります。

Supabaseはデータベース以外のログも多い

SupabaseはPostgreSQLを中心としたサービスですが、実際にはデータベースだけでなく、認証、API、ストレージ、Edge Functionsなど複数の機能で構成されています。

それぞれのログを管理画面から確認できるため、アプリケーション全体の動きを追いやすいのが特徴です。

また、認証に関するログや、Supabaseの管理画面で行われた操作を確認するための監査ログもあります。

ただし、ここでも注意したいのは、Supabaseの管理操作と、自分たちが作ったアプリケーション内の操作は別ということです。

例えば「Supabaseのプロジェクト設定を誰が変更したか」はサービス側で記録できても、「自社の管理画面で誰が顧客情報を変更したか」は、アプリケーション側で記録する必要があります。

ヘッドレスCMSの操作履歴も確認する

microCMS、Kuroco、NILTOなどのヘッドレスCMSでは、コンテンツの更新履歴や管理画面の操作ログが用意されています。

誰が記事を更新したか、いつ公開したか、設定や権限を変更したか、といった記録は、Webサイト運用における監査ログとして重要です。

ただし、記録される操作や確認できる期間、利用できるプランはサービスによって異なります。

コンテンツの更新履歴は確認できても、すべての管理操作が監査ログとして残るとは限りません。

また、CMSが持っているのは基本的にCMS内部の操作記録です。公開されたWebサイトへのアクセスや、フロントエンド側で発生したエラーは、ホスティング環境側で確認する必要があります。

ヘッドレスCMS案件では、CMSだけでなく、フロントエンド、ホスティング、APIをひとつのシステムとして見たほうが分かりやすいですね。

DatadogやSentryを追加する場合

複数のサービスにログが分散すると、障害が起きるたびに各管理画面を開いて調査することになります。

Datadogなどのログ管理サービスへ集約すると、複数環境のログをまとめて検索したり、異常を検知して通知したりできます。

Sentryもよく利用されますが、こちらはエラーの発生箇所や影響範囲を調べることが得意なサービスです。

どちらも便利ですが、導入すれば自動的に監査ログが完成するわけではありません。

何を出力するかはアプリケーション側で決める必要がありますし、すべてのログを長期間保存すると、データ量に応じて費用も増えていきます。

普段検索するログと、何かあったときのために保管しておくログを分けるのが現実的です。

どのサービスが優れているか？では決められない

ログだけを比較して、AWSが一番、Cloudflareが一番と決めることはできません。

重要なのは、その案件で何を記録する必要があるのかです。

• サービスのエラーを調査したい
• 管理者の操作を残したい
• CMSの更新履歴を確認したい
• 認証や権限変更を追跡したい
• 監査のために長期間保存したい

必要なものが分かれば、各サービスの標準機能で対応できる部分と、追加の仕組みが必要な部分が見えてきます。

私たちも、最初から大きなログ基盤を用意するのではなく、案件の要件や予算に合わせて構成を考えています。

次回は、こうしたサービスを組み合わせたとき、アプリケーション側でどのようなログを出し、どこへ保存するのか。もう少し実務に近いところを紹介します。

ではでは。