EBS is the default storage choice for ClickHouse on AWS EC2 because it gives the right balance of throughput, IOPS, latency, and price. The wrong volume type, or the wrong number of volumes per instance, will leave EC2 compute idle behind a saturated disk. The right setup matches volume throughput and IOPS to the instance's EBS bandwidth ceiling.
GP3: The Default
GP3 is the recommended volume type for ClickHouse data. It separates capacity from performance, so you size the disk for storage and provision IOPS and throughput independently.
Key numbers:
- Maximum throughput per volume: 2,000 MiB/s
- Maximum IOPS per volume: 80,000
- Included baseline: 3,000 IOPS and 125 MiB/s
- Add IOPS above the included 3,000 and throughput above 125 MiB/s for an additional per-unit cost
A practical starting point for a single-volume node:
- Provision the volume size your data plus headroom requires
- Provision 7000 IOPS (sufficient for most ClickHouse workloads)
- Provision throughput equal to your EC2 instance's EBS bandwidth ceiling
This lets you run a single data volume on instances with up to roughly 10 Gbps EBS bandwidth while still hitting peak performance. GP3 is approximately 20% cheaper per GiB than GP2 and is more flexible because you do not buy IOPS and throughput as a side effect of capacity.
GP2: When You Inherit It
GP2 ties IOPS to volume size (3 IOPS per GiB, with a maximum of 16,000 IOPS reached at 5,334 GiB) and caps throughput at 250 MiB/s once volumes are 334 GiB or larger. Smaller volumes can burst to 3,000 IOPS and throughput scales between 128 and 250 MiB/s with volume size.
The hard 250 MiB/s ceiling per volume is the operational issue. To get more than 250 MiB/s on GP2, you have to attach multiple volumes of at least 334 GiB and stripe them. The split commonly used in older ClickHouse deployments on GP2 is 4 to 5 volumes per node, sized so each is at least 334 GiB.
If you are designing from scratch, use GP3 instead.
ST1: Cold Storage Only
ST1 is throughput-optimized HDD, with up to 500 MiB/s per volume. Random access is slow, but for sequential cold scans on archive partitions it works. Use it behind ClickHouse storage policies as a cold tier, not as a primary data disk.
IO1, IO2, and IO2 Block Express: Rarely Worth It
Provisioned IOPS volumes are designed for IOPS-bound transactional workloads. ClickHouse is throughput-bound on reads of compressed parts. IO1 caps at 1,000 MiB/s and requires 64,000 IOPS to reach it (up to 32,000 IOPS yields a maximum of 500 MiB/s). IO2 Block Express scales to 4,000 MiB/s and 256,000 IOPS, but that performance comes at a substantial price.
For ClickHouse specifically, IO1 and IO2 do not give a meaningful benefit over GP3 at a much higher cost. Skip them unless you have a workload that genuinely demands sub-millisecond IO latency at sustained high IOPS.
Instance EBS Throughput Is the Real Ceiling
EC2 instances each have an EBS bandwidth limit that applies regardless of how many volumes are attached. You cannot exceed it by adding more disks. Check the instance's listed EBS-optimized bandwidth and size your volumes' provisioned throughput to match it, not exceed it.
A common configuration pattern:
- 1 to 3 GP3 volumes per node, or
- 4 to 5 GP2 volumes per node
More than that adds management overhead without performance benefit because the instance's EBS bandwidth is the bottleneck.
Multiple Volumes with ClickHouse Storage Policies
ClickHouse supports multiple disks through storage_configuration. The simplest pattern uses JBOD across several local volumes mounted into the data directory:
<storage_configuration>
<disks>
<disk1>
<path>/var/lib/clickhouse/disk1/</path>
</disk1>
<disk2>
<path>/var/lib/clickhouse/disk2/</path>
</disk2>
</disks>
<policies>
<jbod>
<volumes>
<main>
<disk>disk1</disk>
<disk>disk2</disk>
</main>
</volumes>
</jbod>
</policies>
</storage_configuration>
ClickHouse spreads parts across the volumes. JBOD scales total throughput and capacity without striping at the OS layer.
S3 as Cold Storage
ClickHouse can use S3 as a remote disk or for tiered storage with MergeTree and S3 storage policies. S3 belongs in two roles on EC2:
- Cold tier behind hot EBS, moving older partitions to S3 as they age out of common query ranges.
- Backup storage target for
clickhouse-backuporBACKUP TO S3.
S3 throughput inside a region can fill EC2 network bandwidth (up to 100 Gbps on instances that support it) when accessed through a gateway endpoint. First-byte latency is 100 to 200 milliseconds within a region, so S3 is not viable for low-latency interactive queries on hot data.
A storage policy with EBS hot and S3 cold:
<storage_configuration>
<disks>
<ebs>
<path>/var/lib/clickhouse/disks/ebs/</path>
</ebs>
<s3>
<type>s3</type>
<endpoint>https://your-bucket.s3.us-east-1.amazonaws.com/clickhouse/</endpoint>
<use_environment_credentials>true</use_environment_credentials>
</s3>
</disks>
<policies>
<tiered>
<volumes>
<hot><disk>ebs</disk></hot>
<cold><disk>s3</disk></cold>
</volumes>
<move_factor>0.1</move_factor>
</tiered>
</policies>
</storage_configuration>
EFS and FSx Lustre
EFS (NFS v4.1) works for cold storage on EC2 with the same limits as NFS in general: throughput depends on network bandwidth and file operations per second are slow because of locking. ClickHouse does not support multiple replicas reading from the same EFS data, so EFS does not substitute for ClickHouse replication.
FSx Lustre supports the high throughput patterns ClickHouse benefits from, but historically saw data corruption tied to O_DIRECT and async I/O on older ClickHouse versions. Test against current releases before committing.
Common Pitfalls
- Provisioning a 10,000 IOPS volume on an instance with a 4750 Mbps EBS bandwidth limit. The disk is wasted.
- Attaching 8 GP2 volumes when 2 GP3 volumes would deliver the same total throughput more cheaply.
- Putting ClickHouse data on EFS expecting it to act as shared storage between replicas. It does not.
- Using IO2 for ClickHouse and paying for IOPS the workload does not need.
- Forgetting that GP3 IOPS and throughput above the included baseline cost extra. Budget accordingly.
Frequently Asked Questions
Q: Should I use GP3 or GP2 for new ClickHouse deployments? A: GP3. Cheaper per GB, independent IOPS and throughput provisioning, and a higher throughput ceiling per volume.
Q: Do io1 or io2 volumes help ClickHouse performance? A: For most ClickHouse workloads, no. ClickHouse reads are throughput-bound. IO1 needs 64,000 IOPS for its 1,000 MiB/s ceiling, and io2 Block Express scales further but costs significantly more than GP3 for the same throughput.
Q: How many EBS volumes per node? A: One to three GP3 volumes is typical. The EC2 instance's EBS bandwidth limit caps total throughput regardless of volume count.
Q: Can S3 replace EBS for ClickHouse? A: Not for hot data. S3 latency is too high for interactive queries. Use S3 as a cold tier behind EBS or as backup storage.
Q: Does EFS let multiple ClickHouse replicas share data? A: No. ClickHouse expects each replica to manage its own storage. Replication is at the table engine layer, not the filesystem.
