I spent three months in early 2025 helping a 500-person fintech company evaluate whether to take the BYOC option from their data pipeline vendor. The conversation kept cycling through the same three axes: their compliance team was nervous about data leaving their AWS org, their FinOps lead had done the math on redirecting SaaS spend through their enterprise discount program, and their ML platform team had locked up $4 million of H100 capacity in a specific region that no managed SaaS offering could target. Every angle pointed the same direction. That project changed how I think about SaaS buying decisions at enterprise scale, and it made me realize that BYOC has crossed from “exotic feature for hyperscalers” to “table-stakes expectation” in the space of about three years.
This article is for two audiences: engineers evaluating BYOC options from their SaaS vendors, and architects building BYOC capability into their own products. Both need to understand what the architecture actually looks like and where it tends to blow up.
What BYOC Actually Means
The term gets used loosely, so let me be precise.
BYOC is a deployment model where the vendor’s software runs inside the customer’s cloud account, not the vendor’s. The vendor still operates and manages the software. The customer provides the compute, storage, networking, and cloud identity. Data never leaves the customer’s cloud environment.
This is different from two things people confuse it with. It is not self-hosted, where the customer runs AND manages the software themselves, handling upgrades, incidents, and configuration. It is not simply “deploy to any cloud,” where the vendor runs the software but the customer picks the region. In BYOC, the vendor operates but the customer owns the infrastructure. That distinction creates the interesting architectural problems.
The practical consequence: when your Kafka-compatible streaming vendor offers BYOC, your event data never transits their network. Their control plane sends instructions to a data plane running in your VPC, which processes your data using your S3 buckets, your KMS keys, your VPC endpoints. The vendor can upgrade the software, respond to incidents, and bill you, but they cannot access your data even if they wanted to.
Three Forces Driving BYOC Adoption Right Now
Twenty years in cloud architecture has taught me that durable adoption patterns always have at least three concurrent drivers. BYOC is no exception.
Compliance requirements that are non-negotiable. Data residency laws have real teeth now. GDPR enforcement has produced multi-hundred-million-euro fines. The EU AI Act has specific requirements about where training data can live. US government contractors increasingly require FedRAMP-scoped data handling, and FedRAMP High workloads essentially mandate that no data leave the boundary. A SaaS vendor who tells a regulated customer “trust us, your data is safe on our side” is losing deals to competitors who can say “your data never leaves your account.”
I have been in procurement conversations where the CISO flatly refused to sign any contract that didn’t include either a data processing agreement with specific breach notification timelines or a BYOC option. Enterprise procurement at regulated companies is increasingly structured such that SaaS vendors without BYOC cannot close with certain customer segments. I cover the broader regulatory landscape in the cloud sovereignty and data residency guide, but BYOC is one of the cleanest architectural responses to those requirements.
Cloud commitment economics. This one took me a while to fully appreciate. By the time a company has been on AWS for five or six years, they have negotiated enterprise discount agreements and committed to significant annual spend. The math is straightforward: if you have a $10 million AWS commit and you are paying a SaaS vendor $2 million to run workloads in their AWS account, you are paying full rack rate for compute in the vendor’s account while simultaneously carrying a take-or-pay commitment to Amazon that you may not fully utilize. BYOC flips this. The $2 million of SaaS infrastructure now runs in your account, drawing down your commit, which typically nets 20 to 30 percent off the real cost.
For the FinOps teams I work with, BYOC has become a standard line item in SaaS vendor evaluations. The BYOC premium (vendors usually charge more for BYOC because it’s operationally expensive for them) often gets paid back entirely through commit utilization within the first year. For a related analysis of how cloud account structure affects your total bill, see the article on cloud egress costs and architecture.
AI workload infrastructure constraints. This is the newest driver and the one that’s accelerating fastest. H100 and B200 GPU capacity is not fungible. You can’t just run your fine-tuning job wherever a managed SaaS wants to schedule it. Companies with multi-year GPU reservations in specific availability zones need their AI infrastructure tooling to target those exact resources. If your MLOps platform vendor runs on their own GPU fleet, you are paying for compute twice: your reservation sits underutilized while their compute runs your jobs. BYOC lets the ML platform run in your cloud, against your GPU reservation, with your network topology. Given how expensive GPU capacity has become, this alone can justify the architectural complexity.
The Architecture: Control Plane, Data Plane, Agent
Every BYOC implementation I’ve seen follows the same fundamental decomposition, even when vendors use different terminology.
The control plane is the vendor’s product: the UI, the API, the scheduler, the billing system, the configuration management, the upgrade orchestrator. This runs in the vendor’s cloud. It knows the desired state of your deployment and sends instructions to your environment to achieve it. The control plane never touches your data directly. It handles metadata: cluster configuration, job schedules, access control policies, health status.
The data plane is what runs in your cloud account: compute instances or Kubernetes pods, storage volumes, message queues, the actual workload containers. This is where your data lives and is processed. You own the IAM roles, the VPC, the KMS keys, the network flow logs. The vendor’s software runs here but it’s your infrastructure.
The agent (sometimes called the runner, the connector, or the control-plane proxy) is the critical bridge. It runs inside your environment, initiates outbound connections to the vendor’s control plane, receives instructions, and executes them locally. It also streams telemetry back (health metrics, logs, alerts) so the vendor can operate the data plane even though they have no inbound network access to your environment.
The agent pattern matters: the vendor never needs inbound access to your VPC. The agent initiates TLS connections outbound to the vendor’s control plane. This is how you maintain a tight network perimeter while still allowing the vendor to operate your deployment. It’s the same control loop pattern used by Kubernetes operators that reconcile desired state against actual state, just applied across account boundaries.
IAM and Trust: The Hardest Part
The IAM model for BYOC is where I’ve seen the most design mistakes and where the most security risk lives.
The fundamental problem: the vendor’s control plane needs authorization to act in your cloud account. How much trust do you extend to the vendor, and how do you scope it tightly?
The naive approach is to create an IAM user with broad permissions and share the credentials with the vendor. This is terrible security practice. Credentials rotate, they can be exfiltrated from the vendor’s systems, and broad permissions violate least privilege. I have seen this done by enterprise companies that should know better.
The right approach uses workload identity federation and cross-account role assumption. You create an IAM role in your account with precisely scoped permissions: read/write to specific S3 prefixes, create/delete pods in specific namespaces, describe specific VPC resources. You configure the role’s trust policy to allow the vendor’s workload identity (their OIDC provider, their service account) to assume it. The vendor’s control plane never holds long-lived credentials. They exchange their identity token for a short-lived session against your role.
The scope of that trust is critical. You want to allow the vendor to operate the data plane components (install, upgrade, scale, monitor) without giving them access to your broader cloud account. Use separate IAM roles for separate concerns: one role for infrastructure provisioning (needs EKS or EC2 permissions), a separate role for operational tasks (needs read access to pod status, write access to config maps), a separate role for observability (needs read access to CloudWatch metrics). Never one role that does everything.
On Kubernetes, this pairs naturally with RBAC scoped to the vendor’s namespace. The vendor’s agent gets a service account with namespace-scoped permissions. If a vendor’s control plane is asking for cluster-admin to install their software, that is a red flag worth investigating. Good BYOC implementations define precisely scoped ClusterRoles and document exactly what permissions are required and why.
The identity chain runs: vendor control plane workload identity as an OIDC JWT, then OIDC federation, then assume your IAM role, then scoped permissions in your account. Nothing long-lived, nothing broad, everything auditable in your CloudTrail. For secret management, the BYOC pattern stores secrets in your account (AWS Secrets Manager, HashiCorp Vault, or whatever your standard is) and grants the vendor’s data plane access to specific secrets by ARN. The vendor’s control plane pushes configuration that references your secret ARN. The data plane resolves the actual secret value at runtime from your secrets management infrastructure. The vendor never sees the secret value.
Network Connectivity Patterns
The network architecture depends on how much isolation you need and what latency budget you have.
For most BYOC implementations, the data plane lives entirely within your VPC. Inbound connections from the internet are blocked or minimized. Outbound connections from the agent to the vendor’s control plane use egress through your NAT gateway or VPC endpoints where the vendor has configured PrivateLink. The AWS VPC connectivity guide covers the options in detail, but PrivateLink is almost always the right answer for vendor-to-customer connectivity.
The agent polling pattern is preferred over the vendor pushing connections in, because it keeps your network perimeter clean. The agent maintains a long-lived HTTPS connection to the control plane using WebSockets or HTTP/2 long polling, which the vendor uses to stream instructions without needing to initiate connections into your environment. If the connection drops, the data plane keeps running with its last known configuration until the agent reconnects. This is an important design requirement: the data plane should not require constant connectivity to the control plane to function. Failures in the control plane (outages, networking issues) should degrade gracefully without stopping workloads in your environment.
If the vendor’s product requires the vendor’s cloud and your cloud to exchange data (some analytics products need to run queries that join data from multiple customer tenants), the preferred pattern is PrivateLink: you create a VPC endpoint in your account that connects to the vendor’s endpoint service. Traffic never traverses the public internet. The vendor sees connections from your CIDR space. You see connections to a specific VPC endpoint rather than a generic internet address.
The anti-pattern I see regularly: VPC peering between the vendor’s account and yours. This creates broad Layer 3 connectivity between the accounts. It works, but it violates the principle of limiting the blast radius if either account is compromised. PrivateLink is strongly preferred because it exposes specific services rather than network-level access.
Operational Reality for Vendors Building BYOC
If you’re on the vendor side building BYOC, the hardest problem isn’t the initial architecture. It’s operations in environments you don’t fully control.
Debugging is harder. When something breaks in a customer’s BYOC deployment, you’re operating with limited visibility. Your observability data is whatever the agent streams back. If the agent itself is down, you’re getting signals from a distance. Vendors need an explicit “call home” mechanism that operates even during partial failures, and customers need to understand what observability data the agent streams so they can make an informed decision about what the vendor can see.
Upgrades are complex. In traditional SaaS, you control when every customer gets a new version. In BYOC, you’re pushing upgrades into environments with variable state. Customer A has node groups running a different AMI than customer B. Customer C has network policies that block traffic your new version assumes is allowed. You need a rollout strategy that handles environmental heterogeneity: canary upgrades, rollback capability, pre-upgrade compatibility checks. GitOps with ArgoCD or Flux can help structure this, but the vendor needs to design the upgrade path explicitly. You cannot assume that what works in your staging environment will work in every customer’s production cluster.
Customer error is a real failure mode. The customer controls the IAM roles, the VPC security groups, the Kubernetes node pool size. They can revoke permissions accidentally, delete resources the data plane depends on, or scale node groups to zero during a cost-cutting push. You need graceful degradation and clear error messaging that helps the customer self-diagnose. The agent needs to surface permission errors, resource constraints, and connectivity issues in a way that maps to actionable remediation steps, not opaque error codes.
The cell-based architecture pattern maps directly. Each customer is a cell. The failure domain of one customer’s BYOC deployment is isolated from every other customer’s deployment. Your control plane needs to track the state of each cell independently and avoid shared state between customer deployments. A bug in one customer’s data plane deployment should never cascade to another customer’s environment. This is the same isolation principle that underpins multi-tenancy patterns in traditional SaaS, applied at the cloud account level rather than the namespace or database level.
When BYOC Makes Sense (and When It Doesn’t)
For customers evaluating BYOC options from vendors:
BYOC makes sense when you have active cloud commits that need utilization, when you have data sovereignty requirements that preclude data leaving your account, when you have existing infrastructure (GPU reservations, specific VPC topologies, specific KMS key hierarchies) that the vendor’s managed offering can’t accommodate, or when your security team requires inspection and auditability of all data flow and that’s only feasible in your own account.
BYOC does not make sense when the vendor’s managed offering meets your requirements and the operational overhead of managing another deployment in your account outweighs the cost savings. It also doesn’t make sense when your organization lacks the cloud operations maturity to handle shared responsibility with a vendor. If you don’t have platform engineers who understand IAM, VPC architecture, and Kubernetes node management, BYOC will become a support burden rather than an operational advantage.
For vendors evaluating whether to build BYOC:
BYOC is strategically worthwhile when your target customer segment is regulated enterprises who can’t sign off on managed SaaS, or when your unit economics favor fewer large enterprise customers who will pay a meaningful premium for BYOC over many smaller managed customers who aggregate to a similar number. The operational cost of BYOC is real. You need to build the agent, the upgrade orchestration, the multi-environment observability stack, and the customer support capability for debugging in environments you don’t fully control. Budget 18 to 24 months to get a production-quality BYOC implementation that doesn’t create more problems than it solves.
The space is maturing. Products like Temporal, Airbyte, Supabase, Northflank, and Railway have BYOC implementations that have run in production for multiple years. The patterns are becoming standardized. If you’re building BYOC today, you don’t need to invent the architecture from scratch. Study what’s available publicly about how these products implement cross-account access, upgrade orchestration, and observability before writing your first line of code.
The Compliance Story Is Just Getting Started
Regulatory pressure on data locality is not going away. The EU’s Digital Services Act and AI Act are creating new categories of requirements. India’s Digital Personal Data Protection Act has enforcement teeth. Every jurisdiction wants to know where data is, who can access it, and who is liable if it’s breached.
For a cloud architect, this feels like the early years of GDPR: a lot of scrambling, a lot of “we need to understand what this actually requires,” and then a settling into architectural patterns that become standard. BYOC is one of those patterns. It’s not the only answer to data sovereignty, but it’s a clean answer that lets you tell your regulators: “our data never left our cloud account. Here’s the IAM policy. Here’s the CloudTrail log. Verify it yourself.”
That auditability story is genuinely powerful, and it’s why BYOC keeps growing even as vendors invest in their own sovereignty region strategies. You control the encryption keys, you control the network egress, you control the audit log. The vendor operates the software, but they operate it in a house you own, under rules you set.
If you’re evaluating your SaaS stack and any of your vendors process sensitive data, ask them about BYOC. If they don’t have it, ask when it’s on the roadmap. It’s becoming the question that separates enterprise-grade vendors from vendors who haven’t yet felt the compliance pressure their customers are facing every day.
Get Cloud Architecture Insights
Practical deep dives on infrastructure, security, and scaling. No spam, no fluff.
By subscribing, you agree to receive emails. Unsubscribe anytime.