| 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.
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.
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.
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.
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.
- Virtual machines executing within Virtual Machine Scale Sets
- Availability Zones
- Flex orchestration mode
- Monitoring: VM Insights
- Security: Automatic Guest Patching
- Virtual machine extensions:
- Azure Monitor Agent
- Preview Application Health
- Azure Key Vault Linux and Windows
- Custom Script for Linux and Windows
- Automatic Extension Upgrades
- Autoscale
- Ephemeral OS disks
- Managed Identities
- Azure Virtual Networks (hub-spoke)
- Azure Firewall managed egress
- Azure Application Gateway (WAF)
- Internal Load Balancers
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.
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.
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."
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.
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.
- Begin by ensuring you install and meet the prerequisites
- Deploy mock connectivity subscription
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
- Request your application landing zone
- Deploy a mock application landing zone subscription
- Prep for Entra ID based user authentication
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.
- Procure client-facing and service-to-service certificates
- Deploy the VMs, workload, and supporting services
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).
Now that the compute and the sample workload is deployed; it's time to look at how it's all working.
Most of the Azure resources deployed in the prior steps will incur ongoing charges unless removed.
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 opencode@microsoft.com with any additional questions or comments.
With ❤️ from Microsoft patterns & practices, Azure Architecture Center.