# Create Remote Read Replicas > For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [cloud-data-platform-full.txt](https://docs.redpanda.com/cloud-data-platform-full.txt) --- title: Create Remote Read Replicas latest-operator-version: v26.2.1 latest-console-tag: v3.9.0 latest-connect-version: 4.104.0 latest-redpanda-tag: v26.2.1 docname: cluster-types/byoc/remote-read-replicas page-component-name: cloud-data-platform page-version: master page-component-version: master page-component-title: Cloud page-relative-src-path: cluster-types/byoc/remote-read-replicas.adoc page-edit-url: https://github.com/redpanda-data/cloud-docs/edit/main/modules/get-started/pages/cluster-types/byoc/remote-read-replicas.adoc description: Learn how to create a remote read replica topic with BYOC, which is a read-only topic that mirrors a topic on a different cluster. page-git-created-date: "2024-08-01" page-git-modified-date: "2026-07-06" --- A remote read replica topic is a read-only topic that mirrors a topic on a different cluster. You can create a separate remote cluster just for consumers of this topic and populate its topics from object storage. A read-only topic on a remote cluster can serve any consumer, without increasing the load on the source cluster. Because these read-only topics access data directly from object storage, there’s no impact to the performance of the cluster. Remote read replica topics do not store any data. When a cluster running a remote read replica is terminated, the topic data only exists on the origin cluster. Redpanda Cloud supports remote read replica topics in BYOC clusters on AWS or GCP. These clusters can be ephemeral; that is, created temporarily to handle specific or transient workloads, but they don’t have to be. The ability to make them ephemeral provides flexibility and cost efficiency: you can scale resources up or down as needed and pay only for what you use. > ❗ **IMPORTANT** > > Creating the remote read replica topic is only one of several required steps. To set up a remote read replica, you must complete all of the following: > > 1. **BYOVPC only**: Grant the reader cluster’s service account read access to the source cluster’s storage bucket. See [BYOVPC: Grant storage permissions](#byovpc-storage-permissions). > > 2. Link the reader cluster to the source cluster by setting `read_replica_cluster_ids`. See [Link the reader cluster to the source cluster](#link-clusters). Creating the topic alone does _not_ link the clusters. > > 3. Create the remote read replica topic. See [Create remote read replica topic](#create-remote-read-replica-topic). ## [](#prerequisites)Prerequisites To use remote read replicas, you need: - A BYOC reader cluster in Ready state. This separate reader cluster must exist in the same Redpanda organization as the source cluster. - AWS: The reader cluster must be in the same region and the same account as the source cluster. - GCP: The reader cluster can be in the same or a different region as the source cluster. The reader cluster must be in the same project as the source cluster. - Azure: Remote read replicas are not supported. ### [](#byovpc-storage-permissions)BYOVPC: Grant storage permissions > 📝 **NOTE** > > This prerequisite only applies to BYOVPC deployments. Skip this step if you’re enabling remote read replicas on standard BYOC clusters. #### GCP To grant additional permissions to the cloud storage manager of the reader cluster, run: ```bash gcloud storage buckets add-iam-policy-binding \ gs:// \ --member="serviceAccount:" \ --role="roles/storage.objectViewer" ``` #### AWS To grant additional permissions to the cloud storage manager of the reader cluster, set the `source_cluster_bucket_names` and `reader_cluster_id` variables in [cloud-examples](https://github.com/redpanda-data/cloud-examples/blob/main/customer-managed/aws/terraform/variables.tf). This should be done in the Terraform of the reader cluster. If the reader cluster’s service account does not have read access to the source cluster’s storage bucket, creating the remote read replica topic fails with an error like `UNKNOWN_SERVER_ERROR: Unable to perform requested topic operation`. ## [](#link-clusters)Link the reader cluster to the source cluster Linking is a required step. It does more than record the relationship between the clusters: - It orders upgrades safely across the linked clusters. - It prevents the source cluster from being deleted while it is linked to a reader cluster. The way linking interacts with storage permissions depends on your deployment type: - Standard BYOC: Linking the clusters grants the reader cluster read access to the source cluster’s storage bucket, so you cannot create a remote read replica topic until the clusters are linked. - BYOVPC: You grant the reader cluster read access to the bucket manually (see [BYOVPC: Grant storage permissions](#byovpc-storage-permissions)), so creating the topic succeeds even when the clusters are not linked. This makes the linking step easy to miss. > ⚠️ **WARNING** > > Creating a remote read replica topic does _not_ link the reader cluster to the source cluster. You must also set `read_replica_cluster_ids` as described in this section. Without this link, upgrades are not ordered safely across the clusters, and the source cluster is not protected from deletion, even if remote read replica topics exist. Add or remove reader clusters to a source cluster in Redpanda Cloud with the [Cloud Control Plane API](https://docs.redpanda.com/cloud-data-platform/manage/api/controlplane/). For information on accessing the Cloud API, see the [authentication guide](https://docs.redpanda.com/api/doc/cloud-controlplane/authentication). 1. To update your source cluster to add one or more reader cluster IDs, make a [`PATCH /v1/clusters/{cluster.id}`](https://docs.redpanda.com/api/doc/cloud-controlplane/operation/operation-clusterservice_updatecluster) request. The full list of clusters is expected on every call. If an ID is removed from the list, it is removed as a reader cluster. ```bash export SOURCE_CLUSTER_ID=....... export READER_CLUSTER_ID=....... curl -X PATCH $API_HOST/v1/clusters/$SOURCE_CLUSTER_ID \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $API_TOKEN" \ -d @- << EOF { "read_replica_cluster_ids": ["$READER_CLUSTER_ID"] } EOF ``` 2. Optional: To see the list of reader clusters on a given source cluster, make a [`GET /v1/clusters/{id}`](https://docs.redpanda.com/api/doc/cloud-controlplane/operation/operation-clusterservice_getcluster) request: ```bash export SOURCE_CLUSTER_ID=....... curl -X GET $API_HOST/v1/clusters/$SOURCE_CLUSTER_ID \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $API_TOKEN" ``` > 📝 **NOTE** > > A source cluster cannot be deleted while any reader cluster IDs are set in its `read_replica_cluster_ids` list. This deletion protection is based on the link, not on the existence of remote read replica topics. When you delete a reader cluster, that cluster’s ID is automatically removed from any existing source cluster `read_replica_cluster_ids` lists. ## [](#create-remote-read-replica-topic)Create remote read replica topic To create a remote read replica topic, run: ```bash rpk topic create -c redpanda.remote.readreplica= --tls-enabled ``` - For ``, use the same name as the original topic. - For ``, use the bucket specified in the `cloud_storage_bucket` properties for the origin cluster. For standard BYOC clusters, the source cluster bucket name follows the pattern: `redpanda-cloud-storage-${SOURCE_CLUSTER_ID}` ## [](#optional-tune-for-live-topics)Optional: Tune for live topics For remote read replicas reading from a live topic (that is, a topic that’s being actively written to by a source cluster), it may be advantageous to control how often segments are flushed to object storage. By default, this is set to 60 minutes. To tune `cloud_storage_segment_max_upload_interval_sec` on the source cluster, contact [Redpanda support](https://support.redpanda.com/hc/en-us/requests/new). (For cold topics, where segments are closed and older than 60 minutes, this configuration is unnecessary: the data is already uploaded to object storage.)