Connecting Apps with Windows Azure Connect

Windows Azure Connect’s primary scenario is enabling IP-level network connectivity between Azure services and external resources. The underlying connectivity model that supports this is quite flexible. For example, you can use Sydney to setup networking between arbitrary groups of machines that are distributed across the internet in a very controlled and secure manner.

Overview

To enable IP-level network connectivity between Azure services and external resources, Windows Azure Connect can be used. The underlying connectivity model that supports this is quite flexible. For example, you can use Windows Azure Connect to setup networking between arbitrary groups of machines that are distributed across the internet in a very controlled and secure manner.

The following diagram illustrates the key elements of the Windows Azure Connect model.

Windows Azure Connect creates a logical “virtual network” which can contain two types of entities: Azure Role groups and Machine groups.

  • Role groups map to Azure roles, which have been enabled for Windows Azure Connect. Only the Azure VM instances for a role are members of a role group – the admin cannot manually add or remove members. Windows Azure Connect automatically manages the membership of role groups – if you add or remove role instances, Windows Azure Connect will track this and update the role group membership appropriately.
  • Machine groups are admin-defined collections of external machines, which have been enabled for Windows Azure Connect through installation of the Windows Azure Connect Endpoint Software. An external machine can belong to at most one machine group.

Connectivity within the Windows Azure Connect virtual network is based on the following rules:

  • A role group can be “linked” to a machine group – this enables connectivity between the members of those groups. A role group can be linked to multiple machine groups – e.g. you could have an Azure web role that is connected to your “My Servers” and “My Laptops” machine groups as shown in the diagram above.
  • Members of a role group (the Azure VM instances) do not have connectivity with each other. In addition, a role group cannot be linked to another role group. These limitations are intentional – the Azure service model controls connectivity between roles and the Azure runtime supports connectivity between role instances. We did not want the Windows Azure Connect model to interfere with this behavior.
  • Machine groups can be linked, as mentioned above, to role groups. Machine groups can also be linked to other machine groups to enable connectivity between members of those groups.
  • Links are not transitive from a connectivity perspective. For example, suppose Group A is linked to Group B, and Group B is linked to Group C. Machines in Group A can communicate with those in Group B, and machines in Group B can communicate with those in Group C. However, machines in Group A cannot communicate with those in Group C.
  • A machine group has an “interconnected” property – if it is set to true, then all members of that group can communicate with each other. If it is set to false, then communication between the members is not allowed.
  • It is important to note that Windows Azure Connect does not affect or interfere with a machine’s existing network connectivity.

Objectives

In this lab, you will learn how to:

  • Provision a Windows Azure Connect service and associate it with your Azure subscription.
  • Setup network connectivity between Azure Roles and external machines.

Exercises

This lab includes the following exercise:

  1. Connecting an Azure Web Role to an External SQL Server Database with Windows Azure Connect
  2. Connecting an Azure Web Role to a on premise services with Windows Azure Connect