Audit logs part 2: Cross-service comparison of web service logging features

What Remains After AWS, Cloudflare, Vercel, Supabase, and Headless CMS?

Hello, I'm Otsuka, CTO at Liberogic.

Last time, we clarified the differences between access logs, application logs, and audit logs.

This time, we'll take a closer look at what kinds of logs are available in the AWS, Cloudflare, Vercel, Supabase, and headless CMS services we typically work with.

That said, this is not a detailed price and feature comparison of each service.

Because each service has quite different characteristics in terms of "what is retained by default" and "how far back you can check," we'll organize those points at a high level.

Even with the same "log feature," the operations covered and retention periods differ.

Additionally, what appears on the admin screen and what is stored for audit purposes over the long term are separate matters.

AWS has comprehensive offerings, but configuration is required

AWS offers a rich set of logging services.

For example, execution logs from Lambda and API Gateway are collected in CloudWatch Logs. Operations performed in the AWS management console or via API can be recorded in CloudTrail.

In brief,

• CloudWatch Logs: View the behavior of applications and AWS services.
• CloudTrail: See who did what in your AWS environment.
• S3: Store logs long-term.

This is how the roles are divided.

Since search, monitoring, alerts, and long-term storage can all be built within AWS, this architecture is well-suited for systems with strict audit requirements.

However, "using AWS doesn't automatically log everything."

You need to configure log output for each service you use and decide on retention periods and storage destinations. The high degree of flexibility requires proper design planning.

Cloudflare separates short-term investigation from external storage.

With Cloudflare Workers, you can view output from console.log() and errors in Workers Logs.

While very convenient for verification during development and investigating recent issues, it is better not to rely solely on the standard logging screen when you need to maintain long-term audit trails.

For logs that require long-term retention, consider a configuration that sends them to R2 or external log management services using Logpush.

Additionally, when delivering static websites using Cloudflare Pages or Workers, not all access appears in the Worker execution logs.

The site displays normally, so it's easy to assume access logs exist — but static file delivery and Worker execution are separate processes.

Cloudflare makes it relatively easy to build compact configurations, but you need to understand which processes go through where to design logging effectively.

Vercel makes it easy to check Next.js logs

With Vercel, you can view logs output by Next.js Functions and Server Actions directly from the dashboard.

Since deployment and execution logs are close together, it provides a clear view for developers and makes everyday error investigation straightforward.

However, the retention period for logs and the scope of external forwarding vary depending on your plan.

If you need to retain logs long-term, additional mechanisms are required, such as using Drains to send them to an external storage location.

Regardless of Vercel, displaying logs in the dashboard and archiving them long-term for audit purposes are two separate matters.

You need to verify these two aspects separately.

Supabase generates logs beyond just the database.

Supabase is a PostgreSQL-centered service, but in practice it comprises multiple features beyond the database alone: authentication, API, storage, and Edge Functions.

Each log can be checked from the dashboard, making it easy to track the overall behavior of your application.

Additionally, there are authentication-related logs and audit logs to verify operations performed in the Supabase dashboard.

However, here too it's important to note that Supabase administrative operations and operations within your own application are separate.

For example, Supabase can record 'who changed the project settings,' but recording 'who changed customer information in your company's dashboard' requires implementation on the application side.

Check operation history in headless CMS.

Headless CMS services like microCMS, Kuroco, and NILTO provide content update history and management dashboard operation logs.

Records of who updated an article, when it was published, and what settings or permissions were changed are critical audit logs for website operations.

However, the operations recorded, the periods you can view, and the available plans vary depending on the service.

Even if you can view content update history, not all administrative operations are necessarily preserved as audit logs.

Additionally, a CMS typically contains only operational records within the CMS itself. Access to published websites and errors occurring on the frontend side must be checked in the hosting environment.

For headless CMS projects, it's clearer to view the CMS, frontend, hosting, and API as a single integrated system.

When adding Datadog or Sentry

If logs are scattered across multiple services, you'll need to open each management dashboard to investigate whenever an issue occurs.

Aggregating logs into a log management service like Datadog allows you to search logs across multiple environments at once and receive alerts when anomalies are detected.

Sentry is also commonly used, but it excels at identifying where errors occur and their scope of impact.

Both are useful, but implementing them doesn't automatically create a complete audit log.

The application side must determine what to output, and storing all logs long-term increases costs in proportion to data volume.

It's practical to separate logs you search regularly from logs you keep for reference in case something goes wrong.

You can't decide based on which service is better.

You can't compare logs alone and declare that AWS or Cloudflare is the best.

What matters is what you need to record for that project.

• Investigate service errors
• Track administrator actions
• Monitor CMS update history
• Audit authentication and permission changes
• Retain logs long-term for compliance

Once you know what you need, you can see which parts each service's standard features can handle and which parts require additional mechanisms.

Rather than setting up a large logging infrastructure from the start, we design the configuration based on each project's requirements and budget.

Next time, we'll look at how applications emit logs and where they're stored when combining these services. We'll cover more practical, real-world implementation details.

Well then.