DEV Community: DongAn

Mastering Azure Availability Sets: Fault Domains, Update Domains, and Best Practices

DongAn — Thu, 27 Nov 2025 04:26:42 +0000

When building infrastructure in Azure, high availability is non-negotiable. One of the fundamental tools for achieving this within a single datacenter is the Availability Set.

In this post, we’ll break down how Availability Sets work, the math behind Fault and Update domains, and the critical constraints you need to know.

What is an Availability Set?
An Availability Set is a logical grouping capability that ensures the Virtual Machines (VMs) you place within it are distributed across multiple isolated hardware nodes in a datacenter.

This distribution is crucial because it protects your applications from two specific types of disruptions:

Planned Maintenance Events: Handled by Update Domains.

Unplanned Hardware Failures: Handled by Fault Domains.

The Core Components: Fault vs. Update Domains
To understand how Azure protects your VMs, you need to understand the two dimensions of an Availability Set.

Fault Domains (FD) What they are: A Fault Domain represents a group of VMs that share common physical hardware, specifically a power source and a network switch (think of it as a physical server rack).

The Goal: To prevent simultaneous downtime caused by physical hardware failures (e.g., a power outage or a rack switch failure).

Configuration: By default, Azure assigns 3 Fault Domains per Availability Set (in most regions).

Distribution: Azure spreads your VMs across these domains. If you have 3 VMs and 3 FDs, each VM sits on a different rack.

Update Domains (UD) What they are: A logical group of hardware that can be rebooted at the same time.

The Goal: To protect against downtime during planned maintenance. When Azure needs to patch the underlying host OS, it will never restart more than one Update Domain at a time.

Configuration: The default is 5 Update Domains, but you can increase this up to 20.

Distribution: When maintenance occurs, UD1 reboots, then UD2, and so on, ensuring the other domains remain online to handle traffic.

The Logic: How VMs are Distributed
It helps to visualize how Azure places your VMs into these buckets.

Example Scenario: Imagine you have an Availability Set configured with 2 Update Domains and 3 Fault Domains. You deploy 3 VMs.

Update Domains: VM 1 and VM 2 might reboot first (UD0), followed by VM 3 (UD1).

Fault Domains: Each of the 3 VMs is placed on separate physical hardware (Rack 1, Rack 2, Rack 3) to maximize survival during a power outage.

The "Bucket" Calculation
What happens if you have more VMs than domains? They wrap around.

Let's say you have 14 VMs and you configured 10 Update Domains.

The Math:

The first 10 VMs fill UD0 through UD9.

The remaining 4 VMs wrap around and are placed in UD0 through UD3.

The Result:

4 Domains (UD0–UD3) contain 2 VMs each.

6 Domains (UD4–UD9) contain 1 VM each.

Risk Assessment: During a patch cycle for UD0, only 2 VMs will go offline simultaneously.

Critical Constraints & "Gotchas"
Availability Sets are powerful, but they come with strict rules.

Creation Only: You cannot add an existing, running VM to an Availability Set. You must define the Availability Set at the time of VM creation. If you need to add a VM later, you will have to recreate it.

Fixed Counts: Once the Availability Set is created, you cannot modify the number of Fault Domains or Update Domains. Plan ahead!

Managed Disks: Always use Managed Disks with your Availability Sets. This ensures that the disks are also placed in different storage clusters aligned with the Fault Domains, preventing a single storage failure from taking down the whole set.

The Resizing Rule
This is a common headache for administrators. If you need to resize a VM within an Availability Set (specifically to a size that requires different physical hardware), you often cannot just resize that one VM.

The Rule: You must stop (deallocate) ALL VMs in the Availability Set first.

The Reason: All running VMs in an Availability Set must reside on the same physical hardware cluster type. To move to a new size that the current cluster doesn't support, the entire set must be moved to a new cluster that supports the new size.

Summary
Fault Domains = Protection against Hardware/Power failures (Racks).

Update Domains = Protection against Microsoft Patching/Reboots.

Strategy: Combine Availability Sets with a Load Balancer to ensure your application remains accessible even when specific domains are down.

Resolve errors in "Build flexible Bicep files by using conditions and loops - Unit 5_Exercise."

DongAn — Wed, 24 Sep 2025 15:45:51 +0000

Several issues lead to errors in Unit 5, "Exercise - Deploy multiple resources by using loops," within the "Build flexible Bicep files by using conditions and loops" module on Microsoft Learn. Primarily, the main.bicep file lacks an environmentName parameter. This omission prevents control over the deployment environment, limiting the exercise to the creation of only the SQL server and SQL database, even when following the provided steps.

You can add the following snippet to your main.bicep file to solve the problem.

Another issue that can cause deployment failure is related to the Microsoft Learn sandbox. Due to unknown issues, attempting to deploy resources via Bicep code in the sandbox repeatedly led to my temporary account being deactivated. Even with remaining usage attempts, and after waiting for four hours to create a new account, the problem persisted. Therefore, for this exercise, it may be necessary to use an Azure pay-as-you-go account to complete the task.

Managing the environment with Azure CLI:
az deployment group create --resource-group Your-RG-Name --name main --template-file main.bicep --parameters environmentName=Production

After a successful deployment, your resource group should include the following resources:

The Concepts of building Reusable and Secure Azure Infrastructure with Bicep

DongAn — Tue, 23 Sep 2025 14:32:36 +0000

Introduction
In modern cloud adoption, the ability to deploy infrastructure reliably and consistently across multiple environments is not just a convenience—it's a necessity. This post details a project focused on a common and critical business scenario: migrating an on-premises web application and its database to Microsoft Azure.

The primary goal was to leverage Infrastructure as Code (IaC) to prepare the cloud infrastructure for three distinct environments: development, testing, and production. By using Bicep, we created a single, reusable template to ensure that each environment is a perfect replica of the others, eliminating configuration drift and streamlining the deployment process.

The Core Concepts
This project was built on three foundational pillars of modern cloud architecture:

Infrastructure as Code (IaC) with Bicep
Instead of manually creating resources through the Azure portal, we defined the entire infrastructure—an Azure App Service, its underlying plan, a SQL Server, and a SQL Database—in a declarative Bicep file. This approach treats infrastructure like application code: it's versioned, repeatable, and automated.
Reusability Through Parameterization
A single template was used for all environments. This was achieved by externalizing all environment-specific configurations (like resource names, pricing tiers, and instance counts) into parameters. We then used separate parameter files for each environment, making it easy to deploy a cost-effective "Free" tier for development and a resilient "Premium" tier for production without changing a single line of the core Bicep code.
Security-First with Azure Key Vault
Handling secrets like database credentials is the most critical aspect of automating infrastructure. This project integrated directly with Azure Key Vault. Instead of storing sensitive values in our code or parameter files, we stored them securely in a vault. The parameter file contains only a reference to the secret, not the secret itself. During deployment, the Azure Resource Manager engine uses this reference to fetch the secret securely, ensuring credentials are never exposed in our codebase.

Project Workflow
The end-to-end process was designed for security and automation:

Setup the Vault: First, we created an Azure Key Vault and securely stored the SQL administrator login and password as secrets.

Define the Infrastructure (main.bicep): We authored a comprehensive Bicep template that defined all resources and used parameters for dynamic values. We used decorators like @allowed and @secure to enforce governance and security rules directly in the code.

Configure the Environment (parameters.dev.json): For each environment, we created a corresponding parameter file. This file specified the SKU for the App Service, the SKU for the database, and, most importantly, the references to the secrets in Azure Key Vault.

Deploy with Azure CLI: The final step was a single Azure CLI command that combined the Bicep template with an environment-specific parameter file to deploy the resources. The process is idempotent, meaning we can run it repeatedly to enforce our desired configuration.

Key Takeaways and Conclusion
This project successfully demonstrates a best-practice approach to cloud infrastructure management. The key takeaways are:

Parameter Hierarchy is Crucial: Understanding that command-line parameters override parameter files, which in turn override defaults in Bicep, is key to building flexible templates.

Decorators Enforce Governance: Using decorators like @allowed and @secure shifts governance left, preventing non-compliant deployments before they even start.

Key Vault is Non-Negotiable for Secrets: The reference mechanism in parameter files is a simple yet powerful feature that enables a secure, auditable, and automated deployment pipeline.

By embracing these principles, any organization can build a robust, secure, and efficient process for managing its cloud infrastructure.

Auto-Adding Tags with Azure Policy

DongAn — Thu, 11 Sep 2025 16:42:53 +0000

Managing resources in Azure can quickly become complex, especially when it comes to cost management, governance, and organization. Tags are your best friend here, allowing you to categorize resources, but manually applying them is tedious and error-prone. This post will guide you on how to use Azure Policy to automatically add a tag and its value to newly created resources, explain a common mistake (like the one I faced!), and show you how to apply tags to existing resources.

The Goal: Auto-Apply a "Cost Center" Tag

Imagine you want every new resource created within a specific Resource Group to automatically get a Cost Center tag with a value of 000. This helps track expenses and assign accountability.

My Previous Policy: A Common Pitfall (and why it didn't work)

I initially tried to achieve this by assigning a policy, thinking it would simply add the tag. However, I kept running into a "Validation failed: Required information is missing or not valid" error when deploying new resources.

Here's why my previous approach likely failed:

The Problem: Using a "Deny" Policy for Tagging

My policy assignment, while appearing to enforce a tag, actually had a "Deny" effect.

What a "Deny" Policy Does: A "Deny" policy acts as a gatekeeper. It checks if the conditions (e.g., "does this resource have the 'Cost Center' tag?") are met before the resource is allowed to be created or updated. If the condition isn't met (i.e., the tag is missing), the deployment is blocked, and you receive a validation error. It doesn't modify anything; it just says "No."
Why it didn't work for auto-tagging: I wanted the tag to be added automatically, not for the deployment to fail if it was missing. A "Deny" policy is excellent for ensuring compliance (e.g., "NEVER deploy a VM without a 'Owner' tag"), but not for automatic remediation or addition.

The Solution: The "Modify" Policy Effect

To automatically add or update tags, you need to use a policy definition with the Modify effect. This effect actively intervenes during resource creation/update to ensure compliance.

Steps to Auto-Add a Tag Using Azure Policy (Modify Effect)

I will use the built-in policy definition: "Inherit a tag from the resource group if it is missing."

Navigate to Azure Policy:
- In the Azure portal, search for and select "Policy."
Delete Conflicting Policies (if any):
- If you have a previous "Deny" policy assignment related to the tag you're trying to auto-add, you must remove it first.
- Go to Assignments on the left menu.
- Find your old policy assignment (e.g., "Inherit the Cost Center tag...") and click the ... (ellipses) next to it.
- Select Delete assignment.
Assign the "Inherit a tag from the resource group if it is missing" Policy:
- Back in the Policy service, go to Assignments and click Assign policy.
- Scope: Choose the Management Group, Subscription, or Resource Group where new resources will be created. This is crucial for defining where the policy applies.
- Policy definition: Click the ... next to "Policy definition" and search for Inherit a tag from the resource group. Select the definition named "Inherit a tag from the resource group if it is missing".
- Parameters: Go to the "Parameters" tab.
  - For Tag Name, enter Cost Center.
  - For Tag value, you can leave it blank (it will inherit the value from the RG itself) or specify a default like 000 if your RG doesn't have it.
  - Crucial Setup: Ensure the Resource Group you're scoping this to itself has the Cost Center tag with the value 000. The policy inherits the tag from the resource group.
- Remediation (for existing resources - discussed below): For now, you can leave "Create a remediation task" unchecked. We'll explain this in the next section.
- Click Review + create, then Create.

Now, whenever you create a new resource within the assigned scope (your Resource Group), if it doesn't already have a Cost Center tag, Azure Policy will automatically add it with the value from the parent Resource Group!

Remediation: Applying Tags to Existing Resources

The Modify effect primarily works on newly created or updated resources. What about resources that already exist in your Resource Group and are missing the Cost Center tag?

This is where Remediation Tasks come in.

After assigning the "Modify" policy:
- Go to Policy -> Remediation in the Azure portal.
- Click + New remediation task.
- Select your newly assigned policy (e.g., "Inherit a tag from the resource group if it is missing").
- Select the scope (Resource Group) you want to target.
- Azure will identify non-compliant resources within that scope.
- Click Remediate.

This task will go through all existing resources in the specified scope that are non-compliant (i.e., missing the Cost Center tag) and apply the tag and its inherited value, bringing them into compliance.

Summary

Use the Modify policy effect to automatically add or update tags.
Avoid Deny policies if your goal is auto-tagging; they will block deployments.
Ensure the parent resource (like the Resource Group) itself has the tag if your policy is set to "inherit" the tag value.
Use Remediation Tasks to apply policies to existing, non-compliant resources.

By leveraging Azure Policy with the correct effects, you can enforce robust tagging strategies across your environment, improving governance and cost management without manual intervention.

Local development environment configuration for Azure CLI

DongAn — Sun, 31 Aug 2025 03:40:40 +0000

Install the following tools:
● Visual Studio Code with Azure Extensions
● The Azure CLI
● Configure your local Python environment for Azure
● The Azure Functions Core Tools, for local development of serverless functions.

Authenticate from your local shell. let Azure pop open a browser and go through their OAuth flow to authenticate you.

You can go to your local command prompt, and launch Azure Cloud Shell.

You need to open the link that the shell prompted, and enter Azure provided code.
After the authenticated, hit y to login.

Before you can use Azure Cloud Shell, you must register the Microsoft.CloudShell resource provider. Access to resources is enabled through provider namespaces that must be registered in your subscription.

1.On your subscription page, expand Settings in left menu and select Resource providers.

2.In the Filter by name... box, enter cloudshell to search for the resource provider.

3.Select the Microsoft.CloudShell resource provider from the provider list.

4.Select Register to change the status from unregistered/Re-register to Registered

PS: The first time you start Cloud Shell you're prompted to create an Azure Storage account for the Azure file share.

Set your subscription
1.List subscriptions you have access to:
az account list

By default, the command returns a JSON array. Each object in the array represents one Azure subscription and contains several key-value pairs.
name: The human-readable name of the subscription (e.g., "My Development Subscription").

id: The unique Subscription ID (a GUID). This is crucial for many CLI commands to specify which subscription you want to work with.

isDefault: A boolean (true or false) that indicates which subscription is currently active for your CLI session. Any commands you run will target the subscription where isDefault is true.

state: The current status of the subscription, most commonly "Enabled".

tenantId: The Microsoft Entra ID (formerly Azure Active Directory) tenant that the subscription belongs to.

Changing the Output Format
The default JSON output is great for scripting but can be hard to read. Use the --output (or -o) flag for better formatting.
az account list --output table

This command will display the subscriptions in a clean, tabular format, which is much easier for human eyes.

2.Set the active subscription for your session:
az account set --subscription 'my-subscription-name/my-subscription-ID'

PS: When you're done building something and don't need to run it anymore, delete the Azure resource group out of your organization. (If you've used proper infrastructure-as-code(IaC), you haven't lost anything - you can just deploy the code in a new account later!)