Platform audit logs
Last updated: Oct 28, 2026
Rationale
Fluid Attacks uses an in-house implementation, Tracks, for audit logging in the Fluid Attacks platform. The platform backend records each relevant change that a user makes as an audit event. The backend sends these events in batches to an HTTPS API. Lambda serves this API behind CloudFront (read Public hosting). The API puts each event in a FIFO SQS queue. Then, a Lambda consumer writes the event to an Aurora PostgreSQL cluster through the RDS Data API.
With this approach, Fluid Attacks has a consistent and unified record for each entity in the platform. The record shows who did what, when, from where, and with which mechanism.
These are the primary reasons why Fluid Attacks selected it and not other alternatives:
- Fluid Attacks made it for its own requirements. Thus, Fluid Attacks can change it for new requirements in the future.
- The queue isolates the platform from the database. Thus, the queue absorbs the traffic when it increases suddenly. User requests do not become slower, and all events go into the database.
- Message groups keep the events of each entity in sequence. A dead-letter queue keeps each event that the consumer cannot write after it tries three times.
- The database changes its capacity with the demand, and you can query it with SQL. Thus, Fluid Attacks can do analytics on a very detailed history.
- Fluid Attacks can make very detailed reports for its clients with it.
- It gives full traceability when Fluid Attacks must examine incidents.
- The same API receives engagement events from SendGrid. Thus, Tracks records email opens, clicks, and unsubscribes together with the actions in the platform.
- Fluid Attacks manages all the infrastructure and writes it as code with Terraform.
This implementation replaced an earlier in-house approach that used DynamoDB Streams and Lambda triggers. That approach kept the history of each item in a different DynamoDB table. Fluid Attacks moved that history into Tracks.
Alternatives
Before Fluid Attacks built the current implementation, it examined a third-party audit logging solution.
WorkOS
- WorkOS gives SaaS solutions for requirements that enterprise applications usually have.
- Because it has a wide scope, it gives services for administrative portals, authentication, authorization, and more. This section is about its Audit Logs capability.
- Because it is a third-party provider, Fluid Attacks would have to adapt to the features that it supports and to its limits.
- It has a per-organization pricing model that scales correctly for the requirements of Fluid Attacks.
- It has a >99% availability SLA.
- It is a SaaS that automatically manages user databases, scaling, security, redundancy, disaster recovery, and more.
- 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.
Fluid Attacks last reviewed WorkOS on Jan 27, 2025.
Usage
Fluid Attacks uses Tracks, its in-house implementation, for audit logging flows in the Fluid Attacks platform.