Now with Windows Azure Virtual Machines and Virtual Networks a lot more capabilities are available to be able to look at Windows Azure not as a ‘yet another platform’ and not your network, but really think of it as a real extension of your On-Premises Data Center. Of course that this always depends on the type of company we are talking about, since if we talk with Enterprises this is a MUST-HAVE because they have a lot of investments still in the On-Premises world and some that aren’t still ready, and might never be, for the Public Cloud, but if we talk to ISV’s this isn’t that important because they want to reduce as much as possible their On-Premises needs.
In order to achieve this extension there is a component in Windows Azure that is key, which is Windows Azure Virtual Network, since it allows to create a VPN between On-Premises and your Windows Azure resources. But there are some important considerations to have in mind, like:
- Windows Azure Virtual Networks is currently still on Preview
- In order to use Windows Azure Virtual Network it’s required to have a Router device that supports VPN on the On-Premises location.
- The On-Premises VPN devices that are currently tested can be found here. This doesn’t mean that they are the only ones you can use, it just means that those are a lot simpler to configure because Windows Azure provides a configuration file that is required to import into the device and it’s done.
- Windows Azure Virtual Networks do not span Regions or Subscriptions, which means that if you have multiple deployments in the same region and within the same subscription you can use the same VNET, if not you’re required to create multiple VNET’s. Here are some scenarios:
- Scenario A:
- Description: Subscription A, has Service B deployed into Windows Azure Cloud Services in North Europe region and Service C deployed in Windows Azure Cloud Services in West Europe region
- Comments: Even though they are in the same subscriptions since they are in different regions you would need to create a VNET for Subscription A for the North Europe region and another for the West Europe region.
- Scenario B:
- Description: Subscription A , has Service A and B deployed Windows Azure Cloud or Windows Azure Virtual Machines, and it’s required that they are in the same VNET
- Comments: In this case you only need one VNET for both since they do not span either subscriptions or regions.
- Scenario C:
- Description: Subscription A has Service B and C deployed in Windows Azure Cloud Service within the same region, but it’s required to create security when connecting between them.
- Comments: In order to achieve this it’s only required to create one VNET since they are in the same subscription and region, but 2 different subnets one for each service, and then it’s the On-Premises VPN/Firewall device that will create the restrictions for each Subnet.
- Scenario D:
- Description: Subscription A has Service B deployed in Windows Azure on the North Central US region, and Subscription C has Service D deployed in Windows Azure on the North Central US region, but they need to communicate between themselves.
- Comments: in order to achieve this it’s required to create a 2 separate VPN connections, one for Subscription A and another for Subscription C, because VNET’s don’t span across different subscriptions even if they are in the same region.
- Currently there’s no ACLing for subnet isolation, so that needs to be done in one of three ways.
- Create different VNET for each Subnet and this way they aren’t known
- Perform the ACLing and restrictions between the different subnets on the Windows Firewall level of the instance
- Perform the ACLing in and On-Premises Firewall device.
So by leveraging Windows Azure Virtual Networks we’ll be able to connect everything we have deployed in Windows Azure Compute with our On-Premises Data Center. By doing this companies gain the ability of leveraging more of their existing investments and look at Windows Azure in a more "extension of Data Center" way and less as a "Black box" which you don’t have a lot of control.
In future posts I’ll go through the process of how-to setup a new Windows Azure Virtual Network between On-Premises and Windows Azure.