BYOC delegation is the part of a bring-your-own-cloud decision that the deployment review never scopes. The review asks where the data plane runs, hears "your account," and files the question as answered. The question it skips is who receives authority over that account when you install the thing. In the offerings reviewed here, those two answers are not the same answer.
This post reads the BYOC documentation for Redpanda, Databricks and Aiven, and treats WarpStream as a vendor claim at the far end of the range. The set is narrow: four data and analytics platforms, and the pages I read are weighted toward AWS. Every empirical statement below is tied to a page I read. "Not stated" means the pages I read do not state it, not that the vendor lacks it.
The Question the Review Asks, and the One It Skips
In cloud architecture strategy, a BYOC review that stops at residency asks one question: where does the data plane run? The documentation answers it the same way each time. Redpanda states that you deploy the data plane in your own VPC and that customer data never leaves it. Databricks operates and manages clusters through a cross-account IAM role in the customer's AWS account. Aiven creates a VPC in the customer's account.
The residency answer looks like the authority answer. It is not.
The authority question is BYOC delegation: who receives permission over my environment when I install this. In Redpanda, Databricks and Aiven, the deployment process establishes that authority through IAM: a bootstrap step, cross-account role, or template the buyer applies. The residency review never reads it, because nothing in the residency question points there.
What "Your Account" Means in BYOC
Start with what the documentation establishes.
In standard Redpanda BYOC, you bootstrap a VM in your VPC with rpk cloud byoc apply. That VM launches the agent. Redpanda then assigns the IAM policies and creates dedicated roles per workload, which it describes as fine-grained and least privilege. The agent pulls cluster specifications from the control plane, and its IAM permissions let it call the cloud provider API to create and manage cluster resources, including VPC peering networks. The control plane handles provisioning, Kubernetes version upgrades and infrastructure maintenance.
In Aiven's AWS custom cloud, you generate a Terraform template in the Aiven console, apply it in your account, and hand the resulting Role ARN back to Aiven. Aiven assumes that role to run operations such as creating the VMs for service nodes, and the documentation describes the grant as permission to create resources and manage them onward. The VPC is one Aiven creates in your account, within a CIDR range you choose.
Then the constraint, stated precisely. Redpanda documents that it does not support customer access to or modification of internal data plane resources, and gives its reason: Redpanda manages configuration changes internally to support a 99.99% SLA for BYOC clusters. That is a specific, documented limit on what the customer can do inside the account. It is not a general claim that the customer has no control, and this post does not make one.
"Runs in your account" therefore establishes where the resources live. It does not establish who can create, change or remove them. Who owns a control plane once the architecture splits is the question the Control Plane Architecture stage of the learning path takes up.
Same Location, Different Authority
BYOC delegation varies even when location does not, and Redpanda provides the cleanest control: one vendor, one data plane location, two variants.
In standard BYOC, Redpanda manages the networking lifecycle and assigns the IAM policies. In BYOVPC, you supply the VPC and the IAM role the agent assumes. You create the networking and security resources in advance, and Redpanda states that the agent does not create or change them. The agent still deploys and operates the cluster, using the role you supply with only the permissions you grant. Redpanda says BYOVPC requires fewer permissions than standard BYOC.
Databricks shows this is not a Redpanda naming quirk. The cross-account role for a Databricks-managed VPC carries permissions to create and delete the VPC, subnets, route tables, NAT and internet gateways and VPC endpoints, plus launch and terminate instances. For a customer-managed VPC the documented set is smaller: the VPC, subnet, route and NAT creation and deletion permissions do not appear in that table, and the documentation states the set can be scoped down further with custom resource restrictions.
| Dimension | Vendor-managed BYOC | Customer-managed variant |
|---|---|---|
| Data-plane location | Customer account (Redpanda, Databricks) | Customer account (Redpanda, Databricks) |
| IAM authority | Redpanda assigns the policies and creates the roles | Redpanda BYOVPC: customer supplies the role, and the agent is limited to what it grants |
| Delegated permissions | Databricks: full VPC and network lifecycle set | Databricks: smaller set, scopable further |
| Network resources | Redpanda manages the networking lifecycle | Customer creates them in advance (Redpanda) or provisions the VPC (Databricks) |
| Operational burden | Not stated in the pages read | Not stated in the pages read |
The location row is identical in both columns. The authority rows are not. Same location is not same authority.
The Decision Is Made at Deployment, and Reduced Authority Can Be a Product Boundary
Two further facts from the same pages change how to read the table. Redpanda states that existing clusters cannot be converted to BYOVPC and that a BYOVPC cluster cannot change VPCs after creation. BYOVPC is an add-on that requires Premium support. On the Databricks side, the customer-managed VPC variant requires the Premium plan or above.
This is not a pricing argument. The architectural point is that BYOC delegation is a design decision, not an implementation detail. In these two offerings, narrower vendor authority is a variant you select and a tier you qualify for, not a setting you adjust later. For Redpanda the variant is fixed at creation. The Databricks page I read does not state whether a workspace can move between VPC types.
The far end of the range is a vendor claim, and it should be read as one. In a June 2024 blog post, WarpStream says its agents need only access to an object storage bucket and an outbound connection to its control plane, that no IAM roles or permissive security policies are required, and that the customer is responsible for running the stateless compute. I have not independently verified any of that, and it does not appear as a row in the inventory below. It shows what the variable looks like when a vendor chooses to remove the grant instead of reducing it.
The BYOC Delegation Inventory
Diagnostic: "What can this vendor's control plane actually do inside my account, and what do the vendor's own documents say about it?"
A review of BYOC delegation should produce an inventory, not a residency statement. Here is the inventory for the offerings reviewed, with four columns. The fourth is validation, not a control: it records what the documentation says happens to the deployed data plane if the vendor control plane is unreachable, and it is evidence-dependent. Where a page I read does not state something, the cell says NS.
| Offering (variant) | Install-time grant | Resource scope | Customer-side constraint | Control-plane-loss behavior (validation, not a control) |
|---|---|---|---|---|
| Redpanda BYOC (standard) | Customer bootstraps a VM in their VPC that launches the agent. Redpanda then assigns the IAM policies and creates dedicated per-workload roles. The agent uses them to call the cloud provider API. | Cluster resources, Kubernetes version upgrades and infrastructure maintenance, VPC peering, and the networking lifecycle. | None stated for scoping the grant. Customers cannot access or modify internal data plane resources. | Stated: clusters remain available if the connection to the control plane is lost. Management during the outage: NS. |
| Redpanda BYOVPC (add-on, Premium support) | Customer supplies the VPC and the IAM role (instance profile) the agent assumes. The agent operates with only the permissions the customer grants. | Customer pre-creates networking and security resources, and the agent does not create or change them. It still deploys and operates the cluster infrastructure. | Customer grants the permissions. The example module restricts the IAM it grants to tagged resources and the cluster definition references a permissions boundary policy. Provisioning checks that the roles meet a minimum permission set, so there is a floor as well as a ceiling. | NS on this page. The page states the cluster needs outbound access to send telemetry to the control plane. |
| Databricks (Databricks-managed VPC) | Cross-account IAM role in the customer's AWS account. The documented purposes include creating and deleting the VPC, subnets, route tables, NAT and internet gateways and VPC endpoints, plus launching and terminating instances. | EC2 and VPC resources for the workspace. | Organization-level SCPs that deny AssumeRole or EC2/VPC access can break the role setup, so customer-side policy can constrain it. | NS. |
| Databricks (customer-managed VPC, Premium or above) | Same role mechanism, smaller permission set. The VPC, subnet, route and NAT create and delete permissions do not appear in this table. Instance launch and terminate, volumes, fleets and launch templates remain. | Narrower, because the customer provisions the VPC. | The documentation states the set can be scoped down further with custom resource restrictions. | NS. |
| Aiven (AWS custom cloud) | Customer applies a generated Terraform template that yields a Role ARN. Aiven assumes that role to run operations such as creating node VMs. The documentation describes it as permission to create resources and manage them onward. | A VPC Aiven creates in the customer account (customer-chosen CIDR, /16 to /24), node VMs, and an S3 bucket if object storage is enabled. The customer selects which Aiven projects or units may use the cloud. | The template can be viewed, downloaded and modified before it is applied. How the role's permissions can be scoped: NS. | NS. |
Three readings follow, and none of them goes beyond the cells.
First, the density of NS. The control-plane-loss column is populated for one of the three vendors, and even there it states availability, not whether management continues. The constraint column is documented for Redpanda BYOVPC and Databricks, and partial for Aiven.
Second, a pointer on Aiven. The IAM permissions JSON on the Aiven page belongs to the user who deploys the template, not to the role Aiven assumes. The Aiven documentation I reviewed does not state how that role's permissions can be scoped. It does show the template can be viewed before you apply it, which is the place to start reading the grant.
Third, an inversion. In standard Redpanda BYOC, the documented constraint binds the customer, not the vendor: the customer cannot access or modify internal data plane resources in the account the customer owns.
Unknown is a result. If a vendor's documentation establishes where the workload runs but does not establish what happens when its control plane disappears, the architecture review should record that gap, not infer an answer. Same location plus documented BYOC delegation is still not an understood architecture. It is an architecture with a populated inventory and a list of questions to put to the vendor.
What This Post Does Not Argue
Four adjacent arguments already have homes, and this post cites them instead of repeating them.
- Your Cloud Isn't Compromised. Your Vendor Is. Now What? covers why third-party authority persists after the trust behind it fails.
- That SaaS integrations accumulate authority over time belongs to The SaaS Control Plane Problem. The BYOC delegation examined here is the authority granted at deployment, not what builds up afterward.
- The delegation object and its schema are covered by Enterprise Architecture Has Identity Governance. It Doesn't Have Delegation Governance. The inventory above is a BYOC-specific fill-in, not a competing model.
- How a delegation is revoked belongs to Rotating Credentials Is Not Revoking Them. This post does not teach the mechanism, and the inventory has no removal-path column. Two scope limits apply. The empirical claims cover the BYOC offerings reviewed here and no others. And the inventory has no column for whether a vendor can change the grant over time, because none of the pages I read state it. That row is under investigation, not claimed.
Architect's Verdict
BYOC is a control-plane delegation decision disguised as a deployment-location decision. The residency answer is real and the documentation supports it. It is also the less informative of the two answers a review needs.
The underlying problem is that the install step establishes the BYOC delegation while the review records the location. In the offerings reviewed here, the vendor-created roles, the resources a customer may not touch, and the narrower variants gated behind a tier are all visible in public documentation. They go unscoped because the review has no artifact that asks for them.
The BYOC delegation inventory is that artifact, and its empty cells are part of its output. Where the documentation is silent, you have found a question for the vendor, not a reason to assume the answer you were hoping for.
Residency tells you where the data sits. Only the inventory tells you who can act on it.
Additional Resources
- Cloud Architecture Strategy — the pillar hub covering placement, ownership and exit decisions across cloud architecture.
- Control Plane Architecture — the learning path stage on who owns the control plane once responsibility splits across vendor and customer.
- Your Cloud Isn't Compromised. Your Vendor Is. Now What? — what happens to standing third-party authority once the trust behind it fails.
- The SaaS Control Plane Problem — how authority accumulates through SaaS integrations, the layer after the install-time grant covered here.
- Enterprise Architecture Has Identity Governance. It Doesn't Have Delegation Governance. — the delegation object this post's inventory fills in for BYOC.
- Redpanda BYOC Architecture — vendor documentation for the standard BYOC control plane and agent model.
Originally published at rack2cloud.com
Top comments (0)