The State of the Azure Platform and Landing Zones in 2021

A majority of the work that I have been focused on in the latter part of last year and early stages of this year has been focused on Cloud Enablement and Azure Foundation engagements, these engagements usually follow one of two patterns:

• Existing Azure customers that have stated on the Azure journey, but the environment has organically evolved and the customer is looking for a current state and alignment to the Microsoft Cloud Adoption Framework
• New customers that have made a strategic decision to move to Azure and are looking at setting up the core foundations to provide sustainable long term adoption of cloud services.

This post will focus on the 2nd bullet point and what needs to be done to design and implement a green-fields Azure Platform. Let’s set some context by starting with defining some Terminology, Key Principles & Critical Design Areas.

Terminology

• The Platform: The platform is comprised of Azure subscription(s) where all core Networking, Identity and Platform management services will be hosted. These subscriptions are generally static after creation and usually defined as a Tier 0 environment that should be tightly controlled from a Security and Governance perspective.
• Landing Zones: A landing zone is an environment for hosting applications and solutions, usually created as an immutable Azure Subscription pre-provisioned through code. A Landing Zone includes foundational capabilities & Shared Services (Governance, Identity, Networking and Security) that are leveraged from the Platform to provide the appropriate guard rails for the subscription.

Key Principles

The key principles below provide some examples of guidance to subsequent decisions across the key design areas of the Azure platform.

• Subscription democratization: Make subscriptions available to business units to support the design, development and testing of both new and migrated applications into Azure.
• Policy-driven governance: Azure Policy should be used to provide guardrails and ensure continued compliance within the platform.
• Single control and management plane: Provide a consistent experience for Platform and DevOps teams using role-based access and policy-driven controls.
• Application-centric and archetype patterns: Focus on application-centric migrations and development catering for both IaaS and PaaS application solutions.
• Align with Azure-native services: Advocate the use of Azure native services capabilities where possible whilst respecting existing investments in tool sets and solutions.

Critical Design Areas

There are Eight (8) critical design areas that map business and technical requirements to Azure constructs and capabilities that are used to build out the Platform and associated Landing Zones, these need to be addressed and key decisions made to ensure the requirements are met.

• Enterprise Agreement (EA) enrollment and Azure Active Directory tenants
• Identity and access management
• Management group and subscription organization
• Network topology and connectivity
• Management and monitoring
• Business continuity and disaster recovery
• Security, governance, and compliance
• Platform automation and DevOps

Over the last 6 months, the team has spent a lot of time and effort to re-architect the way in which we deliver the Azure Platform and Landing Zones and aligned this with the Microsoft Cloud Adoption Framework. We have leveraged the framework and Enterprise-Scale approach to provisioning the Azure Platform, but have also complemented this with our own IP and additional value adds that enhances the solution.

The following were outcomes that we wanted to achieve as part of the new offerings.

• All offerings should be modular and extensible
  • To cater for a variety of customer scenarios, deployment patterns and the cadence of changes and improvement to Azure capabilities.
• Leverage both native ARM and Terraform as options for deployment
  • Give options to customers who have a preference in the way they deploy Infrastructure as Code resources.
• Provide a consistent deployment experience via the Azure portal and programmatically
  • Not all customers are the same and their maturity differs.

We have recently adopted Git Hub Enterprise and are using this as our source control for these offerings, the image below outlines the Azure Resource Manager offerings, distinguished by the deployment topology and intended use.

So what does the deployment look like and what is included? Let’s look at a Traditional Hub & Spoke topology using a Single Platform subscription. The deployment uses conditional logic so you can define what is included and excluded during the provisioning.

• 1 - A scalable Management Group structure with associated Azure Role-Based Access Controls and Azure Policies where there is a clear separation of platform and workloads resources
  • Landing Zone Management Group for workload subscriptions (Production, Non-Production, Online, Corporate Connected)
  • A Sandbox Management Group for ideation and testing that is segregated from a network perspective
  • A Decommissioned Management Group for subscriptions that will be deleted
• 2 - Azure Policies that will enable autonomy and guardrails for the platform and the landing zones
  • Policies that are applied to the whole environment to enforce controls and governance
  • Policies that are applied at the child Management Group levels that focuses on more granular controls and governance
• 3 - An Azure subscription dedicated to the Platform that includes
  • A Log Analytics workspace and an Automation account for Platform monitoring
  • Azure Security Center (Standard or Free tier) to provide Cloud Security Posture Management capabilities
  • Azure Sentinel as the Security information and event management (SIEM) solution
  • Diagnostics settings for Activity Logs, VMs, and PaaS resources sent to Log Analytics
  • A hub virtual network and associated subnets, Network Security Groups and Route tables
  • Network Watcher for network management
  • Azure Firewall (deployed across Availability Zones) as cloud-native firewall
  • Azure Bastion for secure remote access to the environment
  • ExpressRoute Gateway (deployed across Availability Zones) to terminate ExpressRoute circuits
  • VPN Gateway (deployed across Availability Zones) to terminate Site-to-Site VPN connections
  • Azure Private DNS Zones for Private Link and Private Endpoints
  • An Azure Key Vault for secrets and key management
  • A Recovery Services Vault for Azure Backup
  • A pair of Active Directory Domain Controllers deployed in an Availability Set
  • An Azure Budget for tracking cost across the Platform subscription

Deployed Resource Groups:

Deployed Network Resources:

Deployed Monitoring Resources:

Azure Policy Assignments:

Conclusion

This offering provides a fully functioning and scalable Azure Platform, Landing Zone subscriptions can now be allocated to the associated Management Group for the deployment of workloads and solutions. Next time we will look at what we can do for existing Azure environments and how we can tackle that.