Documentation

Support

Unity Cloud

Get Started

Creator SDKs and Services

Open Unity Dashboard

Unity Cloud

Prerequisites

Before you deploy Unity Virtual Private Cloud to Microsoft Azure
Read time 5 minutesLast updated 4 days ago
To deploy Unity Cloud Services to Microsoft Azure, you must have an Azure account and a role with sufficient permissions to create and manage resources. Before you start deploying Virtual Private Cloud, complete the following steps.

1. Prepare deployment on Unity's side

Perform these steps on Unity's side:
  1. Collect the username and the password for the central Azure Container Registry (ACR) that is managed by Unity.
  2. Collect the .xml files that contain the Unity Asset Transformer SDK licenses. These licenses are required for all users who are to perform asset transformations:
    • A valid Unity Asset Transformer license.
    • A floating license server. To set up the license server, refer to these instructions.
  3. Request the Unity team to add the target customer subscription to the allowlist in the relevant private plan properties. The reason is that the solution is currently available only through a private plan in Azure Marketplace.

2. Prepare deployment on the client's side

Perform these steps on the client's side:

2.1 Prepare the project name prefix

Prepare the project name prefix with these characteristics:
  • The prefix is a string.
  • The prefix contains at most six characters.
  • The prefix contains only lowercase alphanumeric characters, but no underscores or dashes.

2.2 Collect an IP range for the virtual network

For the full deployment mode

If you chose the full deployment mode, collect an IP range for the virtual network (VNet) that hosts the solution. The recommended size of the VNet is /21. From that range, a subnet of /22 in size is dedicated to the Azure Kubernetes Service (AKS) cluster, to provide enough address space for the pods. If the solution VNet is to be connected to the corporate network, then this range must not overlap with any other ranges of the customer environment where clients will reside. Subsequently, you can peer this VNet with the hub and route it to or from the corporate network.

For the BYO VNet mode

If you chose the BYO VNet mode, collect the IP range of the precreated VNet that is to host the solution. The IP size of the VNet must be /21. If the solution VNet is to be connected to the corporate network, then this range must not overlap with any other ranges of the customer environment where clients reside. This VNet must contain these subnets:

Subnet

IP range size

Description

aks-snet
/22
Enable the service endpoints for these resource types:
  • Microsoft.Storage
  • Microsoft.ServiceBus
postgres-snet
/24
Delegate this subnet to this resource type: Microsoft.DBforPostgreSQL/flexibleServers. Enable the service endpoints for this resource type: Microsoft.Storage.
private-endpoints-snet
/24
If required for network security groups (NSGs) and route tables, enable the network policy for private endpoints.
cont-ins-snet
/24
Delegate this subnet to this resource type: Microsoft.ContainerInstance/containerGroups. Enable service endpoints for this resource type: Microsoft.Storage.
For the service principal 
Managed Applications On Behalf Application
, which is owned by Microsoft, assign the following roles to the resource group where the VNet, NSGs, and route tables reside:
  • Network Contributor
  • User Access Administrator, with the option Allow user to assign all roles except privileged administrator roles
After deployment completion, you can remove these role assignments.

2.3 Collect the IP ranges for the pods and services

Collect the IP ranges for the pods and services, in Classless Inter-Domain Routing ranges (CIDR) notation. The offer UI requests only the network addresses. The network masks are hard-coded:
  • /16 for pods
  • /22 for services
If the solution VNet is to be connected to the corporate network, then these ranges must not overlap with any other ranges of the customer environment where clients will reside. These IP ranges are set by default:
  • 172.29.0.0/16 for pods
  • 172.28.0.0/22 for services

2.4 Collect the fully qualified domain name

Collect the fully qualified domain name (FQDN) of the domain to be used to access Virtual Private Cloud. After deployment, the relevant DNS record is created in the internal DNS. Read more about postdeployment.

2.5 Prepare the TLS certificate and the private key

Collect the following information in .pem format:
  • A TLS certificate for the selected domain name, and issued by a certification authority (CA) that is trusted by the clients who access Virtual Private Cloud
  • The corresponding private key

2.6 Prepare the MongoDB instance

Prepare a MongoDB instance that can host Virtual Private Cloud databases and that is managed by one of these entities:
  • A cloud provider that is, for example, hosted in MongoDB Atlas
  • The customer, in which case the instance can run in their Azure environment
You can deploy Virtual Private Cloud even if this MongoDB instance isn't accessible at the time of deployment. For example, the instance might be running in another Azure VNet that can't be peered with the solution VNet until the latter is created. However, Virtual Private Cloud doesn't fully initialize until the MongoDB instance is made accessible from the solution VNet. In this case, consider these options:
  • Use a MongoDB Atlas cluster, or a publicly available cluster, that meets one of these requirements:
    • The cluster is initially accessible from any IP. The reason is that the outbound IPs of the Virtual Private Cloud solution are unknown until deployment. After you have deployed the solution, configure more specific access to the network.
    • The cluster is initially restricted to the administrators' IPs. In this case, you can deploy the solution, but it won't be operational until it can access the MongoDB cluster. Configure the MongoDB cluster so that the solution AKS cluster can access it after deployment.
  • Use an internally deployed MongoDB cluster, for example, one that is deployed in another Azure VNet, and connect it to the solution VNet after deployment, for example, by directly peering VNets. This option is similar to the previous option in terms of enabling access to MongoDB after deployment. This approach also applies when utilizing MongoDB Atlas with network peering. Read more about network peering in the Mongo DB documentation.
  • If you use an internally deployed MongoDB, it is accessible through its internal DNS name rather than by its private IP address. This name must be resolvable from the solution VNet. This requirement might require additional configuration.
Performance characteristics of the MongoDB cluster must match the M30 tier in MongoDB Atlas with 128 GB of storage. Its region must match, or be as close as possible to, the region where Virtual Private Cloud solution is deployed. This requirement is to avoid database latency issues. To run deployment, you need the connection string of the MongoDB instance, even if the instance isn't accessible at the time of deployment.

2.7 Prepare the Azure subscription

Prepare your Azure subscription for deployment:
  1. Adjust the resource quotas. Read more about deployment size in the deployment procedure.
  2. Register the following resource providers for the subscription if they haven't yet been automatically registered during subscription provisioning:
    • Microsoft.Network
    • Microsoft.Storage
    • Microsoft.KeyVault
    • Microsoft.ManagedIdentity
    • Microsoft.Cache
    • Microsoft.ContainerService
    • Microsoft.KubernetesConfiguration
    • Microsoft.DBforPostgreSQL
    • Microsoft.EventGrid
    • Microsoft.EventHub
    • Microsoft.Insights
    • Microsoft.OperationalInsights
    • Microsoft.ServiceBus
The recommended practice is to assign the following roles to Virtual Private Cloud administrators for the subscription for which the solution is to be deployed:
  • The Azure Kubernetes Service RBAC Cluster Admin role, which is required to manage the AKS cluster
  • The Key Vault Administrator role, which is required to manage the secrets in the key vault
Alternatively, you can assign these roles to the solution resource group after deployment.

2.8 Prepare the VNet and the subnet

Prepare the VNet and the subnet to which you will connect the private endpoint to the Azure Private Link services of the solution. The VNet must already exist in the customer environment that is routed to and from the corporate network. The VNet can reside in any subscription.

Next steps

Deploy Virtual Private Cloud