Windows Azure SQL Database Marketplace
We announced the preview of Windows Azure Virtual Network on June 6. In this blog post, we wanted to take a deeper look at this brand new feature and explain it further in the context of other cross-premises networking features that already exist in Windows Azure.
Prior to the release of Windows Azure Virtual Network, you had a range of options to connect your on-premises IT environment with the public cloud. You were able to use SQL Data Sync for synchronizing databases, ServiceBus for application-level connectivity, and Windows Azure Connect for securely connecting machines at an IP level. Now, with Windows Azure Virtual Network, we’re enhancing our cross-premises connectivity stack further by allowing you to set up site-to-site connectivity, much like you’d set up a branch office network and connect your corporate network to it using VPN gateways.
Here’s a visual representation of our cross-premises connectivity stack with the release of the Virtual Network service:
With this new capability, you can now create a logically isolated private environment in Windows Azure, and connect it to your corporate datacenter using a secure VPN tunnel. Once set up, your isolated Windows Azure environment can function as a logical extension of your corporate network.
You can create a private network (called a Virtual Network, or VNET for short) in the Windows Azure environment within which you’re able to define private IP address ranges. Within a VNET, you also have the choice of creating logical subnets and specifying a DNS that virtual machines will use. When virtual machines or role instances are launched inside a VNET or a subnet, they’re automatically assigned the IP address from the range you specify. A thing to note here is that VNETs are logically isolated from each other, so your private IP addresses do not collide with another customer’s private IP addresses even though they might be the same.
Once you’ve created a VNET, you have the option to connect it securely to your on-premises network through a standard IPSEC VPN tunnel. If you choose to do this, a VPN gateway will automatically be provisioned for you in Windows Azure. Then, all you have to do is to configure your on-premises VPN gateway to finish setting up the tunnel.
With the functionality that Windows Azure Virtual Network provides, we think you’ll be able to address a variety of hybrid cloud scenarios like building ‘virtual’ extensions to your datacenter, or running some parts of your application in the Cloud and others in your local datacenter. For example, you can now domain join virtual machines running in Windows Azure to an on-premises AD, and you can run intranet-facing Sharepoint in Windows Azure.
“Great, so both Virtual Network and Connect allow me to create secure cross-premises IP level connections. What’s the difference?” you might ask. Here’s a quick video illustrating the difference between these two services:
You can create a VNET in Windows Azure through the management portal in a fairly simple manner. The following video explains how to setup a VNET, assign IP address ranges and then create a connection with your on-premises network.
We hope you’ll like the Windows Azure Virtual Network capability. Click here for more information and tutorials on creating and managing virtual networks in Windows Azure.
Venkat Gattamneni, Sr. Product Marketing Manager, Windows Azure
Jason Chen, Principal Program Manager, Windows Azure