Arrow Image

Blog & News

Arrow Image

Automated Deployment of a Streaming Gateway Appliance (SGA) with Frame Networking in AWS

Automated Deployment of a Streaming Gateway Appliance (SGA) with Frame Networking in AWS

In my previous blog, I outlined how the Nutanix Frame™ Bring Your Own (BYO) Networking capability in Amazon Web Services (AWS) could be used to deploy a Frame account in a manner that would allow it to be connected to an existing private network. In that post, I deployed a RDP bastion server so that I could access those private Frame workloads from an internet based machine since I had no private network.

News & Blog



In this blog, I will demonstrate how the Frame automated Streaming Gateway Appliance (SGA) deployment capability can be used to grant internet access to those same private workloads so that I no longer need the RDP bastion server to access the private network.

Private Network Configuration

The diagram below shows the existing private network configuration.

Figure 1. Existing network configuration
Figure 1. Existing network configuration

In this scenario I chose to use a /24 CIDR for the VPC, in order to better accommodate the SGA requirement that the target private network has a network mask between 18 and 24 bits.

Streaming Gateway Appliance (SGA)

The Streaming Gateway Appliance (SGA) is a reverse proxy, based on NGINX® software, that customers can deploy which allows internet-based users to connect to Frame workload virtual machines (VMs) that are on private networks. The architecture is described here. The SGA can be manually deployed by a cloud administrator on your private cloud in the network of your choosing (VPC, subnet) by following these directions. You will need to manage the wildcard DNS A record, the wildcard public key certificate for the SGA, and the load balancer (if you wish to have a high-availability SGA deployment).

Recently, Nutanix introduced a feature (Frame networking, private network with SGA) that automates the deployment of an SGA. This allows the Frame customer administrator to create one or more SGAs from the Frame Console during account creation. With this feature, the automation orchestration process creates both a Frame workload VPC and an SGA VPC, handles the wildcard DNS A record, the wildcard public key certificate, and the load balancer (if required). However, this capability is not appropriate for our BYO Networking case. The automation capability can be leveraged if you contact Frame Support with your Frame Account name, the CIDR that should be used for the SGA VPC, and the number of SGA's that you want deployed. Frame Support can kick off the process to automatically create the SGA VPC for you and peer it to your existing VPC.

In this example, I want 2 SGAs in a VPC with the CIDR so that both VPCs will be routable to each other and any other private subnets I might create in the future. The automated SGA deployment process will end up creating a solution architecture, as illustrated in Figure 2.

Figure 2. SGA Deployment Architecture
Figure 2. SGA Deployment Architecture

Frame automatically creates the VPC, the peer, the subnets (one for each availability zone), the Internet Gateway, the NAT GW, the number of SGA's requested, and the load balancer (if more than 1 SGA is requested). It also sets up the routes. The only task that needs to be done on the Frame Account VPC is to check the workload security group and confirm that the SGAs have the ability to establish inbound connections to the workload VMs on 443 so the users on the Internet can stream from the workload VMs. In this example, I did that by allowing all IP's to create inbound tcp/443 sessions in the workload security group.

Automating the Whole Thing

As mentioned above, Frame has a new feature to automatically deploy and set up SGAs when creating Frame accounts using BYO AWS subscriptions. The feature, labeled ‘Private network with SGA', allows Frame Administrators to automatically deploy both a Frame SGA VPC and a Frame workload VPC in one easy step. The only additional information required from what is mentioned above is the VPC CIDR of the workload VPC.

Figure 3. Private Network with SGA dialog
Figure 3. Private Network with SGA dialog

Following the workflow described in our documentation, the Frame Platform will create the resources for the same architecture as the BYO Network case above. The SGAs will be placed behind a load balancer and “Let's Encrypt” certificates dedicated to the Frame Account will be created and automatically deployed. The subdomain used will be a subdomain of the domain and will include the “vendor ID” which is a unique identifier for a frame account (vendor id is 33957 in the example below).

Figure 4. Sample of a SGA-enabled workload VM hostname
Figure 4. Sample of a SGA-enabled workload VM hostname

SGA Autodeploy - Networking

As noted above, the SGA Autodeploy, whether initiated via Frame Support or through the Frame Console, creates a new VPC dedicated to the SGAs. This separation has the benefit of creating a cloud-based DMZ where inbound connections to the private network can be focused and secured.

Figure 5. SGA VPC
Figure 5. SGA VPC

The Frame Administrator defines the CIDR block and a VPC is created with that block. This CIDR should be unique and routable on the Private network or Private VPCs that it needs to connect.

The autodeploy process will split this VPC into subnets based on the number of AWS Availability Zones (AZs) in the AWS Region. If more than one SGA is requested, Frame Platform will deploy the SGAs in multiple AZs, resulting in a high availability (HA) solution when a single AZ is inaccessible.

An internet gateway is attached to the SGA VPC and if required, a load balancer is provisioned in front of the SGAs, completing the HA setup. The final networking step creates the peer with the requested Frame account workload VPC and updates the route tables in both VPCs.

SGA Autodeploy - DNS

The next step is to create a DNS subzone based on what is known in Frame as the “Vendor ID” as shown in Figure 5. Each Frame account has a unique ID found on the “Summary” page of the account.

Figure 6. Vendor ID
Figure 6. Vendor ID

The subzone will be subordinate to the domain and will be of the form We use Route53 for our DNS so the subzone will be created and a single wildcard entry will be set up pointing to either the IP of the single SGA instance or the CNAME of the AWS Load Balancer.

SGA Autodeploy - NGINX Configuration

The SGA VMs themselves are deployed with “userdata” which is a script that runs each time the SGA is booted. It uses environment variables set by the Frame Platform to customize the configuration.

If not configured, the first thing the SGA does is create a public or private keypair that is and sends the public key to Frame Platform. This pair is used to secure future communications between the SGA and the Frame Platform.

The script then contacts “LetsEncrypt” to get a challenge string which is then forwarded to Frame Platform. The Frame Platform takes the challenge string and stores it in the DNS subzone as a TXT record so that “LetsEncrypt” can validate the ownership of the DNS subzone.

The SGA script then polls the Frame Platform until it gets confirmation from the Frame Platform that the DNS update is complete. It then informs “LetsEncrypt” that the challenge can be verified. Once successful, LetsEncrypt completes the SSL certificate signing and returns the public key certificate back to the SGA where it can be used in the Nginx configuration.

A separate script takes the CIDR information provided and creates the appropriate entries in NGINX for each potential workload IP address.

Once all this is done, NGINX is restarted and the SGA is ready to go!

The Benefits

Automating the deployment of Streaming Gateway Appliances (SGA) gives Frame administrators the benefit of additional security for their Frame accounts, without the hassle of obtaining and maintaining SSL Certificates and managing the wildcard DNS record. It also eases the connection between the Frame workload account and the private network by allowing administrators to control the private IP addressing of both the Frame Account and the SGA VPCs.

About the Author


Dizzion was founded in 2011 with a visionary mission to redefine the way the world works.

In an era of legacy Virtual Desktop Infrastructure (VDI), Dizzion set out to challenge the status quo by making it simple for all customers to transform their workspace experience. By building a powerful automation and services platform on top of the VMware stack, Dizzion delivered virtual desktops as a service before Desktop as a Service (DaaS) even existed.

David Horvath

Senior Solutions Architect

William Wong is the VP of Service Delivery for Dizzion, responsible for service delivery (professional and managed services), solutions architecture, and support. He works actively with customers to transform their business and operations leveraging DaaS in a hybrid and multi-cloud world. Before joining Dizzion as part of the Frame spinout from Nutanix, William was Head of Enterprise Solutions at Frame and following Nutanix's acquisition of Frame in 2018, Director of Solutions Architecture (Frame) at Nutanix. Prior to his work in DaaS, William led the development and adoption of innovative Internet software solutions and services, including Internet-based credit card and check processing and eCommerce platforms. William spent over 30 years at Cancer Commons, NetDeposit, Hewlett-Packard, VeriFone, and multiple Internet, payment, and eCommerce startups in executive management, program management, engineering management, and executive advisory positions. William received his B.S., M.S., and Ph.D. in Electrical Engineering from Stanford University.

More about the author

Subscribe to our newsletter

Register for our newsletter now to unlock the full potential of Dizzion's Resource Library. Don't miss out on the latest industry insights – sign up today!