S3
Last updated: Nov 4, 2026
Rationale
AWS S3 (Cloud Object Storage) is the service that Fluid Attacks uses to keep files in the cloud.
These are the primary reasons why Fluid Attacks selected it and not other alternatives:
- It is SaaS oriented. To start to keep data, Fluid Attacks must make only a bucket. Fluid Attacks does not have to think about storage space, infrastructure scalability, data availability, data persistence, and many other infrastructure items.
- It complies with some 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.
- Fluid Attacks can write the resources as code with Terraform.
- Amazon CloudFront can be in front of it with Origin Access Control, which cryptographically restricts object access to one distribution. Together with Cloudflare at the edge, this is the pattern of Fluid Attacks to serve static sites publicly. Read Public hosting.
- It supports presigned URLs. With these URLs, Fluid Attacks can make signed download links that anyone with the URL can use until they expire. The expiration is configurable. This feature decreases the risk of data leaks very much.
- It supports versioning. Fluid Attacks turns it on for some buckets and keeps the old versions for a limited time.
- It supports storage lifecycle. Thus, Fluid Attacks can declare policies that expire files and move them to different storage classes.
- Fluid Attacks can get access to it programmatically with the AWS CLI and with language-specific libraries, for example, Python's Boto3. Thus, Fluid Attacks can connect its applications to it.
- Terraform can use it as a backend to keep its state.
- It supports AES256 server-side encryption with bucket-level defaults.
- It supports bucket policies. Fluid Attacks uses them to accept only TLS access and to restrict object reads to the CloudFront distributions in front of the buckets. Thus, public users cannot get the objects directly from S3 and go around the CDN.
- It supports Storage Lens, an analytics module that shows information and trends and helps to optimize the usage.
Alternatives
These are the alternatives that Fluid Attacks examined before it selected AWS S3. The list goes from the most interesting alternative to the least interesting one for the requirements of Fluid Attacks.
Google Cloud Storage
Google Cloud Storage is the object storage service on Google Cloud.
- It was not available when Fluid Attacks moved to the cloud.
- Fluid Attacks would have to support one more cloud provider, and its knowledge and tools would be in more platforms.
- It does not give first-class integration with the AWS-native primitives that Fluid Attacks uses for public hosting (CloudFront OAC, IAM roles, Lambda event sources).
Fluid Attacks last reviewed Google Cloud Storage on Apr 23, 2026.
Azure Blob Storage
Azure Blob Storage is the object storage service on Microsoft Azure.
- It was not available when Fluid Attacks moved to the cloud.
- Fluid Attacks would have to support one more cloud provider, and its knowledge and tools would be in more platforms.
- It does not integrate with the AWS ecosystem, where the other infrastructure of Fluid Attacks is.
Fluid Attacks last reviewed Azure Blob Storage on Apr 23, 2026.
Usage
Fluid Attacks uses AWS S3 for these tasks:
- To serve static assets for public sites (read Public hosting)
- To make signed download URLs in the platform
- To keep platform resources, evidence, reports, and analytics
- To keep Sorts training data
- To keep Skims data
- To keep the GitLab CI cache
- To keep the Terraform state
Fluid Attacks does not use AWS S3 to keep multimedia for its sites, for example, images and videos. For these files, Fluid Attacks uses Cloudinary.