Audit Log Part 2: Cross-Comparison of Web Service Logging Features

AWS, Cloudflare, Vercel, Supabase, and headless CMS: What Logs Remain?

Hello, I'm Otsuka, CTO at Liberogic.

In the previous article, we clarified the differences between access logs, application logs, and audit logs.

This time, we'll take a closer look at the specific types of logs available in the services we commonly work with: AWS, Cloudflare, Vercel, Supabase, and headless CMS.

That said, this is not about making detailed comparisons of pricing and features across services.

Each service has distinct characteristics in terms of 'what is retained by default' and 'what can be reviewed later,' so we'll provide a general overview of those aspects.

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

Additionally, what is displayed in the management interface and what is retained long-term for audit purposes are separate matters.

AWS has everything you need, but configuration is required

AWS offers a comprehensive suite 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 for the long term

—that's the division of roles.

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

However, using AWS doesn't mean everything is automatically logged.

You need to configure log output for each service you use and decide on retention periods and storage destinations. Because of this flexibility, proper planning is essential.

Cloudflare separates short-term investigation from external storage

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

It's very convenient for verification during development and investigating recent issues, but when you need to maintain audit logs over a long period, it's best not to rely solely on the standard log screen.

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

Additionally, when serving static websites via Cloudflare Pages or Workers, not all access is recorded in the Worker execution logs.

The site displays normally, so you might assume access logs are automatically there, 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 pass through which infrastructure to design your logs effectively.

Vercel makes it easy to check Next.js logs

In Vercel, you can view logs from Next.js Functions and Server Actions directly from the management console.

Because deployments and execution logs are in a nearby location, it's easy for developers to understand and investigate everyday errors.

On the other hand, the period for which logs are available and the scope of external transfer depend on your plan.

If you need to retain logs long-term, you'll need additional infrastructure, such as using Drains to send them to an external storage location.

Whether or not it's Vercel, displaying logs in the admin dashboard and retaining them long-term for audit purposes are two separate matters.

These two points need to be verified separately.

Supabase contains logs beyond just the database.

While Supabase is a service centered on PostgreSQL, it actually comprises multiple functions including authentication, API, storage, and Edge Functions, not just the database.

Since each log can be viewed from the admin dashboard, it is easy to track the behavior of the entire application.

There are also authentication-related logs and audit logs to verify actions performed in the Supabase admin dashboard.

However, it is important to note here that Supabase management operations and operations within your own application are separate.

For example, while the service can record "who changed the Supabase project settings," it requires the application to record "who changed customer information in your own admin dashboard."

Check operation history in headless CMS.

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

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

However, the operations that are recorded, the period for which they can be verified, and the available plans vary by service.

Even if you can check the content update history, not all administrative operations are necessarily retained as audit logs.

Additionally, a CMS typically only stores operation records within the CMS itself. Access to published websites and errors that occur 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 one integrated system.

When adding Datadog or Sentry

When logs are scattered across multiple services, you'll need to open each admin dashboard to investigate every time an incident occurs.

By aggregating logs to a log management service like Datadog, you can search logs from multiple environments together and detect and notify on anomalies.

Sentry is also commonly used, but it specializes in identifying where errors occur and their impact scope.

Both are useful, but implementing them does not automatically complete your audit log setup.

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

In practice, it makes sense to separate logs you search regularly from those you keep archived for when something goes wrong.

You cannot decide based on which service is superior.

You cannot conclude that AWS is best or Cloudflare is best by comparing logs alone.

What matters is understanding what your project needs to record.

• I want to investigate service errors.
• I want to track administrator actions.
• I want to review CMS update history.
• I want to track authentication and permission changes.
• I want to retain logs long-term for audit purposes.

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

We don't set up a large logging infrastructure from the start either. Instead, we design the configuration to match the project requirements and budget.

Next time, we'll discuss how applications generate and store logs when these services are combined. We'll focus on more practical, real-world scenarios.

Well then.