In this post I will be comparing the two different options, Azure Resource Management and Resource groups.

These two are fundamentally different although they have the same functions for the resources.

But first let’s go thru the cloud journey you choose to get here.

Choosing your cloud solution

This was from Microsoft Security compass presentation and it was so nice that decided to include it here.

High-level responsibilities

Here are the differences for different approaches.

As we can see the more you rely on Microsoft provided PaaS or SaaS, you will have less to worry about.

Security is always a mutual responsibility

When you migrate and start using workloads in the cloud, you will have protection from Azure out of the box for some parts and you can buy different security solutions for them.

Microsoft does their job for proactively protecting their and your environment as you can see from the numbers below.

What about your part?

First define your responsible team for different aspects.

Network Security	Typically existing network security team Configuration and maintenance of Azure Firewall, Network Virtual Appliances (and associated routing), WAFs, NSGs, ASGs, etc.
Network Management	Typically existing network operations team Enterprise-wide virtual network and subnet allocation
Server Endpoint Security	Typically IT operations, security, or jointly Monitor and remediate server security (patching, configuration, endpoint security, etc.)
Incident Monitoring and Response	Typically security operations team Investigate and remediate security incidents in SIEM or source console: •Azure Security Center •Azure AD Identity Protection	•
Policy Management	Typically GRC team + Architecture Set Direction for use of Roles Based Access Control (RBAC), Azure Security Center, Administrator protection strategy, and Azure Policy to govern Azure resources
Identity Security and Standards	Typically Security Team + Identity Team Jointly Set direction for Azure AD directories, PIM/PAM usage, MFA, password/synchronization configuration, Application Identity Standards

Azure Security Benchmark (baseline)

Microsoft has established a security benchmark for deployments and it’s currently in version 3.0

Here the Excel sheet to see the security recommendations.

azure-security-benchmark-v3.0.xlsx

And here the old version 2.0 for referral.

azure-resource-manager-security-baseline-v2.0.xlsx

github.com

And Here’s what’s new in the Azure Security Benchmark version 3.0:

Mappings to the industry frameworks PCI-DSS v3.2.1 and CIS Controls v8 are added in addition to the existing mappings to CIS Controls v7.1 and NIST SP800-53 Rev4.
Refining the control guidance to be more granular and actionable, e.g., security guidance is now divided into two separate parts, Security Principle and Azure Guidance. Security Principle is the “what”, explaining the control at the technology-agnostic level; Azure Guidance is focused on the “how”, elaborating on the relevant technical features and ways to implement the controls in Azure.
The addition of new control(s), e.g., DevOps Security as a new control family which also includes topics such as threat modeling and software supply chain security. Key and certificate management was introduced to recommend key and certificate management best practices in Azure.

So, just bear this one mind when checking those settings that could be right for you.

Then you create the approach for the cloud and in the cloud.

There are many layers before you can get to the deployment itself and for the top most level Microsoft have made a framework called Cloud Adoption Framework or CAF.

What is CAF you ask?

Microsoft has defined their preferred way to the cloud inside this framework.

In the architecture point of view it looks similar to this.

How to achieve this?

Microsoft want’s you to deploy Management groups that will be managing the subscriptions below, those subscriptions have the resource groups that have the resources.

So as I mentioned in the beginning, you can achieve the same level of protection with resource group level but then you have to manage them individually not from Tenant root level.

When you choose Management groups

A subscription can belong to one management group
Management groups can only be six levels deep
You are allowed 10,000 management groups in a single tenant
There is a single top-level root management group that cannot be deleted
New subscriptions are automatically placed under the root
Any user access assigned to a management group is applied to all resources and child management groups
By default, the root management group’s display name is Tenant root group. The ID is the Azure Active Directory ID
To change the display name, your account must be assigned the Owner or Contributor role on the root management group. See Change the name of a management group to update the name of a management group
The root management group can’t be moved or deleted, unlike other management groups
All subscriptions and management groups fold up to the one root management group within the directory
All resources in the directory fold up to the root management group for global management
New subscriptions are automatically defaulted to the root management group when created
All Azure customers can see the root management group, but not all customers have access to manage that root management group
Everyone who has access to a subscription can see the context of where that subscription is in the hierarchy
No one is given default access to the root management group. Azure AD Global Administrators are the only users that can elevate themselves to gain access. Once they have access to the root management group, the global administrators can assign any Azure role to other users to manage it
In SDK, the root management group, or ‘Tenant Root’, operates as a management group

And this it what it will look like.

What about resource groups?

When using resource groups, you should design the resources to have the same life-cycle. Production functions to their own and development or testing in their own.

Here is a example list of do’s and dont’s for them:

Resources can be added to or deleted from an Azure Resource Group but they always have to belong to to one.
When you create a resource group and add resources, you have to remember that Not all resources can be moved to different resource groups.
Azure resource group regions: the resources you include in a resource group can be located in different Azure regions, and may be in different regions than the group itself. The group needs a location to specify where the metadata will be stored, which is necessary for some compliance policies.
Grant access with resource groups: you should use resource groups to control access to your resources.
When a resource group is deleted, all resources in the group are deleted .
Group limits: you can deploy up to 800 instances of a resource type in each resource group – with some exceptions.

Resource group limits

Resource	Limit
Resources per resource group	Resources aren’t limited by resource group. Instead, they’re limited by resource type in a resource group. See next row.
Resources per resource group, per resource type	800 – Some resource types can exceed the 800 limit. See Resources not limited to 800 instances per resource group.
Deployments per resource group in the deployment history	800¹
Resources per deployment	800
Management locks per unique scope	20
Number of tags per resource or resource group	50
Tag key length	512
Tag value length	256

¹ Deployments are automatically deleted from the history as you near the limit. Deleting an entry from the deployment history doesn’t affect the deployed resources. For more information, see Automatic deletions from deployment history.

VNet peering best practices

As you build your network in Azure, it is important to keep in mind the following universal design principles:

Ensure non-overlapping address spaces. Make sure your VNet address space (CIDR block) does not overlap with your organization’s other network ranges.
Your subnets should not cover the entire address space of the VNet. Plan ahead and reserve some address space for the future.
It is recommended you have fewer large VNets rather than multiple small VNets. This will prevent management overhead.
Secure your VNets by assigning Network Security Groups (NSGs) to the subnets beneath them. For more information about network security concepts, see Azure network security overview.

When in doubt or you don’t have environment to try out different subscription scenarios, you can rely on Microsoft to give you a clear picture what path to choose.

Microsoft architecture center to the rescue!

Microsoft have released an consolidated center for different architectures, it’s an easy way to start the planning.

Azure Architecture Center – Azure Architecture Center

The Azure Architecture Center provides guidance for designing and building solutions on Azure using established patterns and practices.

If you choose “Browse Azure architecture” from the main page.

There you will find example guidance for integrating your On-premises AD securely to Azure AD.

But also cost estimates for different deployment. Microsoft has created an example of microservices pattern. As the container orchestrator, one of the options could be Azure Kubernetes Service (AKS) that manages a cluster of pods. Microsoft chose NGINX ingress controller because it’s well-known controller for such workloads.

Architecture of the Drone Delivery application

And the initial cost estimations.

Initial cost estimate – Azure Architecture Center

Learn best practices and strategies for modeling workloads and estimating initial costs for cloud migrations.

Technology Area documentations by Microsoft

Explore architectures and guides for different technologies

AI & Machine Learning

Data

DevOps

Enterprise integration

High performance computing (HPC)

Identity

Internet of Things (IoT)

Microservices

Networking

Serverless applications

VM workloads

SAP

Web apps

Final thoughts

If your environment will be scaled to multiple subscriptions, it would be wise to choose Management groups. Also consider the management with policies from the Management group level.

You can also use one subscription and resource groups or multiple subscriptions and their own resource groups based on the resources that need to be grouped. And then peer those subscriptions with VNet peering.

Or even use Azure Private Links to provide external subscriptions access to your own resources. People have been using Private Endpoint to publish to other tenants but this should not be done based on Microsoft best practices but instead to use Azure Private Links.

There could be more but I will split these to coming posts, stay tuned for more!

KEEP CALM AND CARRY ON IN AZURE - Keep Calm and Posters Generator, Maker For Free - KeepCalmAndPosters.com

Azure Enterprise-scale or Resource groups?