Redpanda Cloud: should we choose Serverless, Dedicated, or BYOC for a regulated workload?

Most regulated teams don’t ask “Kafka or not?” anymore—they ask where their data actually lives, who can touch it, and how fast they can prove it. In Redpanda Cloud, that comes down to three deployment models—Serverless, Dedicated, and BYOC—that all run the same high‑performance engine, but make very different trade-offs on sovereignty, control, and operational responsibility.

Quick Answer: For regulated workloads, Redpanda Cloud BYOC is usually the safest default because it keeps data and infrastructure inside your own cloud account while still giving you a fully managed, Kafka-compatible streaming platform. Dedicated is a strong fit when you need isolation and SLAs but don’t have strict data residency or “own the VPC” requirements. Serverless is ideal for less-sensitive workloads, edge/prototyping, and bursty or unpredictable traffic where governance demands are lighter.

The Quick Overview

What It Is: Redpanda Cloud is a fully managed, Kafka-compatible streaming platform available in three deployment models—Serverless, Dedicated, and BYOC (Bring Your Own Cloud)—all built on the same Redpanda engine.
Who It Is For: Platform, data, and AI infrastructure teams that need high-throughput streaming plus strict governance for sensitive data and AI agents, especially in regulated industries.
Core Problem Solved: It gives you a governed, production-grade streaming backbone—without running clusters yourself—while still meeting requirements around data sovereignty, access control, auditability, and cost predictability.

How It Works

Redpanda Cloud lets you choose where the Redpanda engine runs and who owns the underlying cloud resources, without changing your APIs or your application code.

All three options share the same core:

Kafka-compatible API
One-binary, zero-dependency engine
High throughput and predictable latency (10GBps+ workloads, 1.1T+ records/day in production)
Cloud-native capabilities like tiered storage, self-healing, and multi-AZ high availability

The difference is the control plane and data plane split—who owns the VPC, who sees the infrastructure, and how deep your compliance and governance needs go.

Serverless: Redpanda runs everything in Redpanda’s cloud accounts. You consume it as pure SaaS—no clusters to manage, no capacity planning. You get a Kafka-compatible endpoint and pay for usage.
Dedicated: Redpanda provisions isolated, fully managed clusters in Redpanda-owned accounts, tuned to your workload with stronger isolation, SLAs, and optional managed Connect. You get private networking options and more knobs for scale and performance.
BYOC (Bring Your Own Cloud): Redpanda deploys and manages the same Dedicated clusters inside your own AWS/GCP/Azure accounts. You keep full control over underlying infrastructure and data locality, while Redpanda operates the engine and control plane.

From an application point of view, you connect via Kafka APIs and treat it as a single streaming layer. From a compliance and governance point of view, you choose the model that matches your regulator, your CISO, and your AI risk posture.

Connect / Control / Operate Across Models

Think of the decision as three axes: how you connect, how you control, and how you operate.

Connect: All models give you Kafka-compatible endpoints, 300+ connector options, and the same streaming semantics. Your client code doesn’t change.
Control: BYOC gives you maximum control over underlying infrastructure and data residency. Dedicated gives you strong isolation and enterprise controls without owning the VPC. Serverless prioritizes speed and elasticity over deep infrastructure control.
Operate: In all cases, Redpanda operates the clusters: upgrades, scaling, high availability, and 24x7 support. Your team focuses on topics, schemas, and policies, not brokers and Zookeeper (which Redpanda replaces entirely).

For regulated workloads—especially when agents will read and write sensitive operational data—the Control axis is usually the deciding factor.

Serverless vs Dedicated vs BYOC: Regulated Workload Lens

Serverless: Fastest path, least infrastructure control

Serverless is Redpanda in pure SaaS mode. Redpanda owns the infrastructure, networking, and capacity planning. You own topics, ACLs, and how your systems use the streams.

Best when:

You need to move quickly with non-PII, non-regulated data.
You’re prototyping new AI agents or event-driven features where compliance requirements are still being defined.
You value “no-cluster” operations and elastic scale over VPC-level control.

Trade-offs for regulated workloads:

Data sovereignty: You don’t control the underlying infrastructure. This can be a blocker where regulators require workloads to run in your own cloud account or specific landing zone.
Network boundaries: You rely on Redpanda’s networking model (public endpoints, private connectivity options where available), which may not satisfy stricter “no traffic leaves our VPC” policies.
Audit scope: You get Redpanda’s audit features, but not IaaS-level logs (e.g., CloudTrail, GCP Audit Logs, or Azure Activity Logs) for the Redpanda nodes, because those resources aren’t in your account.

If your regulator or security team mandates strict data residency, SCPs, or shared responsibility that includes infrastructure layer logs, Serverless is usually not the right home for the crown jewels.

Dedicated: Fully managed clusters with strong isolation

Dedicated gives you a fully managed Redpanda cluster, deployed as a service in Redpanda-owned cloud accounts. It’s built for predictable, high-throughput workloads with enterprise controls and multi-AZ resilience.

Key characteristics:

Deployment model: Cloud clusters as a service, deployed on recognized cloud providers. Redpanda provisions and operates the clusters.
Dedicated resources: Isolated clusters (no noisy neighbors), with capacity sized to your workload.
Integrated console: Each Dedicated cluster ships with a dedicated Redpanda Console for observability and operations.
Optional managed Connect: You can add fully managed Kafka Connect and connectors to ingest and egress data.

Regulated workload strengths:

High availability & durability: Multi-AZ, Raft-based durability, read replicas, and self-healing, tested at extreme scale.
Compliance readiness: Enterprise security features (RBAC, OIDC/Kerberos, audit logging) help you meet many compliance frameworks.
Operational guarantees: 24x7 support and SLAs, plus predictable performance for GBps workloads.

But:

Data sovereignty: Infrastructure resides in Redpanda-owned accounts. You get strong logical isolation and security, but not “we own the VPC” guarantees.
Cloud flexibility: You can pick regions and providers where Dedicated is available, but you don’t control the underlying IaaS contracts or org-level policies.

Dedicated is a strong fit when you’re regulated but not under strict “must run inside our cloud account” rules. Financial services teams often run tiered architectures here: non-PII streams in Dedicated, highly sensitive or AI-agent-critical streams in BYOC.

BYOC: Full infrastructure control with managed operations

BYOC (Bring Your Own Cloud) is the model purpose-built for regulated workloads and strict data sovereignty.

Redpanda deploys and manages the same Dedicated clusters directly into your own AWS, GCP, or Azure accounts. You maintain full ownership of the VPC, subnets, security groups, and IaaS-level logs. Redpanda manages the software and operations.

Key characteristics:

Full control over infrastructure: Clusters run in your cloud account. You decide regions, VPC topology, peering, firewall rules, and IAM baselines.
Data sovereignty: You keep data and compute under your cloud contract—critical for data residency, national cloud, and industry-specific rules.
Same engine, same features: BYOC uses the same core Redpanda engine as Dedicated. Kafka compatibility, tiered storage, Raft durability, high throughput—all included.
Managed by Redpanda: You still get fully managed upgrades, self-healing, scaling assistance, and 24x7 support. It’s not DIY.

Why regulated teams prefer BYOC:

Regulator-friendly story: “All data and compute for this streaming system live in our cloud account, under our IAM and SCPs. Redpanda operates it, but we own the boundary.”
Deep audit and forensics: Combine Redpanda’s audit logs with your cloud provider’s logs for a complete picture—from API calls to network events.
Network isolation: Keep the cluster fully private inside your VPC, expose endpoints via your own private connectivity strategy (PrivateLink, VPN, peering, etc.).
Data residency & sovereignty: Satisfy “in-region, in-account” requirements and data localization laws while still using a managed service.

If you’re asking the question in the page slug—“should we choose Serverless, Dedicated, or BYOC for a regulated workload?”—BYOC is almost always the recommended answer unless your compliance team explicitly says that Dedicated or Serverless meets your bar.

Features & Benefits Breakdown

Below is a simplified comparison aimed at regulated workloads.

Core Feature	Serverless	Dedicated	BYOC
Infrastructure Ownership	Redpanda-owned	Redpanda-owned	Customer-owned (your AWS/GCP/Azure accounts)
Data Sovereignty	No control over underlying infrastructure	Strong isolation, but infra in Redpanda accounts	Full control over infrastructure, BYOC option for compliance on AWS, GCP, Azure
Deployment Model	Fully managed, multi-tenant/serverless	Fully managed single-tenant clusters	Fully managed, in your cloud account (BYOC)
Network Control	Limited VPC-level control	Private networking options, but Redpanda VPC	Full VPC control: routing, firewall, peering, PrivateLink, etc.
Compliance Alignment	Best for low-sensitivity data, internal tools	Good fit for many regulated use cases without strict VPC ownership	Best fit for strict regulatory regimes, data residency, and sovereignty
Operational Burden	Lowest	Low	Low (Redpanda manages), but you manage cloud account guardrails
Cost Model	Usage-based, elastic	Reserved capacity, predictable scaling	Reserved capacity in your accounts; potential savings via your cloud discounts & commitments

Ideal Use Cases

Serverless

Best for early-stage AI and event prototypes: Because it lets you stand up Kafka-compatible streaming in minutes without touching infrastructure, perfect for testing agent behaviors on non-sensitive data.
Best for bursty or seasonal workloads: Because the elastic, usage-based model absorbs unpredictable spikes without you pre-planning cluster capacity.

Dedicated

Best for high-throughput, business-critical apps without strict account-level sovereignty: Because you get isolated clusters, HA, and enterprise support without managing the underlying cloud infrastructure.
Best for teams consolidating Kafka sprawl: Because you can migrate from self-managed Kafka/MSK into a simpler, high-performance managed cluster with tiered storage and lower operational load.

BYOC

Best for regulated, production AI agent workloads: Because agents will use and change sensitive data, and BYOC lets you govern every action on a streaming backbone that lives inside your own cloud accounts.
Best for organizations with strict data residency and sovereignty mandates: Because all compute and storage stay in your own AWS/GCP/Azure org, under your IAM, logging, and SCPs, while Redpanda operates the software.

Limitations & Considerations

Serverless governance limitations:
Serverless can still enforce topic-level ACLs, authentication, and audit logs, but you cannot apply your own VPC-level controls or org-level policies to the underlying hosts. For workloads where regulators care about infrastructure boundaries or sovereign clouds, this is often a hard stop.
BYOC operational responsibilities:
BYOC offloads cluster operations to Redpanda, but you still own cloud account hygiene: VPC design, peering, IAM guardrails, and provider-level compliance settings. You need a cloud team comfortable owning that layer.
Dedicated sovereignty boundary:
Dedicated meets many compliance frameworks via security controls, HA, and auditability, but some regulators or internal policies will insist on “in-account” deployments. In those cases, BYOC becomes non-negotiable.
Migration planning:
Redpanda is Kafka-compatible and drop-in friendly, but moving from a legacy Kafka stack (or between Serverless/Dedicated/BYOC) still requires planning around topics, ACLs, schemas, and client configs.

Pricing & Plans

Redpanda Cloud pricing varies by deployment model and workload profile, but the broad contours for regulated teams look like this:

Serverless:
Usage-based pricing (capacity and traffic) with no cluster sizing to worry about. Ideal when you can treat streaming as a pure utility and don’t need infrastructure-level commitments.
Dedicated:
Cluster-based pricing with reserved capacity and predictable spend for steady, high-throughput workloads. Costs are significantly lower than running equivalent Kafka stacks in many cases due to reduced broker counts and operational overhead.
BYOC:
You pay Redpanda for the managed service, plus your cloud provider for the underlying infrastructure in your accounts. The upside: you can apply your existing enterprise discounts, reserved instances, and committed spend, often reducing net TCO versus SaaS-only models or legacy Kafka services.

Concrete choice guidance:

“We must own the cloud accounts, VPC, and logs for regulated systems.” → Choose BYOC.
“We’re regulated but infra ownership is flexible; we mostly need isolation and SLAs.” → Choose Dedicated.
“This workload is not regulated; we want minimum friction and pay-for-what-we-use.” → Choose Serverless.

Frequently Asked Questions

Is BYOC mandatory for regulated workloads, or can we use Dedicated?

Short Answer: If your regulator or internal policies require workloads to run inside your own cloud accounts, BYOC is mandatory. If they only require strong isolation, encryption, and auditability, Dedicated may be sufficient.

Details:
Regulation isn’t one-size-fits-all. Some frameworks focus on controls—encryption, access management, audit logs, and incident response. Redpanda Dedicated can meet a lot of those needs: multi-AZ HA, enterprise security, audit logs, and strict tenant isolation.

However, other regimes (especially in finance, government, healthcare, and region-specific data residency laws) explicitly require that certain workloads run inside your org’s cloud accounts, under your IAM and VPC design. In those environments, the ability to say “all compute and storage for this system run in our AWS/GCP/Azure org” is critical. That’s exactly what BYOC provides.

In practice, many enterprises run a mix: BYOC for their most sensitive and regulated workloads, Dedicated for broader internal event streams, and Serverless for experimentation and non-sensitive use cases.

How hard is it to migrate between Serverless, Dedicated, and BYOC?

Short Answer: It’s straightforward but not push-button. Redpanda’s Kafka compatibility and connector ecosystem make migrations predictable, but you still need a planned cutover.

Details:
Because all three Redpanda Cloud options expose Kafka-compatible endpoints, migration looks like a typical Kafka-to-Kafka move:

Stand up the new target cluster (e.g., BYOC) alongside the existing environment.
Mirror topics and data using Kafka Connect, MirrorMaker-like patterns, or other replication tools.
Gradually cut over producers and consumers to the new endpoints.
Validate latency, throughput, and policy behavior (ACLs, auth, encryption).
Decommission the old cluster once traffic is drained and retention windows have passed.

If you’re coming from legacy Kafka (self-managed, MSK, or another vendor), the same process applies. The main difference is that once you’re on Redpanda, you can later switch between Dedicated and BYOC using the same patterns, without changing application code.

Redpanda’s team and documentation can help with reference architectures, replication setups, and cutover plans—especially for high-volume or zero-downtime migrations.

Summary

For regulated workloads, you’re not just buying Kafka compatibility—you’re buying control, sovereignty, and proof.

Serverless gives you the fastest path and lowest operational burden, but limited control over underlying infrastructure, making it best for non-regulated or low-sensitivity data.
Dedicated gives you isolated, fully managed clusters with enterprise features and SLAs, suitable for many regulated scenarios where owning the VPC isn’t mandatory.
BYOC runs the same high-performance engine inside your own cloud accounts, giving you full infrastructure control, data sovereignty, and the audit story regulators expect—while Redpanda still handles upgrades, HA, and 24x7 operations.

If your agents, services, or compliance teams will put this system under a microscope, BYOC is usually the right place to start.

Next Step

Get Started