# Remote Read Replicas in Kubernetes

> For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [streaming-full.txt](https://docs.redpanda.com/streaming-full.txt)

---
title: Remote Read Replicas in Kubernetes
latest-redpanda-tag: v25.3.11
latest-console-tag: v3.7.3
latest-operator-version: v26.1.4
# EOL = End-of-Life (support lifecycle status)
page-is-nearing-eol: "false"
page-is-past-eol: "false"
page-eol-date: November 19, 2026
latest-connect-version: 4.93.0
docname: kubernetes/tiered-storage/k-remote-read-replicas
page-component-name: streaming
page-version: "25.3"
page-component-version: "25.3"
page-component-title: Streaming
page-relative-src-path: kubernetes/tiered-storage/k-remote-read-replicas.adoc
page-edit-url: https://github.com/redpanda-data/docs/edit/v/25.3/modules/manage/pages/kubernetes/tiered-storage/k-remote-read-replicas.adoc
description: Learn how to create a Remote Read Replica topic, which is a read-only topic that mirrors a topic on a different cluster.
page-git-created-date: "2024-08-15"
page-git-modified-date: "2025-07-31"
support-status: supported
---

<!-- Source: https://docs.redpanda.com/streaming/25.3/manage/kubernetes/tiered-storage/k-remote-read-replicas.md -->

> 📝 **NOTE**
>
> This feature requires an [enterprise license](https://docs.redpanda.com/streaming/25.3/get-started/licensing/). To get a trial license key or extend your trial period, [generate a new trial license key](https://redpanda.com/try-enterprise). To purchase a license, contact [Redpanda Sales](https://redpanda.com/upgrade).
>
> If Redpanda has enterprise features enabled and it cannot find a valid license, [restrictions](https://docs.redpanda.com/streaming/25.3/get-started/licensing/#self-managed) apply.

A Remote Read Replica topic is a read-only topic that mirrors a topic on a different cluster. Remote Read Replicas work with both [Tiered Storage](https://docs.redpanda.com/streaming/25.3/manage/kubernetes/tiered-storage/k-tiered-storage/) and [archival storage](https://docs.redpanda.com/streaming/25.3/manage/kubernetes/tiered-storage/k-tiered-storage/#data-archiving).

When a topic has object storage enabled, you can create a separate remote cluster just for consumers of this topic, and populate its topics from remote storage. A read-only topic on a remote cluster can serve any consumer, without increasing the load on the origin cluster. Use cases for Remote Read Replicas include data analytics, offline model training, and development clusters.

You can create Remote Read Replica topics in a Redpanda cluster that directly accesses data stored in object storage. Because these read-only topics access data directly from object storage instead of the topics' origin cluster, there’s no impact to the performance of the cluster. Topic data can be consumed within a region of your choice, regardless of the region where it was produced.

> ❗ **IMPORTANT**
>
> -   The Remote Read Replica cluster must run on the same version of Redpanda as the origin cluster, or just one feature release ahead of the origin cluster. For example, if the origin cluster is version 24.1, the Remote Read Replica cluster can be 24.2, but not 24.3. It cannot skip feature releases.
>
> -   When upgrading, upgrade the Remote Read Replica cluster before upgrading the origin cluster.

For default values and documentation for configuration options, see the [`values.yaml`](https://artifacthub.io/packages/helm/redpanda-data/redpanda?modal=values&path=storage.tiered.config) file.

## [](#prerequisites)Prerequisites

You need the following:

-   An origin cluster with [Tiered Storage](https://docs.redpanda.com/streaming/25.3/manage/kubernetes/tiered-storage/k-tiered-storage/#set-up-tiered-storage) set up. Multi-region buckets or containers are not supported.

-   A topic on the origin cluster, which you can use as a Remote Read Replica topic on the remote cluster.

-   A separate remote cluster.

    -   AWS: The remote cluster must be in the same region as the origin cluster’s storage bucket/container.

    -   GCP: The remote cluster can be in the same or a different region as the bucket/container.

    -   Azure: Remote read replicas are not supported.



This feature requires an [enterprise license](https://docs.redpanda.com/streaming/25.3/get-started/licensing/). To get a trial license key or extend your trial period, [generate a new trial license key](https://redpanda.com/try-enterprise). To purchase a license, contact [Redpanda Sales](https://redpanda.com/upgrade).

If Redpanda has enterprise features enabled and it cannot find a valid license, [restrictions](https://docs.redpanda.com/streaming/25.3/get-started/licensing/#self-managed) apply.

To check if you already have a license key applied to your cluster:

```bash
rpk cluster license info
```

## [](#configure-object-storage-for-the-remote-cluster)Configure object storage for the remote cluster

You must configure access to the same object storage as the origin cluster.

#### Amazon S3

You can configure access to Amazon S3 with either an IAM role attached to the instance or with access keys.

### Use IAM roles

To configure access to an S3 bucket with an IAM role:

1.  Configure an [IAM role](https://docs.redpanda.com/streaming/25.3/manage/security/iam-roles/#configuring-iam-roles) with read permissions for the S3 bucket.

2.  Override the following required cluster properties in the Helm chart:

    Replace the following placeholders:

    -   `<region>`: The region of your S3 bucket.



### Use access keys

To configure access to an S3 bucket with access keys instead of an IAM role:

1.  Grant a user the following permissions to read objects on the bucket to be used with the cluster (or on all buckets):

    -   `GetObject`

    -   `ListBucket`


2.  Create a Secret in which to store the access key and secret key.

    ```yaml
    apiVersion: v1
    kind: Secret
    metadata:
      name: storage-secrets
      namespace: <namespace>
    type: Opaque
    data:
      access-key: <base64-encoded-access-key>
      secret-key: <base64-encoded-secret-key>
    ```

    -   Replace `<base64-encoded-access-key>` with your base64-encoded access key.

    -   Replace `<base64-encoded-secret-key>` with your base64-encoded secret key.


3.  Override the following required cluster properties in the Helm chart:

    Replace `<region>` with the region of your S3 bucket.
##### --values

`cloud-storage.yaml`

```yaml
storage:
  tiered:
    config:
      cloud_storage_enabled: true
      cloud_storage_credentials_source: aws_instance_metadata
      cloud_storage_region: <region>
      cloud_storage_bucket: "none"
```

```bash
helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \
--values cloud-storage.yaml
```

##### --set

```bash
helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \
  --set storage.tiered.config.cloud_storage_enabled=true \
  --set storage.tiered.config.cloud_storage_credentials_source=aws_instance_metadata \
  --set storage.tiered.config.cloud_storage_region=<region> \
  --set storage.tiered.config.cloud_storage_bucket="none"
```

##### --values

`cloud-storage.yaml`

```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
      cloud_storage_region: <region>
      cloud_storage_bucket: "none"
```

```bash
helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \
--values cloud-storage.yaml
```

##### --set

```bash
helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \
  --set storage.tiered.config.cloud_storage_enabled=true \
  --set storage.tiered.credentialsSecretRef.accessKey.name=storage-secrets \
  --set storage.tiered.credentialsSecretRef.accessKey.key=access-key \
  --set storage.tiered.credentialsSecretRef.secretKey.name=storage-secrets \
  --set storage.tiered.credentialsSecretRef.secretKey.key=secret-key \
  --set storage.tiered.config.cloud_storage_credentials_source=config_file \
  --set storage.tiered.config.cloud_storage_region=<region> \
  --set storage.tiered.config.cloud_storage_bucket="none"
```

#### Google Cloud Storage

You can configure access to Google Cloud Storage with either an IAM role attached to the instance or with access keys.

### Use IAM roles

To configure access to Google Cloud Storage with an IAM role, override the following required cluster properties in the Helm chart:

Replace `<region>` with the region of your bucket.

### Use access keys

To configure access to Google Cloud Storage with access keys instead of an IAM role:

1.  Create a Secret in which to store the access key and secret key.

    ```yaml
    apiVersion: v1
    kind: Secret
    metadata:
      name: storage-secrets
      namespace: <namespace>
    type: Opaque
    data:
      access-key: <base64-encoded-access-key>
      secret-key: <base64-encoded-secret-key>
    ```

    -   Replace `<base64-encoded-access-key>` with your base64-encoded access key.

    -   Replace `<base64-encoded-secret-key>` with your base64-encoded secret key.


2.  Override the following required cluster properties in the Helm chart:

    Replace `<region>` with the region of your bucket.
##### --values

`cloud-storage.yaml`

```yaml
storage:
  tiered:
    config:
      cloud_storage_enabled: true
      cloud_storage_credentials_source: gcp_instance_metadata
      cloud_storage_region: <region>
      cloud_storage_bucket: "none"
```

```bash
helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \
--values cloud-storage.yaml
```

##### --set

```bash
helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \
  --set storage.tiered.config.cloud_storage_enabled=true \
  --set storage.tiered.config.cloud_storage_credentials_source=aws_instance_metadata \
  --set storage.tiered.config.cloud_storage_region=<region> \
  --set storage.tiered.config.cloud_storage_bucket="none"
```

##### --values

`cloud-storage.yaml`

```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
      cloud_storage_api_endpoint: storage.googleapis.com
      cloud_storage_region: <region>
      cloud_storage_bucket: "none"
```

```bash
helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \
--values cloud-storage.yaml
```

##### --set

```bash
helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \
  --set storage.tiered.config.cloud_storage_enabled=true \
  --set storage.tiered.credentialsSecretRef.accessKey.name=storage-secrets \
  --set storage.tiered.credentialsSecretRef.accessKey.key=access-key \
  --set storage.tiered.credentialsSecretRef.secretKey.name=storage-secrets \
  --set storage.tiered.credentialsSecretRef.secretKey.key=secret-key \
  --set storage.tiered.config.cloud_storage_credentials_source=config_file \
  --set storage.tiered.config.cloud_storage_api_endpoint=storage.googleapis.com \
  --set storage.tiered.config.cloud_storage_region=<region> \
  --set storage.tiered.config.cloud_storage_bucket="none"
```

#### Azure Blob Storage

To configure access to Azure Blob Storage(ABS):

1.  Create a Secret in which to store the access key.

    ```yaml
    apiVersion: v1
    kind: Secret
    metadata:
      name: storage-secrets
      namespace: <namespace>
    type: Opaque
    data:
      access-key: <base64-encoded-access-key>
    ```

    -   Replace `<base64-encoded-access-key>` with your base64-encoded access key.


2.  Override the following required cluster properties in the Helm chart:


Replace `<account-name>` with the name of your Azure account.
##### --values

`cloud-storage.yaml`

```yaml
storage:
  tiered:
    credentialsSecretRef:
      secretKey:
        configurationKey: cloud_storage_azure_shared_key
        name: storage-secrets
        key: access-key
    config:
      cloud_storage_enabled: true
      cloud_storage_azure_storage_account: <account-name>
      cloud_storage_azure_container: "none"
```

```bash
helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \
--values cloud-storage.yaml
```

##### --set

```bash
helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \
  --set storage.tiered.config.cloud_storage_enabled=true \
  --set storage.tiered.credentialsSecretRef.secretKey.configurationKey=cloud_storage_azure_shared_key \
  --set storage.tiered.credentialsSecretRef.secretKey.name=storage-secrets \
  --set storage.tiered.credentialsSecretRef.secretKey.key=access-key \
  --set storage.tiered.config.cloud_storage_azure_storage_account=<account-name> \
  --set storage.tiered.config.cloud_storage_azure_container="none"
```

## [](#create-a-remote-read-replica-topic)Create a Remote Read Replica topic

To create the Remote Read Replica topic, run:

```bash
rpk topic create <topic_name> -c redpanda.remote.readreplica=<bucket_name>
```

-   For `<topic_name>`, use the same name as the original topic.

-   For `<bucket_name>`, use the bucket/container specified in the `cloud_storage_bucket` or `cloud_storage_azure_container` properties for the origin cluster.


> 📝 **NOTE**
>
> -   The Remote Read Replica cluster must run on the same version of Redpanda as the origin cluster, or just one feature release ahead of the origin cluster. For example, if the origin cluster is version 23.1, the Remote Read Replica cluster can be 23.2, but not 23.4. It cannot skip feature releases.
>
> -   During upgrades, upgrade the Remote Read Replica cluster before upgrading the origin cluster.
>
> -   Do not use `redpanda.remote.read` or `redpanda.remote.write` with `redpanda.remote.readreplica`. Redpanda ignores the values for remote read and remote write properties on read replica topics.

## [](#reduce-lag-in-data-availability)Reduce lag in data availability

When object storage is enabled on a topic, Redpanda copies closed log segments to the configured object store. Log segments are closed when the value of the segment size has been reached. A topic’s object store thus lags behind the local copy by the [`log_segment_size`](https://docs.redpanda.com/streaming/25.3/reference/properties/cluster-properties/#log_segment_size) or, if set, by the topic’s `segment.bytes` value. To reduce this lag in the data availability for the Remote Read Replica:

-   You can lower the value of `segment.bytes`. This lets Redpanda archive smaller log segments more frequently, at the cost of increasing I/O and file count.

-   Redpanda Streaming deployments can set an idle timeout with `[storage.tiered.config.cloud_storage_segment_max_upload_interval_sec](https://docs.redpanda.com/streaming/25.3/reference/properties/object-storage-properties/#cloud_storage_segment_max_upload_interval_sec)` to force Redpanda to periodically archive the contents of open log segments to object storage. This is useful if a topic’s write rate is low and log segments are kept open for long periods of time. The appropriate interval may depend on your total partition count: a system with less partitions can handle a higher number of segments per partition.


## [](#suggested-reading)Suggested reading

[Remote Read Replicas: Read-only topics in Tiered Storage](https://redpanda.com/blog/remote-read-replicas-for-distributing-work)

## Suggested labs

-   [Redpanda Iceberg Docker Compose Example](https://docs.redpanda.com/labs/docker-compose/iceberg/)
-   [Iceberg Streaming on Kubernetes with Redpanda, MinIO, and Spark](https://docs.redpanda.com/labs/kubernetes/iceberg/)

[Search all labs](https://docs.redpanda.com/labs)