Aurora
Last updated: Oct 30, 2026
Rationale
Fluid Attacks uses Amazon Aurora for relational databases in the cloud. Fluid Attacks runs its PostgreSQL-compatible edition in Serverless v2 mode for the workloads that must use SQL. DynamoDB continues to be the database for the business data of the platform.
These are the primary reasons why Fluid Attacks selected it and not other alternatives:
- It is a fully managed service. AWS does the patching, replication, failover, and storage increases. Thus, there are no database servers to operate.
- It complies with many certifications from ISO and CSA. Many of these certifications make sure that the entity uses best practices for secure cloud-based environments and information security.
- It supports Serverless v2 scaling. Thus, the capacity of each cluster increases and decreases between a minimum and a maximum with the load. The cluster can also pause to zero capacity when it is idle. Clusters that get traffic only from scheduled jobs do not use compute between the jobs.
- It has the RDS Data API. With this HTTPS interface, Lambda functions can run SQL statements without open database connections.
- It supports IAM database authentication. Thus, Fluid Attacks can give each workload access to one database user from its IAM role, with short-lived tokens and not with stored passwords.
- It integrates with AWS Secrets Manager to make and rotate the master password. Thus, no person touches this password.
- It supports encryption at rest with KMS. You can configure it to reject the connections that do not use TLS.
- It gives continuous backups with point-in-time recovery, a final snapshot when a user deletes a cluster, and deletion protection. Thus, the risk of an accidental data loss decreases.
- It exports PostgreSQL logs to CloudWatch, and it supports Performance Insights and enhanced monitoring. Thus, Fluid Attacks can find the slow queries and examine the resource use.
- It can export cluster data to S3 in Parquet format. Fluid Attacks uses this function to copy tables into Snowflake without more load on the database.
- You can write the resources as code with Terraform. The same in-house Terraform module makes all the clusters of Fluid Attacks. Thus, each cluster has the same security and operational baseline.
Alternatives
At this time, Fluid Attacks does not examine alternatives. Aurora is the managed relational database in AWS, where the other infrastructure of Fluid Attacks is. Also, the workloads that do not use SQL already run on DynamoDB and Snowflake.
Usage
Fluid Attacks uses Amazon Aurora PostgreSQL Serverless v2 for three clusters:
- To keep the advisory database that Aggregates builds. Aggregates is the Software Composition Analysis database builder of Fluid Attacks. A Batch job synchronizes the advisories, reachability templates, and package versions into the cluster. The public vulnerability database website queries it in real time.
- To keep the audit and usage events that Tracks collects. Tracks is the audit logging service of Platform audit logs. The events come through an SQS queue, and a Lambda consumer writes them with the RDS Data API.
- To keep the Git commit history that the code ETL of Observes ingests. This history is the system of record for the authors that the platform bills. The platform reads it through IAM database authentication, and a daily export to S3 sends the data to the billing tables in Snowflake.
Fluid Attacks does not use Amazon Aurora for these tasks:
- To keep the business data of the platform. This data is in DynamoDB.
- Analytics and reporting. These tasks run on Snowflake.