Docs Self-Managed Manage Kubernetes Cloud Topics Cloud Topics on Kubernetes Page options Copy as Markdown Copied! View as plain text Ask AI about this topic Add MCP server to VS Code 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. After reading this page, you will be able to: Configure object storage for Cloud Topics on Kubernetes Enable and create Cloud Topics using the Redpanda Operator or Helm Verify topic storage mode configuration How Cloud Topics work With standard Redpanda topics, data is replicated across brokers using Raft consensus and stored locally on each replica. Cloud Topics change this model: data is acknowledged only after it is uploaded to object storage, making object storage the source of truth for both replication and consumption. 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. Storage modes Redpanda supports multiple storage modes that you can set at the cluster or topic level using the redpanda.storage.mode property: Mode Behavior unset Follows legacy behavior. Topics inherit cluster-level remote read/write settings. local Data is stored only on local disk. No remote storage is used. tiered Data is written locally and offloaded to object storage asynchronously using Tiered Storage. cloud Data is managed primarily in object storage. Local storage acts as a cache. Ideal use cases Cloud Topics are best suited for latency-tolerant workloads, including: Observability and logging streams Offline analytics pipelines AI/ML training data ingestion Development and staging environments with flexible latency requirements Limitations Shadow links do not currently support Cloud Topics. Once created, a Cloud Topic cannot be converted back to a standard Redpanda topic that uses local or Tiered Storage. Conversely, existing topics created as local or Tiered Storage topics cannot be converted to Cloud Topics. Higher produce latency compared to standard topics (expect 1-2 seconds with public cloud stores). Prerequisites You must have the following: kubectl: Ensure you have the kubectl command-line tool installed and configured to communicate with your cluster. Redpanda: A Redpanda Operator and a Redpanda resource deployed in your Kubernetes cluster running Redpanda v26.1 or later. Object storage: A configured object storage backend (Amazon S3, Google Cloud Storage, Azure Blob Storage, or an S3-compatible store such as MinIO). Enterprise license: A valid Redpanda Enterprise license applied to the cluster. 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. To check if you already have a license key applied to your cluster: rpk cluster license info Configure object storage Cloud Topics use the same object storage configuration as Tiered Storage. If you have already configured object storage for Tiered Storage, you can skip this step and proceed to Enable Cloud Topics. For detailed instructions including IAM role configuration, access key management, and encryption options, see Configure object storage in the Tiered Storage documentation. The following examples show the minimum required configuration for each cloud provider. Amazon S3 Helm + Operator Helm redpanda-cluster.yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Redpanda metadata: name: redpanda spec: clusterSpec: storage: tiered: credentialsSecretRef: accessKey: name: storage-secrets key: access-key secretKey: name: storage-secrets key: secret-key config: cloud_storage_enabled: true cloud_storage_credentials_source: config_file (1) cloud_storage_region: <region> cloud_storage_bucket: <bucket-name> 1 Use aws_instance_metadata instead if you are using an IAM role attached to your nodes. cloud-storage.yaml storage: tiered: credentialsSecretRef: accessKey: name: storage-secrets key: access-key secretKey: name: storage-secrets key: secret-key config: cloud_storage_enabled: true cloud_storage_credentials_source: config_file (1) cloud_storage_region: <region> cloud_storage_bucket: <bucket-name> 1 Use aws_instance_metadata instead if you are using an IAM role attached to your nodes. For details on IAM roles, access keys, and AWS KMS encryption, see Amazon S3 in the Tiered Storage documentation. Google Cloud Storage (GCS) Helm + Operator Helm redpanda-cluster.yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Redpanda metadata: name: redpanda spec: clusterSpec: storage: tiered: credentialsSecretRef: accessKey: name: storage-secrets key: access-key secretKey: name: storage-secrets key: secret-key config: cloud_storage_enabled: true cloud_storage_credentials_source: config_file (1) cloud_storage_api_endpoint: storage.googleapis.com cloud_storage_region: <region> cloud_storage_bucket: <bucket-name> 1 Use gcp_instance_metadata instead if you are using a GCP service account attached to your nodes. cloud-storage.yaml storage: tiered: credentialsSecretRef: accessKey: name: storage-secrets key: access-key secretKey: name: storage-secrets key: secret-key config: cloud_storage_enabled: true cloud_storage_credentials_source: config_file (1) cloud_storage_api_endpoint: storage.googleapis.com cloud_storage_region: <region> cloud_storage_bucket: <bucket-name> 1 Use gcp_instance_metadata instead if you are using a GCP service account attached to your nodes. For details on IAM roles, HMAC access keys, and customer-managed encryption keys, see Google Cloud Storage in the Tiered Storage documentation. Azure Blob Storage Helm + Operator Helm redpanda-cluster.yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Redpanda metadata: name: redpanda spec: clusterSpec: storage: tiered: credentialsSecretRef: accessKey: name: storage-secrets key: shared-key config: cloud_storage_enabled: true cloud_storage_credentials_source: config_file (1) cloud_storage_azure_storage_account: <account-name> cloud_storage_azure_container: <container-name> 1 Use azure_aks_oidc_federation instead if you are using an Azure managed identity. When using managed identities, omit credentialsSecretRef and configure workload identity annotations on the service account. cloud-storage.yaml storage: tiered: credentialsSecretRef: accessKey: name: storage-secrets key: shared-key config: cloud_storage_enabled: true cloud_storage_credentials_source: config_file (1) cloud_storage_azure_storage_account: <account-name> cloud_storage_azure_container: <container-name> 1 Use azure_aks_oidc_federation instead if you are using an Azure managed identity. When using managed identities, omit credentialsSecretRef and configure workload identity annotations on the service account. For details on managed identities and account access keys, see Microsoft ABS/ADLS in the Tiered Storage documentation. Enable Cloud Topics To enable Cloud Topics, set the cloud_topics_enabled cluster property to true and set the default storage mode for all new topics to cloud. Helm + Operator Helm Add the following to your Redpanda custom resource to enable Cloud Topics and set the default storage mode: redpanda-cluster.yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Redpanda metadata: name: redpanda spec: clusterSpec: storage: tiered: mountType: none credentialsSecretRef: accessKey: name: cloud-storage-creds key: access-key secretKey: name: cloud-storage-creds key: secret-key config: cloud_storage_enabled: true cloud_storage_region: <region> cloud_storage_bucket: <bucket-name> config: cluster: cloud_topics_enabled: true default_redpanda_storage_mode: cloud (1) 1 Optional. Set to cloud to make all new topics Cloud Topics by default. Omit this to create Cloud Topics individually. Apply the configuration: kubectl apply -f redpanda-cluster.yaml -n <namespace> The Redpanda Operator reconciles the configuration. Wait for the cluster to be ready: kubectl rollout status statefulset redpanda -n <namespace> --watch Verify that Cloud Topics are enabled: kubectl exec -n <namespace> redpanda-0 -c redpanda -- \ rpk cluster config get cloud_topics_enabled Expected output: true Add the following to your Helm values file: cloud-topics-values.yaml storage: tiered: mountType: none credentialsSecretRef: accessKey: name: cloud-storage-creds key: access-key secretKey: name: cloud-storage-creds key: secret-key config: cloud_storage_enabled: true cloud_storage_region: <region> cloud_storage_bucket: <bucket-name> config: cluster: cloud_topics_enabled: true default_redpanda_storage_mode: cloud (1) 1 Optional. Set to cloud to make all new topics Cloud Topics by default. Omit this to create Cloud Topics individually. Deploy or upgrade the Helm chart: helm upgrade --install redpanda redpanda/redpanda \ -n <namespace> --create-namespace \ -f cloud-topics-values.yaml Wait for the cluster to be ready: kubectl rollout status statefulset redpanda -n <namespace> --watch Verify that Cloud Topics are enabled: kubectl exec -n <namespace> redpanda-0 -c redpanda -- \ rpk cluster config get cloud_topics_enabled Expected output: true Create a Cloud Topic You can create Cloud Topics either by setting the cluster default storage mode to cloud, or by configuring individual topics. Create Cloud Topics by default If you set default_redpanda_storage_mode to cloud in the cluster configuration, all new topics inherit the cloud storage mode automatically. Verify the cluster default: kubectl exec -n <namespace> redpanda-0 -c redpanda -- \ rpk cluster config get default_redpanda_storage_mode Expected output: cloud Any new topic created without an explicit storage mode inherits this default: cloud-topic.yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Topic metadata: name: my-cloud-topic namespace: <namespace> spec: partitions: 3 replicationFactor: 3 cluster: clusterRef: name: redpanda kubectl apply -f cloud-topic.yaml Create individual Cloud Topics If the cluster default storage mode is not set to cloud, you can create individual Cloud Topics by setting the redpanda.storage.mode property on the topic. cloud-topic.yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Topic metadata: name: my-cloud-topic namespace: <namespace> spec: partitions: 3 replicationFactor: 3 additionalConfig: redpanda.storage.mode: "cloud" cluster: clusterRef: name: redpanda kubectl apply -f cloud-topic.yaml Override the cluster default Topic-level storage mode settings override the cluster default. For example, if the cluster default is cloud, you can create a topic that uses Tiered Storage instead: tiered-topic.yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Topic metadata: name: my-tiered-topic namespace: <namespace> spec: partitions: 3 replicationFactor: 3 additionalConfig: redpanda.storage.mode: "tiered" cluster: clusterRef: name: redpanda Verify topic storage mode To verify the storage mode of a topic, inspect its configuration through the Topic resource status: kubectl get topic <topic-name> -n <namespace> -o jsonpath=\ '{range .status.topicConfiguration[*]}{.name}={.value} ({.source}){"\n"}{end}' \ | grep storage.mode Expected output for a Cloud Topic: storage.mode=cloud (DEFAULT_CONFIG) Or, if explicitly set on the topic: storage.mode=cloud (DYNAMIC_TOPIC_CONFIG) The source field indicates whether the value was inherited from the cluster default (DEFAULT_CONFIG) or explicitly set on the topic (DYNAMIC_TOPIC_CONFIG). Suggested reading Use Tiered Storage on Kubernetes Manage Topics with the Redpanda Operator Back to top × Simple online edits For simple changes, such as fixing a typo, you can edit the content directly on GitHub. Edit on GitHub Or, open an issue to let us know about something that you want us to change. Open an issue Contribution guide For extensive content updates, or if you prefer to work locally, read our contribution guide . Was this helpful? thumb_up thumb_down group Ask in the community mail Share your feedback group_add Make a contribution 🎉 Thanks for your feedback! Delete PersistentVolumes Tiered Storage