Resource Groups
The first real thing you’ll ever build in Azure is a resource group. Resource groups are free to create.
This blog entry is the fourth in a series regarding virtual machines within Microsoft’s Azure Infrastructure-as-a-Service (IaaS) platform. After our coverage of the prerequisites to virtual machines , this post focuses on the required resources.
An Azure resource group is a container that holds related resources. Resources in a resource group should share a similar life cycle. Every object in an Azure deployment needs to be in a resource group. Objects can be added to or removed from a resource group at any time. Objects can also be moved between resource groups.
As important as they are, you can’t actually do anything with a resource group alone. A resource group has exactly two properties that need to be set: a name and a location. Nonetheless, for any resource that you create, you’ll need to specify a resource group or create a new one. There’s a common misconception that all resources within a resource group must be in the same location. This is false, and the only thing that’s locked into the location that you specify in a resource group is the metadata. Therefore, if you have a deployment that includes VMs in different regions, you can keep those resources in the same resource group.
A resource group also provides a very quick and easy way to delete a large number of resources. Deleting a resource group will delete every single resource contained within it. This is obviously very powerful – and very permanent – so Microsoft has added a few extra steps to make sure that you only delete things you really want to delete.
Virtual Networks
Another resource that an Azure VM must have is a virtual network. Like resource groups, virtual networks are free to create.
A virtual network (VNet) is what allows all objects in Azure to securely communicate with each other. A VNet also provides a means to communicate with endpoints outside of that VNet, either in another VNet or on another network altogether, like your local office or a datacenter.
In order to create a virtual network, there are four required properties that you must define:
- In Azure, nearly all object names are canonical, meaning that they can never be changed, so take care to plan out your naming convention before beginning deployment of resources.
- Resource Group. Again, everything in Azure needs a resource group.
- Location. This is the region where you’ll deploy your VNet. Understand that all VMs must exist in the same location as the VNet they’re associated with, so at this point a decision on location should be finalized.
- Address Space. An address space is composed of one or more non-overlapping IP ranges. Devices on these ranges can communicate with each other, but not with devices on other networks, unless a connection has been established with the VNet. A VNet’s IP range can be broken down further into subnets. It’s very important to note that the address space that you define for your virtual network cannot overlap with your on-premises network if the intention is to connect them. If overlapping networks exist, a connection cannot be established.
Connectivity
This is the point of the process where you start incurring charges.
Once you’ve created a VNet, you can begin to build virtual machines. Note, though, that these machines will only be able to communicate with each other, or with the internet should you expose them externally. In order to securely connect to your on-premises environment, you’ll need to create a private VPN connection. This is done by creating a virtual network gateway (VNG) and configuring it to talk to your on-premises firewall. Once this is configured and the proper networks are defined both on-premises and in Azure, traffic can route between the two networks. A similar relationship can be established between two Azure VNets, even if they’re in different subscriptions.
VNGs come in a variety of performance SKUs. The entry-level SKU is the Basic, which has a maximum bandwidth of 100 Mbps, a maximum of 10 S2S tunnels and a maximum of 128 P2S tunnels. The fastest SKU is the VpnGw5, which offers 10 Gbps.
If you’re wondering why anyone would bother with the Basic when the VpnGw5 is available, the answer is simple – price. The Basic costs only $0.04 per hour, while the VpnGw5’s price tag is much higher, at $3.65 per hour. If you’re running your connection 24/7/365, the price difference is $350.40 for the Basic vs. $31,974.00 for the VpnGw5.
In reality, the Basic would only be used for testing, and the VpnGw5 would be reserved for much larger workloads. Therefore, there are a number of options in between, one of which will likely suit your particular needs.
Another price to be aware of is data egress costs. While data going into Azure costs nothing, you’ll pay for every byte after the first 5 GB that leaves Azure. That cost will be about $86 per TB, so it’s important to understand how your devices will communicate and what traffic will be flowing.
Possible Discounts for Azure VMs
If your company owns Windows Server 2012/2016 Standard or Datacenter with Software Assurance, you might be entitled to a discount of about 40% on some Azure VMs.
Azure Windows VMs include the Windows licenses as part of the cost. However, if you have SA on your Windows Server licenses, you can repurpose them in Azure by selecting the base compute rate VMs (which are essentially Linux labeled). In order to take advantage of this special offer, you need to either create the Azure VM by selecting the Azure Marketplace image or by migrating an existing Azure VM using Azure Site Recovery and PowerShell.
The licensing benefit allows you to run two Azure VMs with up to eight cores or one Azure VM with up to 16 cores, at the base compute rate described above. If you’re licensed for Windows Server Standard, you must stop using that license on-premises in order to take advantage of the offer. Windows Server Datacenter allows you to keep using the licenses on-premises as well as in Azure.
To continue to the conversation with our team, please get in touch.
