BYO Azure Account

Bring Your Own Azure Subscription to Frame

Frame provides two options for using Azure infrastructure. You can “Bring Your Own” (BYO) Microsoft Azure subscription that you own and manage yourself or purchase Nutanix IaaS credits to use Nutanix-managed Azure subscription. When you bring your own (BYO) Azure subscription, you pay Microsoft directly for infrastructure (your VMs, storage, networking, etc.) and only pay Nutanix for using Frame.

Common reasons why you would bring your own Azure subscription are:

  • You wish to take advantage of existing billing arrangements with Azure for convenience and/or pricing. For example, your organization may already have certain Azure consumption commitments or pre-payments – you can use Frame to consume those resources on your own Azure account.

  • You want to have additional administrative control over your Frame workloads for more detailed monitoring and metrics.

  • You want to configure other network integrations (VPN gateways, ExpressRoutes) which you can’t do using Nutanix-managed Azure subscription.

  • You must meet industry-specific compliance regimes (e.g., HIPAA) that require you to fully manage and control your cloud resources.


  • In order to register your Azure account with Frame, you will need a Microsoft Azure account with a valid Azure subscription. If you don’t have one already you can create one by going to Microsoft’s website.

  • Permissions to add and modify role assignments for the Azure subscription ID.

  • Before proceeding, ensure that the following Resource Providers are registered in your Azure subscription:

    • Microsoft.Compute

    • Microsoft.Network

    • Microsoft.Storage


Please note that some costs (e.g., storage) may begin to accrue immediately after adding your BYO Azure Cloud Account credentials to Frame Platform.

Create an Azure Application Registration

This section assumes that you already have an active Azure account with a subscription dedicated to Frame. At this point, you should have also set the resource limits for your subscription to levels high enough to accommodate your expected loads. To confirm your subscription, login to the Azure web portal, navigate to your subscription, and confirm that its status is “active”:

  1. You will need to create an Azure app registration for Frame. The app registration is the mechanism by which you’ll give Frame access to creating and managing virtual machines and storage resources in your Azure subscription. Open the Azure Active Directory option and App registration section. From there, select “New registration” to create a new app.

  1. You’ll see a panel titled “Register an application.” You’ll be asked for the following information:

  • a valid Name: you can choose any name, but we recommend you simply call it “Frame” or “Frame.”

  • select your desired “Supported account types” option to specify who has access to the application.

  • a Redirect URI: You can leave this optional field blank.

  1. Click “Register” at the bottom of the panel.

  1. A notification will appear informing you that your application has been created successfully. It should now be available in your “App registrations” list.

  2. Next, select your new application from the list and copy or write down the “Application (client) ID” and “Directory (tenant) ID.” These IDs are two of the four values you will need for setting up your Frame integration (note that you do NOT need the “Object ID”):

  1. Once you have written down the Application (client) ID, navigate to the “Branding” page listed in the menu on the left side of your Azure portal.

  1. Use the application icon shown below. Click “Save.”

  1. Next, you’ll need to create a “Client Secret” for Frame to use as a password to manage your Azure resources. Click “Certificates & secrets” under your application’s management options. Click the “New client secret” button under “Client secrets”.

  2. You will be prompted to add a new client secret. Simply add a description and select the desired expiration duration from the drop-down menu next to “Expires.” Click “Add.”



The client secret is used by Frame to manage your BYO Azure account. Microsoft recently implemented a maximum expiration date of 2 years from the client secret creation date. When your key expires, you will need to re-enter your cloud account credentials from the cloud account management view of your Frame console. If you fail to update your client secret before it expires, Frame will no longer be able to manage your Azure account and you will likely experience an outage.

  1. On the “Client secrets” page, copy your newly-created client secret. We will need this value later on.


Subscription Configurations

The final step before integrating your BYO Azure cloud account with Frame entails obtaining your Azure Subscription ID and adding owner permissions to your new application.

  1. At the top of your Azure portal, search for “Subscriptions” and click on the first option that appears.

  1. Find the subscription that you created for Frame. Copy the Subscription ID and set it aside to be used in the final steps of this guide.

  1. Now, click on the subscription to open its properties. Click on the “Access Control (IAM)” page, and then click the “Add” button on the top of the Access Control panel. Select “Add role assignment.”

  1. A new window will appear asking for the following information:

  • Role: Select “Owner” or “Contributor” from the drop-down menu.

  • Assign access to: Select “Azure AD user, group, or service principal” option.

  • Select: Select the name of your application.

  1. Once you have configured the fields above, click “Save.”

  2. Before moving on, ensure you have obtained the following values.

  • Azure Application ID

  • Azure Directory ID

  • Azure Subscription ID

  • Azure Client Secret

You’ll use these values for the Frame setup below.

Adding your Azure Cloud Account

BYO cloud accounts can be created either at the “customer” or “organization” tiers of Frame’s logical hierarchy. More information about Frame’s hierarchy concepts can be referenced here.

A BYO cloud account created at the “customer” (highest) tier will be accessible to all hierarchical children (“organizations” and their accounts). If you choose to add the BYO cloud account at the “organization” tier, the BYO cloud account will only be available to the chosen organization and any accounts underneath it. Customer Administrators can add a BYO cloud account at the Customer or Organization level while Organization Administrators may only add a BYO cloud account at the Organization tier.


A particular cloud subscription can only be associated with a single entity on the Frame platform. If you associate your cloud subscription to one Organization, it cannot be associated with another Organization or Customer. If your use case requires that multiple Organizations will have access to your Azure subscription, you must associate the cloud account to your Customer entity.

Azure Cloud Account Registration Procedure

  1. Go to the Frame Admin view.

  2. Navigate to the “Organizations” or “Customers” section (depending on where you wish to add the cloud account).

  3. Click on the ellipsis listed next to the organization or customer you wish to add your cloud account to, click “Edit.”

  4. Select the “Cloud Accounts” tab and then select “Add Cloud Account” in the upper right corner:

  5. A new window will appear prompting you for the information you recorded earlier:

    • Name: Enter the desired name for your BYO Cloud Account.

    • Application ID: Enter the Azure Application ID.

    • Directory ID: Enter the Azure Directory ID.

    • Secret: Enter the Azure Secret key value.

    • Subscription ID: Enter the Azure Subscription ID.

    • Verify Azure credentials: Click this button to verify that your credentials are valid before creating the cloud account.

    • Select data centers: Select at least one data center you would like to provision your Frame account(s) and resources in.

  6. Click the check box once you have read through the disclaimer, and then click “Create.”

Now that your Azure Cloud Account is created and accessible within Frame, you will be able to create Frame accounts using this BYO cloud account. Be aware that the first Frame account created in an Azure datacenter region may take 30+ minutes as Frame Platform must copy the Nutanix-provided OS images to the Azure datacenter before the Frame account is created.

Resources Created During BYO Azure Cloud Account Creation

Frame provisions a single storage account for every datacenter region selected upon cloud account creation. The Nutanix-provided OS master images are copied to each storage account and will be used when the first Frame account is created in that region.

Azure Service Limits

By default, a newly created Azure account will impose certain service limits on available resources. Depending on the number of the Frame workload VMs required of a given machine family (e.g., number of concurrent users on NV6), how the Frame account is created (e.g., Frame networking with or without an SGA), and whether you use Publish or Quick Publish, you will likely need to adjust the default limits imposed on the Azure account. If these limits are set to values that are lower than what is required by the Frame platform, you can expect certain functions to either fail, or be substantially delayed. The requirements by Frame for these service limits depends on the desired workload and required resources. The recommended service limit increases include the following:


The following steps may not be necessary for smaller production environments or trial accounts.

Recommended Azure Service Limits

Azure Resource


Virtual Machines and Family vCPUs (CPU-only and GPU instance types)

Azure has quotas on the total number of vCPUs and the total number of family-specific vCPUs, on a per-location basis. We recommend you first determine the expected max number of instances by instance type (per Frame account) for your needs. Next, calculate the number of vCPUs and family-specific vCPUs based on the expected max number of instances and the required number of vCPUs per instance type (for that family). If you use Publish, set your vCPU quota to 2.2 times the required number of vCPUs and specific family-specific vCPUs quotas to 2.2 times your expected max number of instances. The additional 20% will accommodate any additional resources such as Sandboxes, Utility servers, etc. If you use Quick Publish, you can use a minimum factor of 1.X times to calculate the required number of vCPUs and family-specific vCPUs. X is computed as the “Number of production instances created on publish” divided by expected max instances. By default, the “Number of production instances created on publish” value is configured to be 10 VMs. A factor of 1.3-1.5 should be sufficient to account for typical Quick Publishes and overhead.

Azure Managed Disks

Typically, this resource quota does not need to be modified. To estimate total disk storage consumption, multiply the total number of VMs you expect to provision by the size of the Sandbox VM (e.g., Frame-provided Windows 10 images 128 GiB; Windows Server images 64 GiB) across all Frame accounts you plan to provision. Number and size of any utility servers, number of Sandbox image backups, number and size of personal drives, and number and size of enterprise profile disks would be additional storage to consider.

Public IPs

You will need 1 public IP address for each powered on VM for Frame accounts created with Frame networking (default). You will also need to account for the temporary increase of public IP addresses during a Publish or Quick Publish when the new production VMs are created and before the old production VMs are terminated. If the Frame account is created using Frame networking, private network with Streaming Gateway Appliance (SGA), then you will need 1 public IP address for the SGA VM (or the load balancer in front of the SGA VMs) and all of the workload VMs will only have private IP addresses.


If Frame networking (default) or Frame networking (private networking) is used to create Frame accounts, the number of VNets equals the number of Frame accounts. If Frame networking (private networking with SGA) is used to create Frame accounts, the required number of VNets is two times the number of Frame accounts. For BYO networking, no new networks are created.

Click the link for more information on Azure service limits. When requesting compute service limit increases, you must calculate and request limits based on the amount of CPU cores you will need per region, per instance type. For instance, if you needed two D2_V2 instances, you would need to request 4 cores (2 cores x 2 instances) for the “D Series” SKU Family in your Azure Portal. More information about requesting vCPU limit increases can be found in their official documentation.

Deployment model

When requesting limit/quota increases the Azure team may ask which deployment model is used. The method used is ARM (not ASM).

Azure Instance Types

Each IaaS provider has a unique naming scheme for their instance types. Azure breaks down their instance types by vCPU cores. More information about Windows virtual machines in Azure can be found in their official Azure documentation.

For the latest Azure instances supported by Frame, refer to Nutanix Frame Pricing Page. Note that since you are bringing your own Azure account, your pricing may be different from that shown in the table.


Promotional instances provided by Microsoft by default are not currently supported by Frame Platform. If you wish to use an account with an existing promotion, you will need to either exhaust promotional hours first or contact Azure support to remove those instances.

Usage Estimates

The total cost of your Azure service depends on your service tier with Azure and any custom pricing arrangements you may have. Full details of Azure pricing for these areas are listed in Azure’s pricing information online. If you have an Enterprise Agreement, you can download your specific price list from the EA Portal.

Storage sizing is based on several factors specific to your apps: the base system image of the Windows OS, the size of your applications plus application data and any user data. Additional data is consumed if you are using a Utility Server.

The base system image for the Sandbox can be set to any desired capacity upon account creation. The general formula for estimating the total amount of storage required is the Sandbox image size multiplied by the maximum number of instances multiplied by the monthly hours consumed. Total storage also includes the system image size of all Utility Servers multiplied by the number of hours consumed per month.


Even if instances are powered off, storage is still consumed.

Your networking usage on Azure also depends on your apps and the work patterns of your users. Azure networking limits and data transfer pricing are based on inbound and outbound data sent to or from Azure regions or the internet. Typical data transfer costs for Frame customers are between 1% and 2% of their overall monthly bill. For details about how your account will be charged for data transfers, please refer to Azure documentation.

Your Azure expenses are separate from the cost of the Frame service for our BYO accounts. Azure bills your account according to your usage patterns on Frame, as described in our documentation regarding capacity management.