What to Use on AWS When You Want ClickHouse Query Speed

ClickHouse is what teams reach for when a dashboard or an API has to aggregate large volumes of fresh data and answer in well under a second, for many users at once. On AWS that raises an awkward question, because AWS does not run ClickHouse as one of its own services. There is no ClickHouse in the AWS product directory, and the AWS What's New feed mentions it only as an example workload for storage-heavy EC2 instances.

So the choice is between running ClickHouse on AWS in one of three ways, and using an AWS service that covers part of the same ground. This guide compares them by workload. Where a vendor makes a performance claim, it is labelled as that vendor's claim.

What the Workload Actually Needs

"ClickHouse speed" usually means some mix of these four things, and each option below covers a different part of it:

• aggregations over large tables that return interactively
• data that can be queried seconds after it arrives
• many concurrent queries, often from an application rather than from analysts
• query shapes known in advance, such as dashboards and API endpoints, rather than open exploration

Write down which of them you really need before comparing products. A team that needs fresh data for a handful of analysts has far more options than one serving a customer-facing API.

Option 1: ClickHouse Itself, on AWS

ClickHouse Cloud is operated by ClickHouse Inc. and sold through AWS Marketplace, so its usage appears on the AWS bill. ClickHouse's documentation lists 14 AWS regions as public, Frankfurt, Ireland and London among them, with more available as private regions on the Enterprise plan. AWS PrivateLink is available on the Scale and Enterprise plans.

Bring Your Own Cloud (BYOC) runs the data plane, meaning your clusters, data and backups, entirely in your own AWS account, while ClickHouse keeps the control plane in its own VPC. ClickHouse creates and operates the EKS cluster itself, and installing into an existing cluster is not supported. The setup spans three availability zones, it requires a committed contract, and it has been generally available on AWS since February 2025.

Self-hosting means open-source ClickHouse on EC2 or EKS, with ClickHouse Keeper coordinating replication in place of ZooKeeper. Two Kubernetes operators exist, both under the Apache 2.0 license. Altinity's has been developed since 2019, and ClickHouse Inc. has its own official operator, which was at version 0.0.8 in September 2026. For storage, ClickHouse recommends provisioned IOPS SSD volumes for maximum performance and general-purpose SSD for lower cost, with S3-backed disks for colder data.

Two cautions from ClickHouse's own documentation apply to self-hosting. Zero-copy replication on S3 is not production ready and should stay off. And SharedMergeTree, the engine that separates storage from compute in ClickHouse Cloud, is not part of the open-source build, so a self-hosted cluster does not behave like the Cloud service. Self-hosting gives the most control and the most work, since Keeper, replicas, backups and upgrades are all yours. ClickHouse's sizing guide recommends three replicas per shard, or two when the data sits on EBS.

Option 2: Amazon Redshift

Redshift is AWS's columnar, massively parallel data warehouse, with its storage on S3 behind a local SSD cache. Serverless capacity is measured in RPUs, with a default base of 128 that can be set anywhere from 4 to 512, and compute is metered per second with a 60-second minimum.

Three features bring it closer to ClickHouse territory than its reputation suggests.

• Streaming ingestion loads data from Kinesis Data Streams or Amazon MSK straight into a streaming materialized view, which AWS describes as near real-time analytics. Refresh is manual by default.
• Zero-ETL integrations replicate Aurora, RDS for MySQL and PostgreSQL, DynamoDB and a list of SaaS sources into Redshift without a pipeline to maintain.
• Faster first runs. In March 2026 AWS changed how Redshift compiles new queries and put the gain for dashboard and ETL workloads at up to 7x. In May 2026 it added Graviton-based RG instances that it says are up to 2.4x faster than RA3. Both figures are AWS's own.

ClickHouse's migration guide argues that Redshift struggles with real-time work because of per-query compilation and a cap of 50 concurrent queries. Both points have aged. The 50 is the slot limit for manual workload management, while automatic WLM is the default on provisioned clusters and the only mode on Serverless, and the March 2026 change went after exactly the compilation cost of new queries.

Redshift fits when the workload is a warehouse, with joins across many sources, BI tools, data that already lives in AWS, and freshness measured in seconds to minutes rather than milliseconds.

Option 3: Amazon Athena on S3

Athena runs SQL over data in S3 with no cluster to manage. Engine version 3 is built with the open-source Trino and Presto projects, reads and writes Apache Iceberg tables, and works with S3 Tables, the table buckets with built-in Iceberg support that AWS introduced in December 2024. On demand it is billed by the data each query scans, with a 10 MB minimum per query, or by reserved capacity in DPUs. Query result reuse can answer a repeated query from a stored result for 60 minutes by default and for up to seven days.

AWS positions Athena for interactive, ad hoc analysis. It suits exploring a data lake and periodic reports. For an API that runs the same aggregation many times a minute it is the wrong tool, because every run scans and bills again unless result reuse applies.

Option 4: OpenSearch for Logs and Events

Amazon OpenSearch Service is the AWS answer when the data is logs, traces or events. It speaks SQL and PPL, can query logs in S3 where they sit, and since OpenSearch 3.1 offers a star-tree index that pre-aggregates data at ingestion time. AWS says it gives sub-second responses for frequent aggregations such as terms, histograms and ranges. The index is opt-in and is set when the index is created. For observability, that often covers what a team wanted ClickHouse for, but OpenSearch is a search engine first and not a general analytical warehouse.

Option 5: Time Series

If the data is metrics or sensor readings, look at Amazon Timestream for InfluxDB, which runs InfluxDB 2 and, since October 2025, InfluxDB 3. Do not start new work on Timestream for LiveAnalytics. AWS closed it to new customers on June 20, 2025, and lists it among its services in maintenance.

How to Choose

Your main need	Start with
Sub-second aggregations on fresh data for many concurrent users	ClickHouse (Cloud, BYOC or self-hosted)
A warehouse that joins Aurora, RDS or DynamoDB data for BI	Redshift with zero-ETL
SQL over files in S3, now and then	Athena with Iceberg or S3 Tables
Log and event analytics	OpenSearch
Metrics and sensor data	Timestream for InfluxDB

Two of these often end up side by side. ClickHouse's own migration guide pitches ClickHouse as a speed layer next to Redshift, which makes sense when governed reporting and a fast customer-facing API are both on the list.

Whichever way you go, decide early who runs it. Redshift, Athena and OpenSearch are AWS's to operate, ClickHouse Cloud and BYOC are ClickHouse's, and a self-hosted cluster is yours, including Keeper, replication and upgrades. Architecture Planning is where we help make that call before any data moves, and How You Overpay on AWS by Choosing the Wrong Service covers the same trap in other corners of AWS.