May 07 2021 02:25 AM
May 07 2021 02:25 AM
I am looking for best practices or Diagrams that can assist me in designing Azure hybrid environment. I am beginner and don't have much experience on Azure. I want to prepare landing zones to start with Azure in Hybrid Model.
Currently, we don't have any design and don't use Azure services(Except Azure AD) for production environment. This is going to be initial setup that will act as base for future deployments so I want to configure things based on best practices.
Some ideas like hierarchal diagrams(Including Management Groups, Subscriptions, Resource Groups etc) for Management, Security and deployment of resources would be really helpful.
Can someone please suggest.
May 07 2021 09:47 AM
it is impossible to give a detailed recipe that works for every scenario. However, Microsoft has very good content that will help you into your decision making process. I guess you heard about the Cloud Adoption Framework. I am sharing the link to the Landing Zones documentation, but you'll find many other topics of interest around Azure adoption:
May 07 2021 12:24 PMSolution
May 19 2021 05:07 AM
Thanks for your feedback and time. I'll go through this and see if it helps.
One more thing, that I would like to know is that what is the general or most widely used method of organizing resources in Azure. For example - Is it good to have separate resource groups or separate subscriptions for different resources/services that we use in Azure.
May 19 2021 05:25 AM - edited May 19 2021 05:26 AM
Hi , you're welcome
From my experience i've seen two patterns :
- Group resources sharing the same lifecycle . It can be an application or a solution so you have all the components in the same resource group .
- Group resources by area so you will have monitoring tools in the same rg the security tools in other the networking tools or components in a different one . The idea behind is to leverage Role based access control and provide least privilege. For example a network engineer should able to manage networking components only and nothing else .
The subscription is at an higher level so you can have subscription for each environment
Dev Preprod Prod for example and in each subscription have the relevant resource groups whether they belong to this or that environment .Since there is a quota for some resources per subscription one subscription may not be enough ( Thousand and thousand of vms or containers) but you can still differenciate prod and non prod subscriptions and for the billing purpose it's quite interesting.