BYOC Anywhere: Het Spectrum van Bring Your Own Cloud-implementaties

In het klassieke SaaS-model host de leverancier de applicatie, het data plane, de infrastructuur, netwerkinrichting en operaties in zijn eigen cloudaccount. Bij BYOC (Bring Your Own Cloud) verschuift deze grens: de klant behoudt de workload, data, netwerkcontroles, auditlogs en vaak ook de facturering binnen zijn eigen cloudomgeving, terwijl de leverancier nog steeds een beheerde productervaring biedt. Deze definitie is een goed begin, maar is onvolledig.

In de praktijk betekent BYOC niet altijd "geef de leverancier een nieuw cloudaccount en laat hen uitrollen". Ondernemingen, gereguleerde organisaties, AI-infrastructuurteams en platform engineering-groepen hebben allemaal verschillende beperkingen. Sommigen kunnen een toegewezen account verstrekken; anderen eisen implementatie in een bestaande VPC; sommigen staan workloads alleen toe op goedgekeurde Kubernetes-clusters; en sommigen mogen helemaal geen internetverbinding toestaan.

Daarom is BYOC beter te begrijpen als een spectrum van implementatie- en operationele modellen:

1. Vendor SaaS
2. BYOC-Account
3. BYOC-VPC
4. BYOC-K8s
5. Air-gapped / disconnected

Het kernpunt is dat BYOC Anywhere niet alleen gaat over waar de infrastructuur staat. Het gaat over het vermogen om software te leveren, te beveiligen, te exploiteren, te meteren, te upgraden, te observeren en te beheren over vele door de klant gecontroleerde omgevingen heen.

Waarom klanten verschillende BYOC-varianten nodig hebben

Klanten vragen om BYOC om verschillende redenen, die vaak samen komen:

• Dataresidentie en soevereiniteit: Data moet in een specifieke regio, account, cloud of jurisdictie blijven.
• Beheersing van beveiliging: Behoefte aan private netwerken, door de klant beheerde sleutels (customer-owned keys), auditlogs, geen toegang van de leverancier tot ruwe data en handhaving van beleid via eigen identiteits- en governancesystemen.
• Commerciële afstemming: Klanten hebben vaak al vaste clouduitgaven, gereserveerde capaciteit, GPU-reserveringen of interne chargeback-modellen. Software in hun eigen account draaien helpt hen deze verplichtingen te benutten in plaats van dubbel te betalen.
• Datagravitatie: Voor AI- en data-intensieve workloads kan het verplaatsen van grote volumes logs, embeddings, modeloutputs, bestanden of telemetrie naar een SaaS-omgeving van een leverancier duur zijn, traag verlopen of verboden zijn. BYOC houdt de rekenkracht dicht bij de data.
• Standaardisatie door platformteams: Teams maken vaak al gebruik van goedgekeurde VPC-patronen, Kubernetes-clusters, service meshes, secrets managers, CI/CD-systemen en observability-stacks. Een leverancier die niet in deze patronen past, zorgt voor operationele frictie.
• Gereguleerde omgevingen: Soms is een disconnected of air-gapped levering vereist, waarbij software-updates, container-images, licenties en telemetrie geen live internettoegang mogen hebben. Deze omgevingen vereisen offline update-workflows, gespiegelde repositories en gecontroleerde processen voor het overdragen van artefacten (zie bijvoorbeeld de documentatie over air-gapped systemen van Ubuntu).

De vier belangrijkste BYOC-varianten

1. BYOC-Account (Bring your own Cloud Account)

Dit is het meest voorkomende model. De klant maakt een toegewezen cloudaccount, project of abonnement aan. De leverancier implementeert het data plane in die omgeving, meestal via beperkte IAM-rollen en de installatie van een agent die de rest automatiseert (of handmatig via Terraform, CloudFormation of specifieke scripts).

Vanuit het perspectief van de klant ziet dit proces er als volgt uit:

1. Account aanmaken
2. IAM-rol goedkeuren
3. Leverancier implementeert
4. Service draait in de cloud van de klant

Dit model werkt goed wanneer de klant volledige isolatie wil zonder dat de leverancier bij elk detail van het bestaande netwerk betrokken hoeft te zijn. De klant is eigenaar van de accountgrenzen, facturering, cloudlogs, regiokeuze en vele beleidscontroles. De leverancier beheert de productlevenscyclus: implementatie, schaling, health checks, upgrades en ondersteuning.

2. BYOC-VPC (Bring your own VPC)

BYOC-VPC gaat een stap verder: de software moet draaien binnen een door de klant goedgekeurde netwerkgrens. In plaats van simpelweg in een nieuw account te implementeren, moet de leverancier integreren met een bestaande VPC, VNet, subnet-indeling, routeringsmodel, DNS-instellingen, firewallbeleid, private endpoints en egress-controles.

Vanuit het perspectief van de klant ziet dit proces er als volgt uit:

1. VPC / subnets verstrekken
2. Routes, endpoints en security groups goedkeuren
3. Privé implementeren

Dit is essentieel wanneer klanten eisen dat er geen publieke endpoints zijn, er privéverbindingen naar interne systemen zijn, er egress allowlists gelden of er gebruik wordt gemaakt van centrale firewall-inspectie en interne DNS/certificaatpolicies. Voorbeelden hiervan zijn diensten zoals AWS PrivateLink, waarmee klanten privé verbinding kunnen maken met services zonder publieke IP's of internetgateways (zie AWS PrivateLink).

3. BYOC-K8s (Bring your own Kubernetes)

Bij BYOC-K8s levert de klant de Kubernetes-runtime. De leverancier implementeert in een door de klant beheerd Kubernetes-cluster, vaak via Helm charts, operators, controllers, CRD's, namespaces, service accounts en container-images.

Vanuit het perspectief van de klant ziet dit proces er als volgt uit:

1. Cluster verstrekken
2. Helm / operator installeren
3. Licentie / control plane verbinden
4. Workloads beheren

Dit model is gebruikelijk wanneer klanten standaardiseren op Kubernetes over verschillende clouds, on-premise of edge-omgevingen. Kubernetes dient hierbij als een portable abstractielaag voor multi-environment levering.

Platformteams hebben hiermee meer controle over admission policies, image scanners, secrets management en GPU-scheduling. Echter, het verantwoordingsmodel verandert: de leverancier beheert niet langer de volledige onderlaag. Variaties in clusterversies, CNI-gedrag en storage drivers vereisen nauwe coördinatie met het platformteam van de klant.

4. Air-gapped Software Distribution

Air-gapped is strikt genomen geen BYOC, maar een natuurlijke uitbreiding van hetzelfde spectrum. De software draait in een omgeving zonder directe internetverbinding, vaak vanwege defensie, publieke sector of kritieke infrastructuur.

Vanuit het perspectief van de klant ziet dit proces er als volgt uit:

1. Ondertekende artefacten ontvangen
2. Scannen / goedkeuren (supply chain)
3. Offline importeren
4. Lokaal installeren / upgraden

Hierbij kan de leverancier geen gebruik maken van live telemetrie, remote debugging of automatische image-pulls. Updates en patches moeten worden gespiegeld of via gecontroleerde processen naar de omgeving worden overgebracht (zie bijvoorbeeld highly secure air-gapped Ubuntu architectures).

Koppeling tussen klantbehoeften en BYOC-varianten

Klantbehoefte	Best passende variant	Waarom dit helpt
Gebruik van gereserveerde cloud-spend	BYOC-Account	Workloads vallen onder de facturering van de klant.
Minimaliseren van toegang leverancier	BYOC-Account / VPC	Vereist beperkte rechten, auditbaarheid en zero-trust controles.
Data in door klant beheerde cloud houden	BYOC-Account / VPC	Het dataplane blijft binnen de grens van de klant.
Integratie met klant supply chain	BYOC-Account / VPC	Maakt image scanning, artifact signing en private registries mogelijk.
Afdwingen van privénetwerken	BYOC-VPC	Ondersteunt privéroutes, endpoints, DNS en egress-controles.
Hergebruik interne platformstandaarden	BYOC-K8s	Draait op goedgekeurde clusters, policies en tooling.
Ondersteuning voor on-prem of edge	BYOC-K8s / Air-gapped	Kubernetes of offline bundles kunnen non-cloud omgevingen beslaan.
Voldoen aan strikte soevereiniteit/geheimhouding	Air-gapped	Verwijdert afhankelijkheid van live externe connectiviteit.

De beveiligingsuitdaging: Secure by Design

Een serieus BYOC-platform moet meer implementeren dan alleen automatiseringsscripts; het moet voldoen aan de beveiligingsnormen van moderne ondernemingen:

• Least-privilege permissies: De leverancier krijgt alleen de rechten die strikt noodzakelijk zijn voor installatie, beheer en observatie.
• End-to-end encryptie: Data moet versleuteld zijn tijdens transport en in rust, bij voorkeur met door de klant beheerde sleutels.
• Zero-inbound toegang: Veel klanten staan geen inkomende toegang vanuit het netwerk van de leverancier toe. Een veiliger patroon is een outbound-only agent die vanuit de omgeving van de klant wordt gestart.
• Egress allowlists: Klanten moeten precies weten welke domeinen, API's en endpoints het product nodig heeft.
• Privéconnectiviteit: Ondersteuning voor Private Link, VPC endpoints of VPN in plaats van publiek internet.
• Integratie met supply chain: Images, SBOM's and signatures moeten passen in de goedkeuringsworkflows van de klant.
• Governance en auditbaarheid: Toegang tot logs, wijzigingshistorie en duidelijke eigendomsgrenzen.

Dit sluit aan bij het zero-trust-principe: geen enkele gebruiker of workload krijgt impliciet vertrouwen enkel omdat deze zich binnen een perimeter bevindt (zie NIST SP 800-207 Zero Trust Architecture).

De portabiliteitsuitdaging: Werken in elke omgeving

Een beperkt BYOC-product werkt wellicht alleen in AWS of met publieke egress, maar dat is niet enterprise-ready. Echte portabiliteit betekent werken over:

• Grote clouds (AWS, Azure, Google Cloud).
• Sovereign cloud regio's.
• Neocloud en GPU cloud providers.
• Klantbeheerde Kubernetes (inclusief OpenShift).
• On-premise datacenters en edge-omgevingen.
• Internetbeperkte en air-gapped netwerken.

Elke omgeving verandert de aannames over identiteit, netwerken, storage en DNS. De architectuur moet deze verschillen isoleren achter een consistent leveringsmodel.

De operationele uitdaging: Beheerde service na implementatie (Day 2)

Het moeilijkste deel van BYOC is niet de eerste dag (Day 1), maar het beheer daarna (Day 2). Een echt platform moet de volledige levenscyclus afhandelen: Provision → Deploy → Configure → Govern → Upgrade → Meter → Observe → Operate.

Dit vereist oplossingen voor:

• Infrastructuurbeheer: Consistente IaC over diverse omgevingen. Tools zoals Terraform schieten hier vaak tekort en vereisen een BYOC-control plane om tenant-bewust en transactieveilig te werken.
• Governance: Break-glass procedures, RBAC, SSO en integratie met enterprise IdP's.
• Upgrades en patches: Veilige rollouts, rollback-mogelijkheden en beheer van configuratie-drift.
• Metering en facturering: Verzamelen van verbruik en integratie met payment processors of cloud marketplaces.
• Licentiëring: Online activatie voor verbonden omgevingen; ondertekende offline licenties voor air-gapped omgevingen.
• Observability: Health checks, logs en metrics zonder klantdata te lekken.
• Day-2 automatisering: Backups, certificaatrotatie, failover en compliance bewijsvoering.

Dit creëert een shared responsibility model: de klant is eigenaar van de omgeving, terwijl de leverancier een beheerde productervaring moet blijven leveren (vergelijkbaar met het AWS shared responsibility model).

Conclusie: BYOC is een Productarchitectuur, geen Implementatiescript

Een eenvoudige BYOC-demo ziet er makkelijk uit: verbind met een account, draai Terraform en start containers. Production-grade BYOC is echter een complex architecturaal vraagstuk. Het vereist een control plane die geïsoleerde omgevingen kan beheren zonder overmatige rechten te claimen, agents die met minimale permissies werken en een robuuste orkestratie van upgrades en observatie.

BYOC is niet slechts één manier van implementeren, maar een spectrum:

• BYOC-Account voor helder cloud-eigendom.
• BYOC-VPC voor integratie in private netwerken.
• BYOC-K8s voor gestandaardiseerde runtime-levering.
• Air-gapped voor hooggevoelige, gedisconnecteerde omgevingen.

De belofte van BYOC Anywhere is dat klanten de volledige controle behouden over hun infrastructuur, data en compliance, terwijl ze toch kunnen genieten van de voordelen van een managed service. Dit is de volgende evolutie in de levering van enterprise software.