Manage Cloud Topics
|
This feature requires an enterprise license. To get a trial license key or extend your trial period, generate a new trial license key. To purchase a license, contact Redpanda Sales. If Redpanda has enterprise features enabled and it cannot find a valid license, restrictions apply. |
Starting in v26.1, Redpanda provides Cloud Topics to support multi-modal streaming workloads in the most cost-effective way possible: as a per-topic configuration running mixed latency workloads. While standard Redpanda topics that use local storage or Tiered Storage are ideal for latency-sensitive workloads (for example, for audit logs or analytics), Cloud Topics are optimized for latency-tolerant, high-throughput workloads where cross-AZ networking charges are a major consideration that can become the dominant cost driver at high throughput. These workloads can include observability streams, offline analytics, AI/ML model training data feeds, or development environments that have flexible latency requirements.
Instead of replicating every byte across expensive network links, Cloud Topics leverage durable, inexpensive cloud storage (S3, ADLS, GCS, MinIO) as the primary mechanism to both replicate data and serve it to consumers. This eliminates over 90% of the cost of replicating data over network links in multi-AZ clusters.
The end-to-end latency experienced when using Cloud Topics can range from 500 ms to as high as a few seconds with different object stores. Lower latencies may be achievable in certain environments, but Cloud Topics is optimized for throughput rather than low latency or tightly constrained tail latency. This latency profile is often acceptable for many streaming workloads, and can unlock new streaming use cases that previously were not cost effective.
With Cloud Topics, data from the client is not acknowledged until it is uploaded to object storage. This maintains durability in the face of infrastructure failures, but results in an increase in both produce latency and end-to-end latency, driven by both batching of produced data and the inherent latency of the underlying object store. You should generally expect end-to-end latencies of 1-2 seconds with public cloud stores.
After reading this page, you will be able to:
-
Describe the latency and cost trade-offs of Cloud Topics compared to standard Redpanda topics
-
Create a Cloud Topic using rpk on a cluster that has cloud storage enabled
-
Identify Cloud Topics limitations and configurations that reduce cross-AZ networking costs
Prerequisites
-
Install or Update rpk v26.1 or later.
-
Enable cloud storage on your Redpanda cluster.
If you plan to use Cloud Topics for all new topics in a Redpanda cluster, be sure to set the following cluster-level property:
default_redpanda_storage_mode=cloudThis ensures that newly-created Redpanda topics are Cloud Topics by default. For details, see Enable Tiered Storage for a cluster.
-
Ensure that you have an Enterprise license.
To check your license status, run:
rpk cluster license info
Limitations
-
In Redpanda versions earlier than v26.2, shadow links do not support Cloud Topics.
-
Once created, a Cloud Topic cannot be converted back to a standard Redpanda topic that uses local storage or Tiered Storage v1. Conversely, existing topics created as local or Tiered Storage v1 topics cannot be converted to Cloud Topics. Starting in Redpanda v26.2, Cloud Topics can be converted to and from Tiered Storage v2 topics.
Create Cloud Topics
Cloud Topics don’t require a separate cluster property to enable them. When cloud storage is enabled for your cluster, you can create Cloud Topics directly.
In Redpanda versions earlier than v26.2, you must also set the cloud_topics_enabled cluster property to true and restart the cluster. This property is deprecated in v26.2 and later. For details, see Deprecated features.
|
To create a Cloud Topic, set the topic property redpanda.storage.mode to cloud:
rpk topic create -c redpanda.storage.mode=cloud <new-cloud-topic-name>
TOPIC STATUS
audit.analytics.may2025 OK
You can make a topic a Cloud Topic only at topic creation time.
In addition to replication, cross-AZ ingress (producer) and egress (consumer) traffic can also contribute substantially to cloud networking costs. When running multi-AZ clusters in general, Redpanda strongly recommends using Follower Fetching, which allows consumers to avoid crossing network zones. When possible, you can use leader pinning, which positions a topic’s partition leader close to the producers, providing a similar benefit for ingress traffic. These features can add additional savings to the replication cost savings of Cloud Topics.
For client-side tuning guidance, see Configure producers for Cloud Topics.