Deploying resources in Azure can be incredibly easy. With just a few clicks in the Microsoft Azure portal, you can set up an Azure SQL server, a database, and/or a virtual machine. This makes it a common approach when starting the migration to the cloud. Often, a person or group within the organization begins by running a Proof of Concept (PoC) in Azure to test and present specific functionalities.
This leads to multiple projects and/or PoCs within the organization being placed in the Cloud without any policy or structure. Initially, this is manageable, but over time it becomes cluttered and unstructured. To address this issue, the Cloud Adoption Framework (CAF) can be of great help. The CAF offers a wide range of documentation that can assist in implementing, migrating, managing, and optimizing the cloud environment.
In this blog, I'll delve into preparing cloud environments and explain what the CAF can offer, as well as why every organization should utilize this framework. Additionally, I'll provide some tips and examples that we use to implement structure and policy in the Microsoft Azure cloud.
The CAF is a Microsoft framework that offers best practices, documentation, and tools to facilitate cloud implementations. You can find more information about everything the framework encompasses in this link to Microsoft's documentation.
The framework provides examples of how to structure your cloud environment using the Azure landing zone architecture. This architecture leverages subscriptions to segregate cloud resources within the environment. Applications can utilize shared resources available from the platform, such as Azure Firewall, VPN gateway, and DNS zones. These resources are placed in the connectivity subscription, which is also referred to as the hub.
The landing zone architecture is designed to be scalable and applicable to all resources and future applications that can be developed in Azure. Whether it's applications for your front-end or your data environments, each application has its own subscription with its dedicated virtual network.
We implement the CAF using Infrastructure as Code, which allows us to establish a solid foundation in the cloud, providing the necessary structure.
In practical terms, this involves creating management groups, appropriately assigning subscriptions to the respective management groups, and ensuring seamless connectivity between networks within those subscriptions. The specific approach to achieve this connectivity depends on our customers' preferences. For instance, we may opt for solutions like Virtual WAN with virtual hubs or a hub-spoke model with virtual network peerings. This forms the foundational setup, which can be further customized and expanded based on the organization's requirements.
Below is the design of the conceptual Azure landing zone architecture from Microsoft. In the center of the image, we have the management groups and subscriptions. Additionally, we now have the 'landing zone zone A2 subscription' (spoke) visible, which is connected to the connectivity subscription (hub). This A2 subscription is just one of the numerous spokes in the hub-spoke model. Each spoke has its own dedicated subscription and virtual network, and they can utilize the resources available in the hub.
The hub serves as the central point through which all internet traffic flows, and it houses essential resources such as the Azure Firewall, VPN gateway, ExpressRoute, and/or Azure DNS. This setup ensures effective connectivity and management of resources within the cloud environment, providing a well-structured and scalable architecture for the organization's needs.
Source: What is an Azure landing zone? - Cloud Adoption Framework | Microsoft Learn
We roll out this foundation with Terraform. This is a well-known Infrastructure-as-Code-tool that we use to deploy all resources in Azure. Every customer is different, but there are always many similarities. To ensure that we must be able to support customer-specific resources, but at the same time also want to apply certain standardization, we use the CAF Enterprise Scale module in Terraform. This module is customizable so that we can apply it to any customer environment. The module helps to set the foundation as described above and at the same time ensures that we apply policy. In this module it is possible to define Azure policies.
At CloudNation we have a basic set of policies that we always use. One of these is setting the allowed locations in which the Azure resources may be located. The locations that we include here are, for example, 'west europe' and 'north europe'. We usually set this policy to the highest management group, so that all management groups below it and therefore all subscriptions must meet this condition. If someone wants to deploy a resource in an unauthorized location, for example in 'East US', this will be stopped by the policy and the deployment will not be possible.
A number of other policies that we often apply are; enable Microsoft Defender for each resource type, have each resource send its logging to the central log analytics workspace, set certain tagging automatically, enable azure monitor of all virtual machines, allow types of virtual machines and block the use of public ip addresses. This is a selection of policies that provide policy. Some policies do something within the cloud environment, such as setting the logging to the workspace. Other policies actually ensure that something is blocked. We often use the policy for the allowed types (skus) of virtual machines to ensure that extremely expensive virtual machines are not rolled out, which prevents surprises on the invoice.
Policies can be seen as a kind of guardrails for the cloud environment. Everyone can work within the guardrails, as soon as someone or a resource wants to go outside, this will be stopped. There will always be specific cases where exceptions have to be made, this is also possible. Exceptions can be created for specific resources, subscriptions or management groups so that specific cases are also possible.
Management groups have an activity log. All policy changes are recorded here for the relevant management group. This can be useful for troubleshooting if, for example, a policy causes certain blocks.
If you want to block something with an Azure policy, it is smart to first set the effect of the policy to 'audit'. The Azure portal shows which resources are affected by this policy so that you can set the policy to 'deny' at a later time. This way you can see what the influence could be before you implement the policy.
Having a reliable and flexible foundation that incorporates policy implementation simultaneously ensures an organized and structured cloud environment. This approach reduces the likelihood of surprises and grants you control over what is allowed and what is not within this environment. As a result, it instills a sense of security and confidence in the present and the future of your cloud endeavors. The CAF goes beyond just preparing the cloud environment; it offers a comprehensive set of resources. Therefore, I strongly recommend revisiting the documentation from time to time.
Moreover, on Monday, July 24, Microsoft made the Azure OpenAI Landing Zone reference architecture available. This architecture seamlessly aligns with the Landing zones suggested by the CAF, serving as a prime example of how the CAF prepares you effectively for the future.
Azure OpenAI Landing Zone reference architecture (microsoft.com)
The next blog will be more technical. In that blog, I will show you how to roll out a foundation with policies with Terraform.