VPC Tenancy and Cloud Resource Title in BYOC PaaS Deployments

BYOC PaaS runs the application’s data plane in the customer’s own cloud account while the vendor manages the software through a separate control plane. For teams choosing a PaaS that deploys into their own AWS, GCP, or Azure account, two questions decide what they control. VPC tenancy defines the network boundary, while cloud resource title determines who owns the infrastructure and what remains after the vendor relationship ends.

What BYOC actually means — the architectural split between control plane and data plane

The control plane runs on the vendor’s infrastructure and handles orchestration, including builds, routing, scaling decisions, upgrades, and monitoring. The data plane runs in the customer’s environment, where the application processes its data. The two planes communicate through a secure channel. That connection is the first boundary to understand. Application data can stay in the account even when the management service runs outside it.

In well-designed implementations, an agent inside the customer’s VPC polls the control plane through an outbound-only connection. A pull-based management component can fetch a document that describes how the cluster should be set up without giving the control plane standing credentials or more permissions than it needs. But this is an implementation choice.

Traversal states the practical test directly, asking whether the vendor can see the data payload. If VPC peering sends application traffic through a vendor-hosted load balancer before reaching the customer’s environment, that is SaaS with a private connection.

BYOC also differs from self-hosting in who operates the software. In self-hosted deployments, the customer handles updates, patching, scaling, and incident response. Under BYOC, the vendor still runs the software, and the customer supplies the infrastructure.

VPC tenancy and resource title are distinct concepts that teams routinely conflate

VPC tenancy describes the network boundary around a workload. Single tenancy gives one customer an environment of its own, with capacity it can count on and control over that environment. Multi-tenancy shares an environment across customers to lower costs and simplify centralized operations. That makes it crucial to get authorization, data separation, quotas, and deployment discipline right. A failure in those controls can affect other customers sharing the environment.

Resource title answers a different question about ownership. It identifies who owns the VPCs, managed Kubernetes clusters, load balancers, databases, IAM roles, and storage buckets that make up production. On a rented PaaS, the vendor holds title to those resources. The customer has a tenancy. A private network does not change that ownership.

Single-tenant SaaS is where the distinction often gets lost. A vendor can give a customer dedicated infrastructure in its own cloud account. The customer gets isolation but not resource title, because the software and data still run under the vendor’s account. Owning resources also does not, on its own, give workloads a dedicated network boundary.

Convox’s BYOC explanation describes provisioning standard cloud resources in the customer’s account, where they remain after the customer stops using the platform. The customer holds both the resources and the network boundary, so its isolation is within its own infrastructure.

What resource title determines when a vendor relationship ends

On shared-tenant PaaS, the vendor provisions, bills, and controls the production environment. When the relationship ends, that tenancy ends too. To leave, the team must rebuild the environment elsewhere as well as replace the tool that manages it. Resource title makes this both an operational and a contractual distinction. The departing team does not own the infrastructure it has been using.

Under account-based BYOC, the VPCs, clusters, databases, and load balancers remain in the customer’s account and stay accessible. What disappears is the vendor’s management layer. Losing that layer can still be painful. However, standard cloud-provider resources can be operated by another tool, team, or platform, so the transition starts from an existing environment.

The team still needs to establish whether it can reconstruct operational state independently. Even when application records stay inside the account, operational metadata can travel back to the control plane. That metadata may include topic names, partition counts, resource IDs, bucket names and sizes, timestamps, and consumer group offsets. Its location deserves attention during exit planning. A running cluster and access to its databases are not a complete answer if the team cannot determine how the environment was being managed.

How VPC tenancy shapes compliance scope, and why shared-tenant PaaS creates the harder audit problem

Resource title affects how a team plans to leave, while tenancy sets the boundary an auditor must check. On shared-tenant PaaS, compliance scope can reach into infrastructure that the customer does not own or control. Producing evidence then depends on the vendor’s systems and cooperation. The customer must demonstrate controls over an environment it cannot directly govern.

HIPAA and GDPR assessments raise questions about where data lives and how its processing environment is controlled. SOC 2 focuses on demonstrable controls but does not mandate data location. Under BYOC, the customer can use the audit logging, network policies, and encryption standards it already has directly on the platform’s infrastructure. The customer’s cloud BAA also becomes relevant to that deployment. These are controls the team can inspect rather than assurances about an inaccessible environment.

For sensitive inference workloads, provider agreements remain essential. As of April 2026, AWS, GCP, Azure, and CoreWeave are among the major GPU cloud providers offering HIPAA BAAs, with RunPod also offering BAAs. HIPAA requires appropriate safeguards, a signed BAA, and a documented risk analysis regardless of the deployment model.

Residency describes where servers and data sit, while sovereignty concerns the laws that may apply to data and providers. Traversal identifies the US CLOUD Act (2018) as a jurisdictional complication because US law enforcement can compel data from US-jurisdiction providers even when it is stored in the EU. The chosen region is therefore only part of the legal boundary.

What BYOC does not guarantee, and where account ownership alone falls short

Owning the account does not automatically make the architecture secure, sovereign, or compliant. The vendor still operates a control plane containing the UI, API, scheduler, upgrade machinery, and monitoring. That creates a shared trust boundary across two environments. Its permissions need scrutiny. The location of the data plane cannot settle what the vendor can access or change.

The first audit target should be the vendor’s IAM permissions. A standing role with wildcard-scoped permissions is a risk to document and remediate, while a role limited to resources the vendor created is a sounder boundary. Buyers should also check what write access and inbound connectivity the vendor needs. Outbound-only polling and broad cross-account permissions are not equivalent arrangements. Both can appear under a BYOC label.

Operational metadata may show topic names, file details, timestamps, and offsets even when record keys and contents stay inside the account. Buyers need to establish exactly what crosses the boundary.

Operations also become a shared responsibility in practice. Customers take on the cloud bill, cross-availability-zone egress, IAM setup, upgrade coordination, and on-call work spanning both environments. Upgrades originate with the vendor but must fit the customer’s maintenance windows and policy approvals. Whether a control-plane outage blocks new resources while existing processing continues depends on how the system is built. That behavior belongs in the on-call runbook.

What the cost structure of BYOC actually looks like compared to shared-tenant PaaS

At modest compute spend, shared-tenant PaaS pricing can be acceptable. Its infrastructure markup may not yet justify the customer-side work of BYOC. Above a certain monthly threshold, however, the gap between PaaS pricing and cloud-direct pricing can become a meaningful fraction of the bill. The crossover depends on the workload and operating burden. It is a calculation for the team’s environment.

Rented platforms mark up compute and meter bandwidth at their own rates. Under BYOC, infrastructure is billed through the customer’s cloud account, with software billed separately by the vendor. Traffic egresses at cloud-provider prices. The platform’s infrastructure can therefore use committed-use discounts, reserved instances, and startup credits that apply to it. AWS Activate and Google for Startups are relevant credit programs.

For GPU-intensive AI workloads, the economic difference can be larger. High-volume inference on private cloud can cost substantially less than commercial API list prices. But those prices are not the entire comparison. Dedicated single-tenant deployments usually cost more per customer than multi-tenant ones, and BYOC gives the customer more work to do on IAM, upgrades, and incidents. The useful comparison is total cost of ownership, including cloud charges, egress, software fees, and operating time. Where compliance, residency, or reliability requires isolation, that expense may be obligatory.

BYOC variants and what each one actually gives a team control over

BYOC-Account puts provisioning inside a customer-owned cloud account and comes closest to full resource title. BYOC-VPC adds private network integration to an account that the vendor may still run. BYOC-K8s delivers the software into a customer-controlled Kubernetes cluster. These variants grant different kinds of control. A team that wants Kubernetes in its own GCP or Azure subscription needs clear account and cluster boundaries as well as a promise of private networking.

Air-gapped delivery goes further by removing the live connection to the vendor, with greater isolation and greater operational friction. It is distinct from the ongoing managed-service relationship in BYOC. Traditional SaaS runs in the vendor’s cloud with shared tenancy, while single-tenant SaaS adds dedicated resources whose title stays with the vendor. Self-hosting puts both infrastructure and operations on the customer. These distinctions are more useful than treating every private deployment as the same product category.

Restate’s July 7, 2026 announcement provides a concrete implementation example for AWS and GCP, with Azure support in preview. Its Terraform template provisions a dedicated VPC and a lightweight runner that polls Restate Cloud through an egress-only connection. But the control plane also connects inbound to the customer’s Kubernetes API to manage environments. The architecture is not wholly outbound-only. Restate Cloud gets system metrics and keeps limited access for upgrades and monitoring, but its operators cannot access application data. The service is initially available on request, with public signup expected in coming months.

An outbound-only runner describes how one component communicates. A Terraform-provisioned stack and a cross-account IAM role assumed by the vendor may both be called BYOC, but they create different trust boundaries and audit requirements.

How do you evaluate a PaaS that deploys into your own AWS, GCP, or Azure account?

The evaluation should start with ownership. Do the VPCs, clusters, load balancers, and databases provision into the customer’s account, and do they remain after cancellation? Can another team operate them without the vendor’s control plane? Persistence and independence are separate tests. To make the move, the team must both replace management and recover the operational state it needs to use it.

The next questions concern access and evidence. Buyers should get the vendor’s permission scope in writing, establish whether every connection is outbound-only, and distinguish payload access from operational metadata. Can the team produce audit evidence from resources governed by its own IAM policies in its chosen region? Or does part of the audit still depend on vendor-controlled infrastructure? For AI workloads, the evaluation also needs GPU support and residency commitments suited to the workload. Where HIPAA applies, buyers should confirm BAA availability with the underlying cloud provider rather than treating the platform vendor’s assurances as a substitute.

Cost then determines when the operating model becomes practical. The team should compare monthly compute spend, the commitments and credits it can use, software charges, and the work it must do to run the system. Shared-tenant PaaS can be enough when compute spend is still low and there are no strict residency requirements or compliance obligations that call for account-level control. Dedicated infrastructure is not automatically the better choice. When a team must directly control its processing environment and keep it after vendor exit, however, it needs VPC tenancy and resource title in its own account.