Archive for March, 2017

I have not seen a lot of official guidance from Microsoft on the number of Resource Groups  (RGs) in a deployment.  Should I put all my resources in one large group? Or use multiple RGs, and what criteria do you use to segment them? Here are some thoughts on granularity and Resource Groups.

  1. Putting all resources in a large group is akin to writing one large monolithic main program with no functions – it is not good modular design and changes later can be an issue. T
  2. Tagging of tiers for monitoring, billing status, and management.   You can tag all resources in one RG (vs each individual resource). If all on one big RG, you can’t differentiate between tiers.
  3. Being able to update all the resources in a RG as one or separately.  Only resources that life cycle together should be in the same RG. A resource group is a unit of provisioning resources as a unit in one action (Application Lifecycle Management – ALM).  You can update and delete them as a unit.
  4. You can restrict access to RGs using RBAC at a more granular level.  This requires more analysis in this architecture but is a administrative positive in multi-tier environments. If everything is in one RG you love this capability. For production applications, you can control the users that may access those resources.  Or for the core infrastructure resources you can limit only infrastructure folks to work with them.
  5. With different RGs, you can define different admin access permissions for each tier. Owner, Reader, Contributor.  Some admins may be owner on one tier, but contributor on other tiers. Not a good security idea to let everyone in the door at the party and let them roam freely in the house into different rooms that they may not have a true business need to administer.  Its why we have different roles/permissions in SQL Server for admins.
  6. Compartmentalizing templates/RGs helps division of responsibility to enhance security. Each template for each tier can be under different RBAC roles for full separation of duties.  Using one large RG you lose the granular security for different tiers of your solution.
  7. Centralized RGs that contain core components (storage, VNETs/subnets, etc.) are an option with >1 RG. As you scale out, creating centralized Resource Groups for your virtual networking and subnets makes it easier to build cross-premises network connections for hybrid connectivity options. When combined with RBAC, you can protect these common groups to only be administered by the correct admin.

Here are some key points around Azure VNET to VNET Peering.


  • Virtual network (VNet) peering enables you to connect two VNets in the same region through the Azure backbone network (no Internet). Once peered, the two VNets appear as one for connectivity purposes.
  • If your VNets are in the same region, you do not need to use a Gateway. Rather, connect VNETs in the same regions with VNET Peering.
  • If VNETs are in different regions, you need to use a Gateway.
  • Each VNet, regardless of whether it is peered with another VNet, can still have its own gateway and use it to connect to an on-premises network.
  • VNet-to-VNet traffic within the same region is free for both directions.
  • Cross region VNet-to-VNet egress (outbound) traffic is charged with the outbound inter-VNet data transfer rates based on the source regions


The traffic between VMs in the peered VNets is routed through the Azure infrastructure (Backbone) (not through a gateway) much like traffic is routed between VMs in the same VNet.  This yields a low-latency, high-bandwidth connection between resources in different VNets.  VMs in the peered VNets can communicate with each other directly by using private IP addresses.


  • The peered VNets must exist in the same Azure region.
  • The peered VNets must have non-overlapping IP address spaces.
  • You can peer VNets that exist in two different subscriptions. A privileged user of both subscriptions authorizes the peering. The subscriptions are associated to the same Active Directory tenant.
  • The network throughput is based on the bandwidth that’s allowed for the VM proportionate to its size. Though the communication between VMs in peered VNets has no additional bandwidth restrictions, there is a maximum network bandwidth depending on the VM size that still applies.



Ever struggle with how to properly select the correct VM type/size for your Azure architecture? I do!  More choices than Kim Kardashian has shoes!  It can be really hard to make the right decision since they are all very good VMs to run your apps on.
Here’s a simplified cheat sheet, and a links that give you cllear info on your decisions.
A series – Normal generic VMs

F series – Eventually replace generic A-series

D/DS series  – “DISK” with faster caching

G/GS series – “GODZILLA” with very large RAM

N series – “NVIDIA” (Graphics units)

H series – “HPC” Compute Intensive with fast Infiniband RDMA

L/LS series -“LOW LATENCY” storage optimized

Choosing the most appropriate Azure Virtual Machine Specification