BYOC Anywhere: The Spectrum of Bring Your Own Cloud Deployments

In the classic SaaS model, the vendor hosts the application, data plane, infrastructure, networking, and operations in its own cloud account. In BYOC (Bring Your Own Cloud), that boundary shifts: the customer keeps the workload, data, network controls, audit logs, and often billing inside their own cloud estate, while the vendor still provides a managed product experience. That definition is a good start, but it is incomplete. In practice, BYOC does not always mean "give the vendor a fresh cloud account and let them deploy." Enterprises, regulated organizations, AI infrastructure teams, and platform engineering groups all have different constraints. Some can provide a dedicated account. Some require deployment into an existing VPC. Some only allow workloads onto approved Kubernetes clusters. Some cannot allow any internet connectivity at all. That is why BYOC is better understood as a spectrum of deployment and operating models. 1Vendor SaaS2BYOC-Account3BYOC-VPC4BYOC-K8s5Air-gapped / disconnected The deeper point: BYOC Anywhere is not just infrastructure placement. It is the ability to deliver, secure, operate, meter, upgrade, observe, and govern software across many customer-controlled environments. Why customers need different BYOC flavors Customers ask for BYOC for different reasons, and those reasons often compound. Some want data residency and sovereignty: data must stay in a specific region, account, cloud, or jurisdiction. Others want security control: private networking, customer-owned keys, audit logs, no vendor access to raw data, and policy enforcement through their own identity and governance systems. Some buyers care about commercial alignment. They already have committed cloud spend, reserved capacity, GPU reservations, or internal chargeback models. Running software in their own account helps them use those commitments instead of paying twice. For AI and data-heavy workloads, the reason is often data gravity. Moving large volumes of logs, embeddings, model outputs, files, or telemetry into a vendor SaaS environment can be expensive, slow, or prohibited. BYOC keeps compute closer to the data. Platform teams may also require standardization. They already run approved VPC patterns, Kubernetes clusters, service meshes, secrets managers, CI/CD systems, observability stacks, and supply-chain scanning. A vendor that cannot fit into those patterns creates operational friction. Finally, regulated environments may require disconnected or air-gapped delivery, where software updates, container images, licenses, and telemetry cannot assume live internet access. Air-gapped environments require offline update workflows, mirrored repositories, and controlled artifact transfer processes. (Ubuntu's air-gapped system documentation) The four main BYOC variants 1. BYOC-Account (Bring your own Cloud Account) Figure 1: A standard BYOC-Account deployment model. BYOC-Account is the most common mental model. The customer creates a dedicated cloud account, project, or subscription. The vendor deploys its data plane into that environment, usually through scoped IAM roles and deploying an agent that automates the rest (or manually through a bunch of Terraform, CloudFormation, one-off installers/scripts). From the customer's perspective, this model feels like: 1Create account2Approve IAM role3Vendor deploys4Service runs in customer cloud This flavor works well when the customer wants clean isolation without forcing the vendor into every detail of their existing network. The customer owns the account boundary, billing, cloud logs, region choice, and many policy controls. The vendor owns the product lifecycle: deployment, scaling, health checks, upgrades, and support. BYOC-Account is often the right starting point because it creates a strong separation of concerns. But it is not enough for customers with strict networking, routing, private endpoint, or internal platform requirements. 2. BYOC-VPC (Bring your own VPC) Figure 2: A secure BYOC-VPC deployment with a customer-approved network boundary. BYOC-VPC goes one level deeper: the software must run inside a customer-approved network boundary. Instead of simply deploying into a fresh account, the vendor must integrate with an existing VPC, VNet, subnet layout, routing model, DNS setup, firewall policy, private endpoints, and egress controls. From the customer's perspective, this model feels like: 1Provide VPC / subnets2Approve routes, endpoints, and security groups3Deploy privately This is important when customers require: No public endpoints. Private connectivity to internal systems. Egress allowlists. PrivateLink-style connectivity. Centralized firewall inspection. Internal DNS and certificate policies. Existing network segmentation. For example, private connectivity services such as AWS PrivateLink are designed to let customers connect privately to services without requiring public IPs, internet gateways, NAT devices, or public routing paths. (AWS PrivateLink) BYOC-VPC is more demanding than BYOC-Account because the deployment has to respect the customer's network architecture across clouds. The vendor cannot assume open outbound internet, default DNS, permissive security groups, or vendor-managed ingress. 3. BYOC-K8s (Bring your own Kubernetes) Figure 3: A standardized BYOC-K8s deployment within a customer-managed Kubernetes runtime. BYOC-K8s means the customer provides the Kubernetes runtime. The vendor deploys into a customer-managed Kubernetes cluster, often through Helm charts, operators, controllers, CRDs, namespaces, service accounts, and container images. From the customer's perspective, this model feels like: 1Provide cluster2Install Helm / operator3Connect license / control plane4Operate workloads This flavor is common when customers already standardize around Kubernetes across clouds, on-prem, edge, or GPU infrastructure. Kubernetes is explicitly designed as a portable, extensible platform for managing containerized workloads and services, which makes it a natural abstraction layer for multi-environment delivery. (Kubernetes for multi-environment delivery) BYOC-K8s gives platform teams more control. They can enforce their own admission policies, image scanners, secrets management, storage classes, ingress controllers, service mesh rules, node pools, GPU scheduling, and observability integrations. But it also changes the responsibility model. The vendor no longer controls the full substrate. Cluster version, CNI behavior, storage drivers, node autoscaling, resource quotas, pod security settings, and image registry access can vary widely. The vendor also does not provision the underlying infrastructure, so infra provisioning, sizing, upgrades, and troubleshooting often require coordination with the customer's platform team. This is especially challenging in traditional on-premises environments, where hardware, networking, and storage abstractions vary significantly. 4. Air-gapped Software Distribution Figure 4: A highly secure air-gapped deployment with customer-controlled offline distribution. Air-gapped is not exactly BYOC, but it is a natural extension of the same customer-controlled delivery spectrum. In this model, the software runs in an environment with no direct internet connectivity, often for defense, public sector, critical infrastructure, financial services, healthcare, or sovereignty reasons. From the customer's perspective, this model feels like: 1Receive signed artifacts2Scan / approve (supply chain)3Import offline4Install / upgrade locally Air-gapped delivery requires a different operating model. The vendor cannot assume live telemetry, remote debugging, online license checks, automatic image pulls, hosted package repositories, or continuous control-plane access. Updates, patches, container images, dependency repositories, and documentation often need to be mirrored or transferred into the environment through controlled processes. (Highly secure, air-gapped Ubuntu architectures) This is where the BYOC idea reaches its hardest form: the customer owns not only the infrastructure boundary, but also the connectivity boundary, update boundary, support boundary, and operational evidence boundary. How each flavor maps to customer needs Customer needBest-fit BYOC flavorWhy it helpsUse committed cloud spendBYOC-AccountWorkloads run under customer billing.Minimize vendor accessBYOC-Account / VPCRequires scoped permissions, auditability, governance and zero-trust controls.Keep data in customer-controlled cloudBYOC-Account / VPCDataplane stays inside the customer boundary.Integrate with customer supply chainBYOC-Account / VPCEnables image scanning, artifact signing, private registries, and approvals.Enforce private networkingBYOC-VPCSupports private routes, endpoints, DNS, e2e encryption and egress controls.Reuse internal platform standardsBYOC-K8sRuns on approved clusters, policies, and tooling.Support on-prem or edgeBYOC-K8s / Air-gappedKubernetes or offline bundles can span non-cloud environments.Meet strict sovereignty or classified requirementsAir-gappedRemoves dependency on live external connectivity. The Security Challenge: BYOC must be secure by design A serious BYOC platform has to implement more than deployment automation. It has to deliver the security posture enterprises expect from modern infrastructure. That includes: Least-privilege permissions. The vendor should receive only the permissions required to install, operate, update, and observe the product. Permissions should be scoped by account, project, namespace, resource type, and lifecycle phase. End-to-end encryption. Data should be encrypted in transit and at rest, with clear support for customer-managed keys where required. Zero-inbound access. Many customers will not allow inbound access from a vendor network. The safer pattern is often an outbound-only agent or runner initiated from the customer environment.