Often, customers have their own AWS VPC or Azure VNet already set up, and would prefer to install BYOC applications there. This guide will walk you through supporting this use-case using app inputs and configurable sandboxes.

​
Installing in a Customer-Provided Network

To enable a customer to install your app in their own network, you need 2 things:

The sandbox can then use those data sources to read the information it needs to provision resources in the customer-provided network.

​
Sandboxes

To give you a head start, we provide managed sandboxes for the most popular platforms. The sandboxes listed here are identical to our turnkey managed sandboxes, except they do not provision network infrastructure of their own and have extra variables for the required network info.

​
AWS EKS BYOVPC

AWS EKS BYOVPC is a sandbox for provisioning an EKS app in a customer-provided VPC. It requires a vpc_id input.

In order for components to work with aws-eks-byovpc sandbox, subnets must be tagged in a way Nuon can look them up.

The eks-byovpc sandbox requires adding a "kubernetes.io/role/internal-elb:1" tag to all private subnets, and a "kubernetes.io/role/elb:1" tag to all public subnets.

​
AWS ECS BYOVPC

AWS ECS BYOVPC is a sandbox for provisioning an ECS app in a customer-provided VPC. It requires a vpc_id app input.

This sandbox also needs to be given private and public subnets to use. There are 2 way to do this:

  1. Tag the public subnets in the target VPC with visibility:public, and the private subnets with visibility:private. This is the default behavior
  2. Define app inputs named private_subnet_ids and public_subnet_ids that each accept a comma-separated string of subnet IDs, and pass them to the sandbox using vars. These will override any tagged subnets that are found.

​
Azure AKS BYOVPN

The Azure AKS BYOVPN sandbox creates an AKS cluster in a customer-provided VPN. It requires resource_group_name, network_name, and subnet_name.

Using VariablesCustom Domains