Design Governance

Purpose

This page covers notes, labs, personal setup items, deviations, etc. covered in the Design Governance Learn module.

Design Governance

  • Governance ensures that rules and policies are enforced.
  • A good strategy controls applications, resources, standards, etc.
  • Targeted via hierarchical structure - top down/broad to narrow application
    • Typical four layers: management groups, subscriptions, resource groups, resources

Management Groups

Learn Link

  • Are containers that manage policies and compliance across multiple subscriptions
  • Management groups can support up to six layers
  • A limit of 10K management groups in a single directory
  • Each management group and subscription can only support one parent (1:n)

Management Group Design Considerations

  • Best practice is to try and keep them “reasonably flat”
  • Try to match it up to the company org chart (departments, sub groups, etc.)
    • Take into account geography for regional compliance considerations (UK vs US vs China)
  • Purpose built management groups
    • Dev, Prod, Test, etc.
  • Separate by sensitivity
    • Separate management groups for sensitive items vs internal business items.
      • “Out of scop” is the magic term for simplifying deployments. You can significantly cut down on policy management by defining and enforcing clear boundaries.

Subscriptions

  • Subscriptions can provide separate billing environments, such as development, test, and production.
  • Policies for individual subscriptions can help satisfy different compliance standards.
  • You can organize specialized workloads to scale beyond the limits of an existing subscription.
  • By using subscriptions, you can manage and track costs for your organizational structure.

Design For Subscriptions

  • Very dynamic requirements across different organizations - one size does not fit all
  • Group subscriptions that share policies under the same management group
  • Shared service subscriptions can group and isolate workloads
    • ExpressRoute, Virtual WAN, etc.
  • Separate resources into subscriptions to avoid resource limits
  • Similar to management groups, separate subscriptions around compliance boundaries
  • Keep network boundaries in mind
    • VNETs cannot be shared across subscriptions
      • Work around this via VNET peering and VPNS

Resource Groups

  • Logical boundary
  • Only resource metadata is is stored in the RG
    • You can logically assign geographic resources to a geographic resource group

Designing For Resource Groups

  • All sorts of considerations come into play - this is due to how flexible resource groups are
  • Try to have set policies but stay flexible
  • Different grouping practices
    • By type: All disks in a disk-rg group, all SQL DBs in a SQL-DB group, etc.
    • By application/lifecycle: All related resources for a particular App, VM, etc. in one RG
    • By access control, dev/test, etc.
    • By Department, location, billing, compliance, etc. are other considerations

Design For Tags

Keep a clear goal in mind when designing a tag strategy as it’s incredibly useful. Billing, automation, reporting, etc. can all utilize tags. Keeping them clean and concise with clear boundaries and usage is important. e.g. If one tag is used for reporting and automation, make sure that all resources under the reporting are applicable to the automation. If an automation script is designed to remove all resources with a tag, that tag had better not be applied for reporting purposes to a LOB resource.

  • Coordinate with stakeholders to make sure that desired information, functions, etc. are readily available
    • If Sales, Marketing, HR, etc. need certain data - plan for and tag appropriately from the beginning
  • Resource tags generally fall into five categories:
    • functional (tier:web, env:prod, etc.)
    • classification (compliance:pci, SLA:24hr)
    • accounting (department:finance, project:projects)
    • partnership (owner:user1, stakeholders:user1,user2,user3)
    • business purpose (process:support, impact:high, revenue_impact:low, etc.)
  • Constantly reevaluate convention and make sure it’s still meeting business needs
  • Apply via Azure policy and enforce the rules and conventions
    • Don’t require it on ALL resources as that can make things messy and useless

Design For Policies

  • Groups of related policies are called initiatives
  • Policies are inherited by downstream resources
  • Apply on-prem (or other tenants?) via Azure Arc
  • The compliance dashboard is great, however, there can be a delay
  • Non-compliant resource handling:
    • Deny, Log, Alert, Alter, Deploy

Design For RBAC

RBAC Flow Chart RBAC Flow Chart

  • An incredible tool to assist with principle of least privilege - as long as you design for it.
  • Consider assigning to groups instead of users - this cuts down on the number of role assignments
  • Custom roles can be shared between subscriptions that share Entra ID trusts
  • Permissions are the sum of the roles. e.g. cumulative, and it also follows hierarchal top-down inheritance. Reader on RG but Contributor on Subscription = Contributor access.

Design for Landing Zones

Landing Doc

I was kind of fuzzy on what these actually are with all of the marketing and corpo jargon. After the docs and and a YouTube video I’m pretty certain that it just boils down to this: It’s a template definition envisioning the structure of an Azure environment. There are migration focused templates where you’re jumping from your on-prem environment, and when you land, what does your Azure deployment/environment (landing zone) look like?

Small Scale Landing Zone blueprints exist for small scale and they lay down the core foundation of what you want to use.

Transitional architectures for pre-existing customers also exit.

There’s a Landing Zone questionnaire to help with cloud adoptions.

I wonder if these came about because customers were creating resources willy-nelly, designed themselves into problematic scenarios/corners, and then complained to Microsoft. Microsoft asks, “Why did you do that?” and the inevitable response is, “Because you let me? How else would it be done? What’s best practice?”.

I went ahead and deployed their option here in a test environment and, outside of some pain points around tenant root access (personal Outlook.com problems?) the process was pretty painless.

There are design choices that will result in cost increases. Items like defender, monitoring, etc. will incur charges. However, these should be fairly minimal and the security options are hit or miss depending on whether or not other solutions are in use. Regardless, taking a look at cost items post-deployment and evaluating the value of deployed services will always be necessary.

  • Deploying one of these is a sort of “Welcome to Azure” guided questionnaire. It’s really slick and I wish I had known about this from the beginning.
  • They define a target architecture and end state
  • Can include policies, resources, all sorts of just… everything
  • Take a step back, CI/CD deployment and configuration management. If the goal is to have a brand new deployment, author items as code, and deploy - what would it look like? The Landing Zone is that definition of everything in a well architected deployment.
  • It’s very similar to the Bicep prod deployments I’ve done before where policies, subscriptions, registrations, RBAC, VMs, Networks, etc. were all deployed en-mass.