EBS

Last updated: Nov 3, 2026

---

Rationale

AWS EBS (Elastic Block Store) is the service that Fluid Attacks uses for block-level storage. With it, Fluid Attacks has hard drives in the cloud. These are the primary reasons why Fluid Attacks selected it and not other alternatives:

• It integrates easily with AWS EC2. Thus, Fluid Attacks can connect external hard drives to instances.
• 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 gives many disk types, from SSDs with a capacity of 64 TiB and a throughput of 4,000 MiB/s to HHDs with a capacity of 16 TiB and a throughput of 500 MiB/s.
• It gives disks with different specializations. There are General Purpose and Provisioned IOPS SSDs, and Throughput Optimized and Cold HHDs. With all these disk types, Fluid Attacks can easily select the disk that agrees with the problem that it must solve.
• It supports point-in-time snapshots that back up all the data on a disk.
• Fluid Attacks can easily attach and detach disks from AWS EC2 machines. Thus, Fluid Attacks can easily change the machine configurations without data loss.
• Fluid Attacks can encrypt disks with AWS KMS keys. This encrypts the data that moves between the disk and the instance that uses it, the data at rest in the volume, the disk snapshots, and all the volumes that come from these snapshots.
• It supports data lifecycle policies. Thus, Fluid Attacks can make, keep, and delete disks with policies.
• It supports monitoring and metrics with AWS CloudWatch.

Alternatives

Google Compute Engine (GCE) is an alternative that was not available when Fluid Attacks moved to the cloud. GCP does not give an equivalent of EBS. All its disk service is inside GCE. It does not support disk encryption.

Usage

Fluid Attacks uses AWS EBS for these items:

• GitLab CI runner managers: Fluid Attacks uses a 15 GiB GP3 disk, because the manager has only basic software, for example, GitLab Runner and the docker-autoscaler executor. High disk throughput is not necessary.
• GitLab CI workers: Fluid Attacks uses 15 GiB GP3 disks only for the operating system of the workers. Also, the workers have high-throughput 50 GiB internal NVMe disks, which are very useful to make the CI jobs as fast as possible.
• Batch processing workers: Fluid Attacks uses 8 GiB GP2 disks only for the operating system. These workers also have 50 GiB internal NVMe disks.
• Kubernetes cluster workers: Fluid Attacks uses GP3 disks for the base operating system and the stored containers of applications: 80 GiB for the nodes of its platform and 20 GiB for the other nodes. High disk throughput is not necessary, because the ARM does not keep data on local disks.
• Okta RADIUS Agent: Fluid Attacks uses a 50 GiB GP2 disk. It is possibly too large, because it has only the base operating system and the RADIUS agent. High disk throughput is not necessary.
• ERP: Fluid Attacks uses two disks: a 50 GiB GP2 disk for the base operating system and a 200 GiB GP2 disk for the ERP data.