BYOC and Data-Intensive Apps

For data-intensive applications, deploying inside the customer’s cloud is often financially and technically advantageous, mainly to avoid egress/ingress costs, reduce latency, and meet compliance requirements. When customers host software directly in their own cloud environments however, they often run into a maze of operational complexity.

Example: Avoiding Egress Costs

Take a single enterprise using five data-intensive apps, each moving about 5 TB of data per day.

If these apps run in the vendors’ clouds, that traffic leaves and re-enters the customer’s environment, triggering egress fees (≈ $0.09 / GB on AWS):

• 5 TB/day × 5 apps = 25 TB/day
• 25 TB = 25,000 GB × $0.09 ≈ $2,250/day
• ≈ $68,000/month
• ≈ $820,000/year in egress costs for one customer

Running the same apps inside the customer’s VPC (BYOC) keeps data local, so egress costs drop to nearly zero. While hosting costs shift to the customer’s cloud bill, for large, steady data flows the egress savings typically dwarf the added compute and storage spend. Customers can also leverage negotiated cloud provider agreements to optimize their cloud spend.

Operational Challenges Behind the Savings

But while the cost benefits are clear, running apps inside a customer’s cloud isn’t without its challenges.

Traditional self-hosting demands significant effort to install, configure, and maintain the application — from handling infrastructure provisioning to applying security patches and coordinating upgrades — what we call Day-2 operations.

Even vendors that offer their own Bring Your Own Cloud (BYOC) solutions frequently rely on brittle, cloud-specific integrations. Security may not be first-class using cross-account permissions or other methods. Some lock their deployments to a single cloud provider, limiting customer flexibility.

Nuon’s Secure Runner

Nuon takes a fundamentally better approach: instead of stitching together ad-hoc connections, Nuon deploys a lightweight, secure runner — a VM inside a VPC that the customer automatically creates in the customer’s cloud using a Nuon-generated AWS CloudFormation stack or equivalent. This runner forms a clean, standardized execution environment for the vendor’s software, without the complexity and limitations of legacy BYOC setups.

The runner defines IAM policies and boundaries for different lifecycle operations (provision, maintenance, deprovision, break glass). These are used to control and restrict what actions Nuon can perform in the customer's cloud account during each phase of an app's lifecycle.

Nuon has out-of-the-box Kubernetes configurations called Sandboxes that include a Kyverno admission controller that enforces policies included in an app’s Nuon configuration. e.g., block workloads that do not have resource memory limits specified to protect the health of the cluster or disallow custom snippets in an NGINX Ingress resource.

In addition to the security measures outlined above, the Nuon runner operates with a secure, egress-only connection to Nuon’s control plane, meaning it never requires inbound access from the outside world. Once deployed inside the customer’s VPC, the runner periodically reaches out to Nuon to pull down the deployment instructions defined in the vendor’s app configuration.

These instructions can include provisioning infrastructure components like Kubernetes clusters, ALBs, and certificates; deploying Helm charts to set up databases and application services; and applying Kubernetes manifests to configure secrets and runtime settings.

This pull-based model is both secure and scalable, enabling Nuon to orchestrate complex application deployments inside the customer’s cloud without opening up any inbound network paths.

Every activity performed by the Nuon runner in the customer cloud account is logged and can be shared with the customer.

Islands of Isolated Vendor Deployments

If vendors build their own BYOC offerings, each vendor deployment is isolated with unique Peering/PrivateLink setup, IAM integration, network routing, security groups, and logging, and operational monitoring and upgrade processes.

So if a customer has 5–6 data-intensive vendors, they may end up with 5–6 separate VPC deployments, each with its own network peering and operational quirks. This operational fragmentation leads to customer security teams approving and monitoring each vendor integration separately. Platform teams must manage multiple pipelines for updates, upgrades, and incident response. Data governance teams must track data residency, access and lineage across multiple isolated environments.

This results in a snowballing complexity tax of sorts as the number of vendors for a customer grows.

Customer-Managed Common Landing Zone

Some mature customer platform teams build a shared landing zone architecture for all their vendors, with standardized VPC structure, networking and security baselines, centralized identity and logging, and unified ingress/egress controls. But like with vendors’ islands, these customer-managed landing zones may be specific to one cloud and may not leverage best practices around application deployment and security that purpose-built vendor’s BYOC platform provides.

Nuon BYOC: A Vendor Neutral Control Plane

There is a new category of vendors that act as a control plane for managing multiple private SaaS deployments. Think of them as multi-vendor orchestrators that combine the flexibility and management of SaaS with the data governance and security of deploying apps within a customer’s cloud.

Instead of every software vendor reinventing the wheel with their own deployment scripts, peering configurations, and upgrade pipelines, Nuon provides a standardized orchestration layer that works across vendors. This means customers don’t end up with a sprawl of one-off “private SaaS” setups to manage, and vendors can focus on building great products rather than maintaining brittle infrastructure tooling.

While customer-managed landing zones can standardize security baselines and networking across a customer’s cloud, they still leave each vendor to figure out how to deploy, upgrade, and operate their software within that environment. That usually means every vendor ships its own Terraform modules, Helm charts, or installation guides, and the customer’s platform team ends up acting as a systems integrator — stitching everything together, troubleshooting conflicts, and managing upgrades.

In practice, customer-managed landing zones often end up feeling a lot like old-school self-hosting. The customer becomes responsible for wiring up infrastructure, managing installations, keeping everything patched and upgraded, and troubleshooting vendor-specific quirks — just like they would if they were running the software entirely on their own. It’s a heavy operational lift that distracts platform teams from higher-value work and slows down vendor adoption. Nuon breaks out of this pattern by providing a fully managed control plane for BYOC deployments: vendors get a standardized, automated way to run their software inside the customer’s cloud, and customers get the benefits of self-hosting (control, security, data locality) without the operational burden.

Nuon flips this model: it provides a unified operational layer, for both vendors and customers, that handles provisioning, lifecycle management, and connectivity for all vendors, without requiring the customer to become the deployment expert for each one. This dramatically reduces overhead for customers while giving vendors a consistent, reliable way to offer BYOC.

Nuon: Multi-vendor BYOC

A key strategic angle for Nuon is that the platform is not just a vendor tool but also customer infrastructure for multi-vendor BYOC.

Another powerful use case is when customers themselves adopt Nuon to standardize how third-party software is deployed inside their cloud. Instead of waiting for each vendor to support Nuon or building one-off deployment pipelines, a customer can run Nuon as part of their platform stack and use it to onboard any vendor software in a consistent, secure way.

In this model, vendors don’t even need direct access to Nuon — the customer controls deployments, permissions, and environments, while benefiting from Nuon’s streamlined runner architecture and lifecycle management.

This gives large enterprises a practical way to tame the complexity of multi-vendor BYOC, turning what used to be a fragmented set of installations into a single, repeatable operational pattern.

Like with software vendors, customers can deploy Nuon's control and data planes into their cloud accounts.

Conclusions

Ultimately, Nuon represents a smarter path forward for modern software delivery.

Instead of forcing customers to choose between the complexity of self-hosting, the rigidity of vendor-managed private SaaS, or the heavy lift of maintaining their own landing zones, Nuon provides a clean, standardized control plane for deploying software directly into customer clouds.

Nuon eliminates the sprawl of one-off integrations, simplifies lifecycle management, and preserves the security, compliance, and data-locality benefits enterprises care about most.

Whether adopted by vendors to power their BYOC offerings, or by customers to unify how third-party software runs in their environments, Nuon turns BYOC from a tangle of bespoke setups into a scalable, elegant operating model.

Nuon is the modern foundation for delivering cloud software where it belongs — inside the customer’s cloud, without the operational complexity.