Cloud

Create a BYOC Cluster on AWS

To create a Redpanda cluster in your virtual private cloud (VPC), follow the instructions in the Redpanda Cloud UI. The UI contains the parameters necessary to successfully run rpk cloud byoc apply. See also: BYOC architecture.

With standard BYOC clusters, Redpanda manages security policies and resources for your VPC, including subnetworks, service accounts, IAM roles, firewall rules, and storage buckets. For the highest level of security, you can manage these resources yourself with a BYOVPC cluster on AWS. To compare the two variants, see Choose Between BYOC and BYOVPC.

Prerequisites

Before you deploy a BYOC cluster on AWS, check that the user creating the cluster has the following prerequisites:

  • A minimum version of Redpanda rpk v24.1. See Install or Update rpk.

  • The user authenticating to AWS has AWSAdministratorAccess access to create the IAM policies specified in AWS IAM policies.

  • The user has the AWS variables necessary to authenticate. Use either:

    • AWS_PROFILE or

    • AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY

    To verify access, you should be able to successfully run aws sts get-caller-identity for your region. For more information, see the AWS CLI reference.

Create a BYOC cluster

  1. Log in to Redpanda Cloud.

  2. On the Clusters page, click Create cluster, then click Create for BYOC.

  3. Enter a cluster name, then select the resource group, provider (AWS), region, tier, availability, and Redpanda version.

    • If you plan to create a private network in your own VPC, select the region where your VPC is located.

    • Three availability zones provide two backups in case one availability zone goes down.

    Optionally, click Advanced settings to specify up to five key-value custom tags. After the cluster is created, Redpanda applies the tags to the AWS resources associated with this cluster, except as described in Reserved tag keys. For more information about AWS tag restrictions, see the AWS documentation. After the cluster is created, you can specify more tags with the Cloud API.

  4. Click Next.

  5. On the Network page, select the connection type: either public or private. For BYOC clusters, private is best-practice.

    • Your network name is used to identify this network.

    • For a CIDR range, choose one that does not overlap with your existing VPCs or your Redpanda network.

    • Clusters with private networking include a setting for API Gateway network access. Public access exposes endpoints for Redpanda Console, the Data Plane API, and the MCP Server API, but they remain protected by your authentication and authorization controls. Private access restricts endpoint access to your VPC only.

      After the cluster is created, you can change the API Gateway access on the Dataplane settings page. If you change from public to private access, users without VPN access to the Redpanda VPC will lose access to these services.

      To route all cluster egress through your own AWS Transit Gateway and hub VPC instead of a per-VPC NAT Gateway, set the Transit Gateway ID field on this page. The field is only available on clusters with a private connection type, and is only visible if centralized egress is enabled for your organization. This option is in beta. See Configure Centralized Egress with AWS Transit Gateway.

  6. Click Next.

  7. On the Deploy page, follow the steps to log in to Redpanda Cloud and deploy the agent.

    As part of agent deployment:

    • Redpanda assigns the permission required to run the agent. For details about these permissions, see AWS IAM policies.

    • Redpanda allocates one Elastic IP (EIP) address in AWS for each BYOC cluster.

Redpanda Cloud does not support customer access or modifications to any of the internal data plane resources. This restriction allows Redpanda Data to manage all configuration changes internally to ensure a 99.99% service level agreement (SLA) for BYOC clusters.

Manage custom tags

Your organization might require custom tags for cost allocation, audit compliance, or governance policies. After cluster creation, you can manage tags with the Cloud Control Plane API. The Control Plane API allows up to 16 custom tags in AWS. Redpanda reserves some tag keys. See Reserved tag keys.

Make sure you have:

  • The cluster ID. You can find this in the Redpanda Cloud UI, in the page header of the cluster overview.

  • A valid bearer token for the Cloud Control Plane API. For details, see Authenticate to the API.

Then complete the following steps:

  1. To refresh agent permissions so the Redpanda agent can update tags, run:

    export CLUSTER_ID="<cluster-id>"

rpk cloud byoc aws apply --redpanda-id="$CLUSTER_ID"

    This step is required because tag management requires additional IAM permissions that may not have been granted during initial cluster creation:

    • ec2:DescribeTags

    • ec2:DescribeVolumes

    • ec2:DescribeNetworkInterfaces

    • ec2:CreateTags

    • ec2:DeleteTags

    • iam:TagPolicy

    • iam:UntagPolicy

    • iam:TagInstanceProfile

    • iam:UntagInstanceProfile

  2. To update tags, invoke the Cloud API.

    First, set your authentication token:

    export AUTH_TOKEN="<your-bearer-token>"

    The PATCH call sets the tags specified under "cloud_provider_tags". It replaces the existing tags with the specified tags. Include all desired tags in the request. To remove a single entry, omit it from the map you send.

    cluster_patch_body=$(cat <<'JSON'
{
  "cloud_provider_tags": {
    "Environment": "production",
    "CostCenter": "engineering"
  }
}
JSON
)

curl -X PATCH "https://api.redpanda.com/v1/clusters/$CLUSTER_ID" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AUTH_TOKEN" \
  -d "$cluster_patch_body"

    To remove all tags, send an empty cloud_provider_tags object:

    cluster_patch_body='{"cloud_provider_tags": {}}'

curl -X PATCH "https://api.redpanda.com/v1/clusters/$CLUSTER_ID" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AUTH_TOKEN" \
  -d "$cluster_patch_body"

Reserved tag keys

Redpanda rejects the following tag keys in the Redpanda Cloud UI and when you update tags with the Control Plane API:

  • redpanda-org

  • redpanda-id

  • network-id

  • redpanda-client

If you enter a reserved key in the UI, the UI shows the error This field is already in use by Redpanda. Redpanda matches keys exactly, including case. AWS also treats tag keys as case-sensitive.

Also avoid the following keys:

  • Keys that start with redpanda-. Redpanda uses this prefix for its own tags, such as redpanda-name, redpanda-managed, redpanda-cloud-storage, redpanda-private-link, and redpanda-agent-version. When you update tags after cluster creation, Redpanda does not apply custom tags with this prefix to EC2 instances, EBS volumes, or network interfaces. The Redpanda Terraform provider also drops them from state.

  • The Name key. Redpanda sets the Name tag on the resources it creates. AWS displays this tag as the resource name in the console.

  • Keys that start with aws:. AWS reserves this prefix, and the UI rejects it.

These rules apply when you create the cluster and when you update tags with the Control Plane API.

Next steps

Configure private networking