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

Regulated workloads force an uncomfortable question: how do you give agents and streaming apps the low-latency backbone they need without losing control of where data lives and who can touch it? With Redpanda Cloud, that choice usually comes down to three deployment models: Serverless, Dedicated, and BYOC. All three run the same high-performance Kafka-compatible engine. The difference is how much control you need over infrastructure, data residency, and compliance boundaries.

Quick Answer: For heavily regulated workloads, Redpanda BYOC is usually the default because it runs entirely in your own cloud account while staying fully managed. Dedicated fits teams with strong cloud controls but fewer data-sovereignty constraints. Serverless is best for non-sensitive workloads, rapid prototyping, and bursty or unpredictable traffic where cost and agility matter more than strict regulatory lines.

---

The Quick Overview

• What It Is: Redpanda Cloud is a fully managed, Kafka-compatible streaming platform delivered in three deployment flavors: Serverless, Dedicated, and BYOC (Bring Your Own Cloud).
• Who It Is For: Platform, data, and application teams building always-on, event-driven, and agentic systems that must meet strict SLOs, auditability, and compliance requirements.
• Core Problem Solved: It gives you a high-throughput, low-latency streaming backbone with enterprise-grade controls—without you running brokers—while letting you choose where and how the underlying infrastructure is hosted to satisfy regulatory and data sovereignty requirements.

---

How It Works

All Redpanda Cloud options give you the same core engine: a Kafka-compatible, one-binary, zero-dependency streaming platform optimized for 10GBps+ workloads, with tiered storage, high availability, and enterprise security. The difference is who owns the infrastructure and where it runs.

At a high level:

1. Serverless:
   Redpanda operates everything in Redpanda-owned cloud accounts. You get instant spin-up, automatic scaling, and no infrastructure decisions—but minimal control over the underlying environment. Best for speed and elasticity, not strict data sovereignty.

2. Dedicated:
   Redpanda runs fully managed clusters in Redpanda-controlled accounts on your chosen provider (AWS/GCP/Azure). You get network isolation, predictable resources, and production-grade controls, but Redpanda still owns the infrastructure. Fits regulated workloads where cloud-provider boundaries and contracts are enough.

3. BYOC (Bring Your Own Cloud):
   Redpanda operates the same Dedicated-grade engine, but in your cloud account. You keep full control over infrastructure, data residency, VPC layout, and compliance posture, while Redpanda manages the software. This is the sweet spot for strongly regulated, high-sensitivity workloads.

---

Features & Benefits Breakdown

All three options share core Redpanda capabilities—Kafka API compatibility, tiered storage, high availability, and enterprise-grade controls. The key differences are in infrastructure control, data sovereignty, and operational model.

Core Feature	What It Does	Primary Benefit
Managed Redpanda Engine	Runs the same high-performance streaming engine across Serverless, Dedicated, and BYOC.	Consistent Kafka-compatible behavior and performance across deployment models.
Infrastructure Ownership	Determines whether Redpanda or your company owns the underlying cloud resources.	Lets you align deployment choice with regulatory and data sovereignty requirements.
Data Sovereignty & Compliance	Maps Redpanda Cloud to your compliance boundary (from vendor-owned infra to your own VPC).	Enables regulated workloads without sacrificing the streaming and agentic capabilities you need.

Let’s unpack each model through a regulated-workload lens.

---

Serverless: Maximum Agility, Minimum Infrastructure Control

Serverless is the “just give me a cluster” option. You provision a Redpanda Cloud cluster and start streaming. Redpanda handles capacity, upgrades, and scaling.

How it works for regulated workloads:

• Runs in Redpanda-owned infrastructure on your chosen cloud region.
• You choose region and some configuration; Redpanda owns the underlying accounts and resources.
• Security and access are controlled at the cluster level (SSO, RBAC, etc.), but you don’t control the underlying VPC, subnets, or storage primitives.

What this means for governance and compliance:

• Pros:

  • Fastest path from prototype to production for non-sensitive use cases.
  • No broker or storage management; ideal for teams ramping up event-driven or agentic workloads.
  • Good for workloads where regionality matters but deep infrastructure control does not.

• Cons:

  • No direct control over underlying infrastructure, which is a non-starter for some regulators and internal security teams.
  • Harder to align with strict data residency rules that require data to remain in your accounts and under your IAM policies.
  • VPC, peering, and network-level controls are limited to what Redpanda exposes.

When it fits regulated workloads:
Only when your regulatory constraints focus on logical security and region, not strict “data must reside in our accounts” rules. Think: internal tools, PII-lite workloads, or observability streams that don’t cross into highly sensitive data.

---

Dedicated: Managed Clusters with Strong Isolation

Dedicated clusters are managed Redpanda Cloud deployments running in Redpanda-owned accounts but with more isolation and control than Serverless.

How it works for regulated workloads:

• Redpanda provisions and manages a dedicated cluster for your org on a single cloud provider and region.
• You get a dedicated Redpanda Console and, optionally, fully managed Kafka Connect clusters and connectors.
• Resources are isolated from other tenants at the cluster level, with strong separation and hardened environments.

What this means for governance and compliance:

• Pros:

  • Strong isolation and predictable performance for mission-critical workloads.
  • Easier to reason about capacity, SLOs, and network paths (e.g., VPC peering, private connectivity).
  • Enterprise features like Raft durability, Multi-AZ HA, read replicas, and self-healing give you the reliability story auditors expect.
  • 24x7 support and SLAs help you clear “production with confidence” and compliance-readiness claims.

• Cons:

  • Infrastructure still lives in Redpanda-owned cloud accounts, which may be insufficient for strict sovereignty rules.
  • Your internal cloud security team doesn’t own the resources or IAM, which can complicate shared-responsibility documentation.
  • If regulators or internal policies require full control over the underlying infrastructure, Dedicated alone won’t satisfy them.

When it fits regulated workloads:
When your regulators and security teams are satisfied with vendor-owned infrastructure as long as:

• It’s in a specific region and provider.
• There’s strong tenant isolation and documented security controls.
• You have contractual guarantees and auditability (logs, access tracking, etc.).

Think: financial services apps under a major cloud’s established compliance umbrella, or healthcare workloads where the provider + vendor combination is certifiable.

---

BYOC: Regulated-First, Data-Sovereign by Design

BYOC (Bring Your Own Cloud) is the regulated team’s best friend. It’s the same fully managed engine as Dedicated, but everything runs inside your own cloud account on AWS, GCP, or Azure.

How it works for regulated workloads:

• Redpanda deploys the Redpanda Cloud Dedicated architecture into your VPC using your cloud account.
• You retain ownership and full control over:
  • Underlying infrastructure (instances, storage, networks).
  • Data residency and replication policies (region, zones, cross-region options).
  • Cloud-provider IAM, logging, and encryption policies.
• Redpanda operates and upgrades the Redpanda software, monitors health, and handles day-two operations.

What this means for governance and compliance:

• Pros:

  • Full control over infrastructure. You decide VPC layout, subnet topology, and security groups.
  • Data sovereignty: Data never leaves your cloud account. Easy to align with “data must remain inside our VPC or jurisdiction” requirements.
  • Compliance on AWS, GCP, Azure: BYOC is explicitly designed to support compliance requirements like data residency and sovereignty on major clouds.
  • Integrates naturally into your existing security stack: centralized logging, KMS-based encryption, IAM roles, and network inspection.
  • Lets you bring Redpanda into air-gapped or highly restricted environments, where direct vendor-managed infra isn’t allowed.

• Cons:

  • Slightly more upfront coordination with your cloud/platform team to prepare accounts and networking.
  • Some organizations may need to update internal ops playbooks to clarify shared responsibilities (you own infra; Redpanda owns the runtime).

When it fits regulated workloads:
Most of the time. If your requirements include any of the following, BYOC is the default:

• Data must reside in your own cloud accounts.
• You need full control over VPCs, private networking, and peering.
• Regulators or security mandates explicitly forbid vendor-owned infra for sensitive data.
• You’re building cross-domain agentic systems where data movement between domains must be tightly governed and fully auditable.

---

Choosing Between Serverless, Dedicated, and BYOC for Regulated Workloads

When regulated workloads are involved, the decision usually comes down to four questions:

1. Who must own the infrastructure?

   • If your compliance team insists that all data and compute live in your accounts, you need BYOC.
   • If vendor-owned accounts are acceptable within a specific region and provider, Dedicated can work.
   • If infra ownership is not a factor and you just need region + encryption, Serverless is viable for lower-sensitivity scenarios.

2. How strict are your data sovereignty rules?

   • “Data must never leave our VPC” → BYOC.
   • “Data must stay in this country/region on approved providers” → Dedicated or BYOC, depending on infra ownership rules.
   • “Region and encryption-at-rest are enough” → any of the three, depending on operational preferences.

3. What’s your operational maturity and appetite?

   • Need maximum agility and minimal ops overhead for early-stage workloads → Serverless.
   • Need predictable capacity, dedicated clusters, and SLO-backed performance → Dedicated or BYOC.
   • Need that plus tight integration with your existing network and security baseline → BYOC.

4. How sensitive is the data your agents and applications will use and change?

   • Low sensitivity, prototype agents, internal support tools → Serverless is fine to start.
   • Customer PII, financial records, clinical data, or regulated logs you must retain immutably → Dedicated if infra ownership is acceptable, BYOC if it isn’t.

---

Ideal Use Cases

• Best for Serverless:
  Because it’s built for agility and bursty workloads where you don’t want to plan capacity. Perfect for:

  • Proof-of-concept agentic apps that need Kafka-compatible streams without infra overhead.
  • Non-PII telemetry, clickstream analytics, and development/test environments.
  • Early-stage teams validating patterns before locking in compliance-heavy deployments.

• Best for Dedicated:
  Because it provides isolated, production-grade managed clusters with strong reliability. Ideal for:

  • Business-critical applications with clear SLOs that still permit vendor-owned infrastructure.
  • Regulated workloads where your auditors accept provider-level certifications and contractual controls.
  • Teams that want a stable, high-throughput Kafka alternative without managing brokers, but don’t need full account-level control.

• Best for BYOC:
  Because it combines full infrastructure ownership with a fully managed Redpanda control plane. Best fit for:

  • Highly regulated industries (finance, healthcare, public sector) with strict data residency and sovereignty rules.
  • Enterprise AI and agentic workloads that touch sensitive operational data and must be auditable and governed inside your own VPC.
  • Organizations standardizing on a “cloud account as compliance boundary” model and needing Kafka compatibility without the operational drag.

---

Limitations & Considerations

• Serverless: Limited Infrastructure Control
  You can’t dictate underlying instance types, storage configurations, or VPC-level policies beyond what the service exposes. For teams under strict governance, this often isn’t enough. Workaround: Use Serverless for non-sensitive or pre-production workloads, and graduate to Dedicated or BYOC once compliance kicks in.

• Dedicated: Vendor-Owned Infra
  Even though you get isolation and strong controls, the cluster still lives in Redpanda’s accounts. If your risk/compliance office is strict about “no third-party infra for regulated data,” this becomes a blocker. Workaround: Move to BYOC, which retains Dedicated’s managed experience but in your own account.

---

Pricing & Plans

Redpanda Cloud pricing is usage-based, with differences tied to deployment model and underlying infrastructure responsibility. As a general pattern:

• Serverless emphasizes elastic consumption, making it cost-effective for spiky or unpredictable workloads.
• Dedicated and BYOC emphasize steady-state, high-throughput clusters with clear capacity planning.

For regulated workloads, most teams treat Redpanda Cloud as critical infrastructure and bias toward predictable, SLO-backed deployments.

• Serverless: Best for teams needing fast time-to-value and elastic scaling without committing to fixed capacity. Use when compliance and data sovereignty requirements are lighter and cost variability is acceptable.

• Dedicated: Best for teams needing managed, isolated clusters with production SLAs where vendor-owned infra is permitted. You get predictable infrastructure profiles with less variability than Serverless.

• BYOC: Best for teams needing strong compliance alignment, full control over infrastructure, and predictable cost behavior tied directly to your own cloud contracts and reserved capacity. BYOC lets you combine Redpanda’s managed expertise with your existing cloud cost and governance strategy.

For exact pricing details and volume discounts, talk directly with Redpanda—especially if you’re consolidating multiple Kafka-like systems or migrating from a legacy MSK or Confluent stack.

---

Frequently Asked Questions

Is Redpanda Serverless safe for regulated data?

Short Answer: It can be, but it depends on your regulator and internal risk posture; many highly regulated teams still prefer BYOC.

Details:
Serverless clusters inherit the cloud provider’s security posture (encryption at rest, secure networking, etc.) and Redpanda’s own enterprise security controls. For some organizations, that’s sufficient—particularly when data is pseudonymized, non-PII, or not mission-critical.
However, if your policies require all regulated data to live within your own cloud accounts, or if auditors expect you to control VPCs, IAM roles, and storage objects directly, Serverless won’t meet the bar. In those cases, Serverless is better suited for pre-production, experimentation, and non-sensitive workloads, with BYOC as the production path.

---

When should I pick Dedicated vs BYOC for a regulated workload?

Short Answer: Choose Dedicated if vendor-owned infra is allowed; choose BYOC if your compliance boundary is “our cloud account or nothing.”

Details:
Use Dedicated when:

• Your regulators and security team are comfortable with vendor-owned infrastructure, as long as it’s in approved regions and clouds.
• You want Redpanda to own more of the operational envelope while you integrate via network-level controls (peering, private endpoints).
• Your data is sensitive but not subject to strict sovereignty rules that require account-level ownership.

Use BYOC when:

• Policies or regulators require that all data and compute live in your own AWS/GCP/Azure accounts.
• You need deep integration with your security tooling—centralized logging, KMS keys, IAM policies, private service endpoints—and you want to prove that no third party can move or directly access your data without going through your controls.
• You’re building highly sensitive event streams (financial transactions, health records, regulated logs) that support agentic systems and must be auditable end to end, within your own cloud perimeter.

---

Summary

For regulated workloads, the key decision isn’t “Can Redpanda handle my scale?”—we know it can, from 1.1 trillion records/day to 100GB/min workloads. The real decision is “Where does my compliance boundary sit, and who owns the infrastructure inside it?”

• Serverless is your fastest, most flexible option for non-sensitive or early-stage workloads where infra ownership isn’t the primary concern.
• Dedicated gives you isolated, production-grade clusters in Redpanda-owned accounts—good when auditors are fine with vendor infra as long as it’s secure and certified.
• BYOC brings the full managed experience into your cloud account, aligning streaming and agentic workloads with strict data sovereignty, residency, and regulatory rules.

If your risk team is already asking, “Who owns the VPC?” or “Can we prove data never leaves our account?”, you’re squarely in BYOC territory.

---

Next Step

Get Started