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.
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.)|
|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.
And here the old version 2.0 for referral.
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
|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||8001|
|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|
1 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.
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.
And the initial cost estimations.
Technology Area documentations by Microsoft
Explore architectures and guides for different technologies
- AKS Production Baseline
- AWS to Azure services comparison
- Cloud Design Patterns
- Web API design
- Chose your Azure compute service
- Application Architecture Guide
- Hub-spoke network topology
- CQRS design pattern
AI & Machine Learning
- Training of Python scikit-learn models
- Distributed training of deep learning models
- Batch scoring of Python models
- Conversational bot
- Machine learning
- Natural language processing
- R developer’s guide to Azure
- Movie recommendation
- Scalable personalization
- See more
- Big Data architectures
- Choosing a data store
- Databricks Monitoring
- Automated enterprise BI with Azure Data Factory
- Enterprise BI with SQL Data Warehouse
- Stream processing with Azure Databricks
- Data lakes
- Extending on-premises data solutions to the cloud
- Free-form text search
- IoT for construction
- Real-time fraud detection
- Time series solutions
- See more
- Advanced Azure Resource Manager Templates
- DevOps with Azure DevOps
- DevOps with containers
- Jenkins server
High performance computing (HPC)
- Computational fluid dynamics (CFD)
- Computer-aided engineering
- HPC video rendering
- Image Modeling
- Linux virtual desktops
- Introduction to HPC on Azure
- Identity in multitenant applications
- Choose an Active Directory integration architecture
- Integrate on-premises AD with Azure AD
- Extend AD DS to Azure
- Create an AD DS forest in Azure
- Extend AD FS to Azure
Internet of Things (IoT)
- Domain analysis
- Tactical DDD
- Identify microservice boundaries
- Design a microservices architecture
- Monitor microservices in Azure Kubernetes Service (AKS)
- CI/CD for microservices
- CI/CD for microservices on Kubernetes
- Migrate from Cloud Services to Service Fabric
- Azure Kubernetes Service (AKS)
- Azure Service Fabric
- Decomposing a monolithic application
- Introduction to microservices on Azure
- Choose a hybrid network architecture
- ExpressRoute with VPN failover
- Troubleshoot a hybrid VPN connection
- Hub-spoke topology
- DMZ between Azure and on-premises
- DMZ between Azure and the Internet
- Highly available network virtual appliances
- Segmenting Virtual Networks
- Code walkthrough
- Serverless event processing
- Serverless web application
- Introduction to Serverless Applications on Azure
- Linux VM deployment
- Windows VM deployment
- N-tier application with Cassandra (Linux)
- N-tier application with SQL Server (Windows)
- Multi-region N-tier application
- Highly scalable WordPress
- Multi-tier Windows
- SAP HANA on Azure (Large Instances)
- SAP HANA Scale-up on Linux
- SAP NetWeaver on Windows on Azure
- SAP S/4HANA in Linux on Azure
- SAP BW/4HANA in Linux on Azure
- SAP NetWeaver on SQL Server
- SAP deployment using an Oracle DB
- Dev/test for SAP
- Basic web application
- Improved scalability
- Multi-region deployment
- Web application monitoring
- E-commerce API management
- E-commerce front-end
- E-commerce product search
- Publishing internal APIs externally
- Securely managed web application
- Highly available web application
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!