Platform audit logs
Last updated: Sep 23, 2026
Rationale
Audit logging for Fluid Attacks' platform is performed by an in-house implementation called Tracks. Every relevant change performed by a user is recorded by the platform's backend as an audit event and sent, in batches, to an HTTPS API served by Lambda behind CloudFront (see Public hosting). The API queues each event in a FIFO SQS queue, and a Lambda consumer writes it to an Aurora PostgreSQL cluster through the RDS Data API.
This approach gives us a consistent and unified record of who did what, when, from where and through which mechanism, for every entity within the platform.
The main reasons why we chose it over other alternatives are the following:
- It is custom-made for our specific needs, so it can be adapted to any requirement we find in the future.
- The queue decouples the platform from the database, so traffic spikes are absorbed without slowing down user requests or dropping events.
- Message groups keep the events of each entity in order, and a dead-letter queue retains any event that repeatedly fails to be written.
- The database scales with demand and can be queried with SQL, giving us the ability to run analytics over a highly granular history.
- It allows us to generate highly detailed reports for our clients.
- It provides full traceability when investigating incidents is required.
- The same API receives engagement events from SendGrid, so email opens, clicks and unsubscribes are recorded next to the actions taken in the platform.
- Infrastructure handling is completely performed by us and written as code using Terraform.
This implementation replaced a previous in-house approach based on DynamoDB Streams and Lambda triggers, which kept the history of every item in a separate DynamoDB table. That history was migrated into Tracks.
Alternatives
Before building the current implementation, we reviewed a third-party audit logging solution.
WorkOS
- WorkOS provides SaaS solutions to requirements usually needed by enterprise applications.
- Due to its broad focus, it provides services for administrative portals, authentication, authorization, etc. Here we will be discussing its Audit Logs capability.
- Being a third-party provider, we would have to adapt ourselves to the features it supports and its limitations.
- It has a per-organization pricing model that scales properly for our use case.
- It has a >99% availability SLA.
- It is a SaaS that automatically handles user databases, scaling, security, redundancy, and disaster recovery, among others.
- Its Python library supports asynchronous environments.
- It does not have a Terraform provider.
- It supports log streaming to AWS S3 and other SIEM providers.
- It supports exporting logs to CSV format.
WorkOS was last reviewed on Jan 27, 2025.
Usage
We use Tracks, our in-house implementation, for audit logging flows at Fluid Attacks' platform.