Architecture Fundamentals in Azure Lab Services

Note

This article references features available since the August 2022 Update, when lab plans replaced lab accounts. For more information, see What's New in the August 2022 Update.

Azure Lab Services is a SaaS (software as a service) solution, which means that the resources needed by Lab Services are handled for you. This article will cover the fundamental resources used by Lab Services and basic architecture of a lab.

Azure Lab Services does provide a couple of areas that allow you to use your own resources with Lab Services. For more information about using VMs on your own network, see Connect to your virtual network in Azure Lab Services to use virtual network injection instead of virtual network peering. To reuse images from an Azure Compute Gallery, see how to attach a compute gallery.

Below is the basic architecture of a lab without advanced networking enabled. The lab plan is hosted in your subscription. The student VMs, along with the resources needed to support the VMs are hosted in a subscription owned by Azure Lab Services. Let’s talk about what is in Azure Lab Service's subscriptions in more detail.

Hosted Resources

The resources required to run a lab are hosted in one of the Microsoft-managed Azure subscriptions. Resources include:

• template virtual machine for the educator
• virtual machine for each student
• network-related items such as a load balancer, virtual network, and network security group

These subscriptions are monitored for suspicious activity. It's important to note that this monitoring is done externally to the virtual machines through VM extension or network pattern monitoring. If shutdown on disconnect is enabled, a diagnostic extension is enabled on the virtual machine. The extension allows Lab Services to be informed of the remote desktop protocol (RDP) session disconnect event.

Virtual Network

By default, each lab is isolated by its own virtual network.

Students connect to their virtual machine through a load balancer. No student virtual machines have a public IP address; they only have a private IP address. The connection string for the student will be the public IP address of the load balancer and a random port between:

• 4980-4989 and 5000-6999 for SSH connections
• 4990-4999 and 7000-8999 for RDP connections

Inbound rules on the load balancer forward the connection, depending on the operating system, to either port 22 (SSH) or port 3389 (RDP) of the appropriate virtual machine. An NSG prevents outside traffic on any other ports.

If the lab is using advanced networking, then each lab is using the same subnet that has been delegated to Azure Lab Services and connected to the lab plan. You'll also be responsible for creating an NSG with an inbound security rule to allow RDP and SSH traffic so students can connect to their VMs.

Access control to the virtual machines

Lab Services handles the student’s ability to perform actions like start and stop on their virtual machines. It also controls access to their VM connection information.

Lab Services also handles the registration of students to the service. There are currently two different access settings: restricted and nonrestricted. For more information, see the manage lab users article. Restricted access means Lab Services verifies that the students are added as user before allowing access. Nonrestricted means any user can register as long as they have the registration link and there's capacity in the lab. Nonrestricted can be useful for hackathon events.

Student VMs that are hosted in the lab have a username and password set by the creator of the lab. Alternately, the creator of the lab can allow registered students to choose their own password on first sign-in.

Next steps

To learn more about features available in Lab Services, see Azure Lab Services concepts and Azure Lab Services overview.