Azure Landing Zones | Architectural Blueprint, Tooling & Best Practices

Video Transcript:

- Up next. We take a look at updates to the Azure landing zone guidance, which provides a proven best practice, architectural blueprint and tooling also sets you up for success. As you build new cloud based services and migrate or modernize what you already have, we'll show you new tools to assess where you are in your cloud journey and how to automate the build out of recommended foundational services to host your workloads and Azure. And to walk us through everything I'm joined today by Azure and Azure landing zone expert, Matt McSpirit. Welcome to mechanics.

- Thank you. Thanks for having me. It's good to be back to share the updates

- And thanks for joining us today. This is really an important topic because anyone who's building on the cloud a lot of the time, you know, you don't know what you don't know. So instead of going through the pain of experience, this gives you a clear path forward that really helps you to avoid specific gotchas from the get go.

- Exactly. And that's critical because oftentimes we see a driving force pushing you towards considering the cloud. Maybe you're in a data center, or as we saw with the pandemic, maybe you need to move fast to accommodate new circumstances for your organization. You also might have started experimenting with new services and before you know, it, that experimental workload is playing an essential role in your operations. And for various reasons, the long term foundation for your workload might be overlooked. So this is about setting up properly for future growth and scale, and not just about addressing the current realities.

- And I gotta say, what I love about the landing zone guidance is it's not just academic, like it L and it SMF guidance. That's stuff that I grew up with. You know, the tooling automates out the provisioning of recommended services for you.

- Absolutely. And that's something we'll dive into today. Services are pre-provision through code as running services with lines of separation, for sub workloads and user roles, which I'll explain more in a moment, there are real implementation lessons encapsulated in this approach so much so that the later sub updates to the architecture are a lot more prescriptive. It's now a single destination that builds out the services for scale security, governance, networking, and identity that you need for hosting your workloads and it's relevant, no matter your organization type or size. And with these services in place, you can run just about any app workload. Now on the periphery, you'll see identity and access management, policies for governance management and monitoring tools, networking, and other shared services. And at the center of the applications themselves, each with their own set of resources, including compute data and storage, plus how they interact with the foundational services.

- And the key here really is that, you know, this is all gonna be scalable and repeatable regardless of your workload type.

- Yeah. And it's a modular approach. You can extend what you deploy to various platforms, which might be workload specific. For example, building an app, running in a Kubernetes cluster, is gonna be different than managing an Azure virtual desktop environment. I wanna show you before was the simple architectural view. Now, if you look at a more detailed, but still high level view of the architecture, you'll notice at the center, everything is broken down. It's a separate subscriptions within Azure. There are subscriptions for identity, management and connectivity, and all of those subscriptions sit under the platform management group in the middle. You can see the more app specific landing zones with their own set of resources. Then you'll see decommissioned subscriptions and sandboxes for retired apps or apps in development. Now, the management group layer above all of these subscriptions is significant, cuz it means that each area can have their own unique policy controls and the right amount of separation.

- And this all sounds and, and looks like how an organization might decentralize their own operations, you know, using different departments or business units or even maybe their different app workloads.

- It does. And in fact, management groups and subscriptions are a great way to delegate control in a logical way. And along with policies, they're really the secret source to organizing your workloads for governance and scale. Now management groups help you create a logical grouping of subscriptions for services like networking, management and identity. And they're separated from your applications and workloads. Now this separation helps because the number of applications in your environment is gonna grow exponentially faster than the shared platform level resources, which are gonna have a one to many relationship with your apps. Then policies set, boundaries and rules that reduce the amount of manual intervention as your environment grows and protect against missteps like accidentally allowing a public IP address on something that shouldn't be accessible externally. They also ensure the right privileges and access permissions for the growing number of teams and stakeholders, interacting with your environment. As you scale.

- That said, this is great to know as you start to build out workloads, you know, but you might be at different stages operationally. So how does this then help organizations that might be in a different place?

- So while a destination's the same, built into the guidance is the acknowledgement that your starting point will be different. You can think of these phases as OnRamps. So if you're at the beginning of your cloud journey or starting from scratch, what we often call Greenfield, you'll be on the start OnRamp. This is like a blank canvas, and you can start with the right structures and services in place following the landing zone, guidance and tooling. Now, if you have an existing environment, this is what's sometimes referred to as brownfield. In this case, you're gonna have a few services perhaps running in a single management group or subscription in Azure. So you'd beyond the align on ramp where you'd need to do some modification, like establishing the right management group and subscription hierarchy to match the Azure landing zone, target architecture. And if you're already in line with best practices, with a few more workloads and progressing well, but looking to add a few more controls, we call this the enhance on ramp, for example, might be looking to add security controls like Microsoft Sentinel to an already mature operation. So you can focus your efforts depending on where your organization falls

- And with the exception of Greenfield, you know, there's a bit of nuance in terms of how you might choose between the align and enhance on ramps because you'd have to have a good handle for how far along your organization really is to get started.

- Right? It does require some investigation, but the good news is there's a new assessment that's just launched that can help with that. It's called the landing zone review and I'll walk you through it right now. Now to find it, just go to aka.ms/assessments and you'll land on the assessment home. Now I'm gonna select the Azure landing zone review here. You can choose your top interests and assess them individually. And if you just start with a few of these, you can always return and add more later now to save time I've pre-selected everything. And on the left, you can see the corresponding questions across categories. It's assessing things like our business priorities operating model and capabilities in our team. I'll hit start now, in my case, I've answered everything with some of the most typical responses. My organization's got a few workloads running in Azure, but we're looking to improve things.

- I'll fill in this last question and choose the second option. And now when I hit view guidance, it shows me my results. And as I suspected, it looks like I've got some room to improve on the right. You can see how my organization fares by category and we'd like to improve identity and management categories. In particular, when I scroll down first, I can see a few hero links for the Azure landing zones accelerator that I'll explain in a moment, a link to the cloud adoption framework guidance and the Azure migration and modernization partner program, where you can get help from partners in your area. Below that you'll see a custom set of recommended actions to take. As you implement Azure landing zones, I'll expand this one for identity, and there are three recommended actions here I can follow for configuring emergency access R back and logging in Azure monitor. And since management scored the lowest in my assessment, I'll expand that category and see three more recommended actions. In fact, I'll click on this one for workload management and it links me directly to design considerations in the cloud adoption frameworks ready resources. And I can immediately see here, for example, just how important it is to use Azure monitor for analysis insights and alerts.

- Okay, so now, you know, all the concepts behind landing zones, you've mapped everything out then tailored to your specific organization. How do you go about building out the landing zone?

- Well, now that we're ready to action this that's where the landing zone's accelerator comes in. So it's a fully automated Azure resource manager template that builds out the full architecture of management groups and subscriptions along with all the core services for the landing zone. Now, before you get started, your user account needs root level permissions for your Azure tenant, and you can check that from the Azure portal and your Azure active directory properties here under access management for Azure resources. And you can see I'm good to go. Now from there, I can navigate to aka.ms/alz, which takes me to the Azure landing zones documentation. And if I click this link on the right, it takes you to the accelerator. You'll see it takes me right to the section on the page. And with this button, I can start deploying my landing zone in Azure.

- Now, once I click that, it'll take me to a wizard experience walking me through the deployment. These settings comprise all the variables necessary to get everything configured in an opinionated way, reflecting the prescriptive architecture across the subscriptions that you define. I'll walk through all the tabs in the wizard. And again, to save time, I filled in most of the fields in advance. So here for deployment location, there are a few basic configs for directory and region. Then in Azure core setup, this is where you'll set up a short management group, prefix. I'm using Kentoso me. Next is platform management, security and governance, where you'll choose your management subscription and configure core management services. Then platform, DevOps and automation. This is where you'll connect your GitHub org and define a service principle. Now, in this case, you're not configuring an Azure subscription, but using GitHub as a proxy for that. And in my case, I won't deploy an integrated C I C D pipeline. So I'll select no above next in network, topology and connectivity. You define the connectivity subscription and have options to deploy a few toes to support your workloads under identity. You define the identity, subscription and associated network settings and the landing zone configuration. That's where you'll define subscription details, Vnet, configs, and additional settings below. Now I can run a validation check against everything and after I review everything one more time and it create it'll kick off the deployment.

- So now everything's running in terms of the deployment, how long does something like this take to complete and what does it produce?

- So this process will take several minutes to deploy everything. So let's fast forward a bit until the deployment is complete and you'll see the environment that's been created. So I'll start with the tenant hierarchy and take a look at the management groups. And when it expand this one for Kaso me, you'll get a good idea of our structure and that it matches our management topology along with the corresponding Azure subscriptions. And of course behind all this it's provisioned quite a few Azure services, policies and conflicts. It's all done for you. And by the way, if you're using Terraform, now there are options to create Azure landing zones at aka.ms/ALZ/terraform. We also have guidance on get hope for using Azure bicep directly to deploy resources at aka.ms.ALZ/Bicep.

- So you're ready to start building out different, uh, workloads inside of the environment with the right services and hierarchy in place as well. You know, we went through everything pretty quickly today, I think, and for anyone who's watching, looking to learn more or get started, what do you recommend?

- Well, the good news is you can get started today. First assess your organization where it lands and to get tailored recommendations, go to aka.ms forward slash/landingzonereview and start your review and everything I've shown today is part of the cloud adoption framework. You can find everything you need for landing zones at aka.ms/alz.

- Thanks Matt for joining us today and sharing all the updates to Azure landing zones. And of course, keep checking back to Microsoft mechanics for all the latest updates subscribe, if you haven't already. And thank you so much for watching.