Skip to content

This is the IaaS baseline for Azure landing zones reference implementation as produced by the Azure Architecture Center.

License

Notifications You must be signed in to change notification settings

mspnp/iaas-landing-zone-baseline

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Infrastructure-as-a-service baseline for Azure landing zones

⚠️ This repo is still under active development by Microsoft patterns & practices and is not yet considered in a release state. ⚠️

This reference implementation demonstrates a recommended starting (baseline) infrastructure as a service (IaaS) architecture with special considerations for Azure landing zone integration. This implementation is a direct continuation of the IaaS baseline reference implementation, which did not have any Azure landing zone context.

Network diagram depicting a hub-spoke network with two peered virtual networks and main Azure resources used in the architecture.

Azure landing zone workload team focus

This repository and its deployment guide primarily addresses the workload team looking to build our their solution expected to be homed within an application landing zone. The platform team will be referenced throughout where their role in this solution would typically be required. However, their role will be abstracted out through proxy deployments and hypotheticals.

This deployment guide is written as if it will be deployed into a single sandbox subscription. Functions normally provided by your platform team will be included in this deployment, but purely a stand-in for your individualized Azure landing zone implementation.

You will walk through the deployment here in a rather verbose method to help you understand each component of this architecture so that you can understand what parts would map back to your responsibility as a workload team vs the responsibility of the partner platform team.

Azure Architecture Center guidance

This project has a companion reference architecture article that describe the architecture, design patterns, and other guidance for this implementation. You can find this article on the Azure Architecture Center at Infrastructure as a Service baseline for Azure landing zones. If you haven't reviewed it, please first read it to learn about the considerations applied in the implementation. Ultimately, this repository is the direct implementation of that specific architectural guidance.

Architecture

This architecture is infrastructure focused, more so than on the code deployed into it. It concentrates on the virtual machines, including concerns with identity, bootstrapping configuration, secret management, and network topologies, all with the explicit context that it's expected to be deployed within an application landing zone.

The implementation presented here is the minimum recommended baseline and should be considered your starting point for pre-production & production stages. This implementation integrates with Azure services provided by the platform team and those owned by you, the workload team, that will deliver observability and provide a network topology to help keep the traffic secure.

The material here is relatively dense. You will need to dedicate time to walk through this deployment guide, with a mind to learning. This repo does NOT provide any "one click" deployment. However, once you've understood the components involved and identified the shared responsibilities between your workload team and your platform team, it is encouraged that you build suitable, auditable deployment processes around your final infrastructure, aligned to your workload's needs.

Throughout the reference implementation, you will see reference to Contoso. Contoso is a fictional fast-growing startup that has adopted the Azure landing zones conceptual architecture to govern their organization's Azure deployments. Contoso provides online web services to its clientele on the west coast of North America. The company has on-premise data centers and some of their business applications are now about to be run from infrastructure as a service on Azure using Virtual Machine Scale Sets. You can read more about their requirements and their IT team composition. This narrative provides grounding for some implementation details, naming conventions, etc. You should adapt as you see fit.

The workload

This implementation uses Nginx as an example workload in the the frontend and backend virtual machines. This workload is purposefully uninteresting, as it is here exclusively to help you experience the baseline infrastructure running within the context of an application landing zone.

Core architecture components

Which Azure landing zone implementation?

Azure landing zone implementations are varied, by design. Your implementation likely will share some similarities with the conceptual architecture used here, but likely may deviate in significant ways. These ways could be as fundamental as a different NVA instead of Azure Firewall running from a Secured Virtual Hub in a Azure Virtual WAN to subtle things like an Azure Policy applied to your target management group that disallows a feature showcased in this implementation.

We acknowledge that you will need to map your organization's Azure landing zone realities onto this architecture. This architecture strives to follow an implementation similar to one described in Deploy Enterprise-Scale with hub and spoke architecture, and as such the deployment guide will reference key concepts like the "Connectivity subscription," "Subscription vending," or "Online" management group; to name a few.

You do NOT need to fully understand your own Azure landing zone platform implementation in order to use this deployment guide. You should be deploying into a single sandbox subscription; you will not be expected to connect to ANY existing networks or platform resources.

Application landing zone

The solution that we are deploying in this guide aligns with the Cloud Adoption Framework definition of an application landing zone with an application team management approach. See Platform vs. application landing zones as a reminder of the distinction.

Management group

Based on the common management groups definitions of "Corp," "Online," "SAP," "Sandbox," ...; this specific web app implementation would normally be expected to live under the "Online" management group, because that management group is defined as: "Online Landing Zones include all Virtual Networks that have internet-facing applications via an Azure Application Gateway (v2)." And does not align with "Corp" which is defined as: "Corp Landing Zones will include all Virtual Networks that do not expose public endpoints and that require connectivity to on-premises, as well as connectivity to other Landing Zones." Your IaaS workload however might be instead placed "Corp" or another based on its requirements. For this deployment guide, we'll assume similar policies are in place as found in "Online."

Deploy the reference implementation

Azure application landing zone deployments always experiences a separation of duties and lifecycle management in the area of prerequisites, the host network, the compute infrastructure, and finally the workload itself. This reference implementation acknowledges this. To make that clearer, a "step-by-step" flow will help you learn the pieces of the solution and give you insight into the relationship between them. Ultimately, lifecycle/SDLC management of your compute and its dependencies will depend on your situation (team roles, organizational standards, etc), and you'll need to implement as appropriate for your needs.

Please start this learning journey in the Build a platform landing zone proxy section. If you follow this through to the end, you'll have the recommended baseline infrastructure deployed, with an end-to-end sample workload running for you to reference in your own Azure subscription, mirroring a typical application landing zone implementation.

1. 🚀 Build a platform landing zone proxy

You are not the platform team, and you are not deploying this into an existing Azure landing zone platform topology, as such you need to set up a proxy version of key typical components to reflect the common resource organization found in Azure landing zones. Also, you to ensure you have the tools & access necessary to accomplish all of the tasks in this deployment guide.

2. Obtain an application landing zone

All application landing zone deployments need the actual subscription(s) the solution's resources will be deployed to. Most organizations have a subscription vending process to create these application landing zone subscriptions. Let's walk through the request and fulfillment

3. Deploy the solution infrastructure

This is the heart of the implemented guidance in this reference implementation. Here you will deploy the Azure resources for your compute and the adjacent services such as Azure Application Gateway, Azure Monitor, and Azure Key Vault.

You performed the prior steps manually here to help you understand the involved components, with the expectation that you'd implement this via an automated DevOps process. Therefore, incorporate the prior steps into your CI/CD pipeline, as you would any infrastructure as code (IaC).

5. 🏁 Validation

Now that the compute and the sample workload is deployed; it's time to look at how it's all working.

🧹 Clean up resources

Most of the Azure resources deployed in the prior steps will incur ongoing charges unless removed.

Related documentation

Contributions

Please see our contributor guide.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

With ❤️ from Microsoft patterns & practices, Azure Architecture Center.

About

This is the IaaS baseline for Azure landing zones reference implementation as produced by the Azure Architecture Center.

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Contributors 4

  •  
  •  
  •  
  •