DEV Community: Sarah Lean 🏴󠁧󠁢

Can you recover a deleted Microsoft Entra Tenant?

Sarah Lean 🏴󠁧󠁢 — Tue, 23 Dec 2025 08:01:00 +0000

A question I am often asked is:

“If our Microsoft Entra tenant was ever deleted — could we recover it?”

It’s an uncomfortable thought, isn’t it? It’s not a scenario anyone wants to think about, but it is something you do have to think about as we rely so heavily on identities being available and secure and the thought of them not being there could be disastrous.

So let’s take the fear out of this topic and break down what’s really possible — and what needs to be planned for.

The Reality: Deleted Tenants Don’t Come Back

Here’s the straightforward truth:

There is no restore option for a deleted Microsoft Entra tenant.

Once it’s gone, it’s gone. A tenant isn’t like a user account or group that has soft delete or recovery windows options.

But before panic sets in, there’s something important to understand:

Microsoft has made deleting a tenant purposely difficult.

To delete a tenant multiple checks and conditions must be met first. All bills and invoices must be paid for, no users are in the Entra tenant, if you are syncing users from on-premises must be turned off, all subscriptions for Azure, Microsoft 365 etc must be removed. It’s not something that a rogue admin can casually click into existence.

Those safeguards are outlined here in Microsoft’s official guidance: https://learn.microsoft.com/azure/active-directory/enterprise-users/directory-delete-howto#prepare-the-organization

Still, even a very small possibility means organisations must treat tenant protection as a critical cybersecurity responsibility.

Defending the Irreplaceable

There isn’t one magic setting that guarantees protection and that’s actually good news. Instead, there are different layers that can be put in place to defend against the exact scenario we worry about. Those layers include:

Break-glass accounts locked down with strict policies
Privilege elevation that expires after use
Risk-based access decisions powered by Identity Protection
Conditional Access and multi-factor authentication (MFA) to stop one compromise becoming many
Alerting on high-impact directory changes

Together, these significantly reduce the likelihood of a tenant-level disaster.

A Shared Responsibility

It’s easy to assume that because Microsoft delivers the identity platform, they must also guarantee tenant-level recovery. But that isn’t how the cloud works. There is a shared responsibility model.

Microsoft Azure Shared Responsibility Model

Microsoft provides:

The platform
The guard rails
The tooling

Customers provide:

Their own risk-aligned configuration
Monitoring
Operational recovery planning

It’s a partnership, and like any partnership, both sides have a role to play.

Planning for the conversation you hope you’ll never have

Nobody wants to have those doom-and-gloom cybersecurity discussions. But this one matters, because identity is the centre of your cloud universe. So ask those uncomfortable questions, what would we do, who would respond, and how quickly could we act.

It’s important to plan and ensure you have prevention in place, as prevention is your only true recovery plan.

How Pre-Sales Techies can use BANT to qualify opportunities effectively

Sarah Lean 🏴󠁧󠁢 — Tue, 16 Dec 2025 13:33:47 +0000

When you’re a pre-sales technical engineer who joins meetings with customers, you're often there to demo a product, answer technical questions, or validate that a proposed solution is the right fit. But there’s another layer to these meetings. The sales person needs to understand if this is a real opportunity worth pursuing.

And that’s where BANT comes in.

Even if you’re the technical expert in the room, knowing how BANT works lets you partner more effectively with the salesperson. You’ll notice key details, ask the right questions, and help move the project forward successfully.

What is BANT?

BANT is a simple framework used in sales to qualify opportunities. It stands for:

Budget – Does the customer have money allocated to solve this problem?
Authority – Are we speaking to the people who can make the decision?
Need – What is the actual business problem we’re solving?
Timeline – When does the customer want to move forward?

For the sales person, it’s about knowing whether an opportunity is real. For techies, it’s about listening for clues and helping your sales person gather this information in a natural way.

How Techies can help with BANT

Budget

Customers often raise cost concerns when discussing technical options. As a techie, you might hear things like:

“We already have Microsoft 365 E5 licenses, can we make use of any of that existing licensing?
“We’ve got a lot of tools, so we’re looking to consolidate, not add more..”

These are comments techies genuinely hear and signal whether money exists, whether cost savings matter, or whether the customer expects re-use of existing investments.

Authority

You can often tell who has influence by the types of questions they ask. If someone digs into integration, security, or long-term support, they might be a decision maker or key influencer.

To help techies spot influencers vs decision-makers, use clearer cues:

People asking things like “How will this integrate with our existing identity platform?” or “What impact will this have on our security posture?” often hold technical authority.
Someone asking “Will this meet our compliance requirements?” or “How does this align with our wider IT strategy?” is usually a senior stakeholder.

These help the reader understand that authority isn’t always “the boss”, sometimes it’s the architect who holds the keys. Need

This is where techies shine. When customers describe their current challenges, you can validate them and tie them back to outcomes. For example:

Customer: “We’re spending too much time checking logs manually”
Techie: “That’s driving up operational overhead, automation could free up your team for more valuable work.

This is an example of a techie listening, and translating issues into solutions or outcomes.

Timeline

Customers drop hints about timing all the time:

“We need to present options to the CIO next month.”
“Year-end change freeze starts soon - can this be implemented before then?”

When you hear these, take note. They are important details that you need to understand in order to help pull together a quote and understand how to prioritise this opportunity.

Tips for keeping it natural

You don’t need to sound like a salesperson to help with BANT. A few approaches that work well:

Ask clarifying questions – e.g., “What’s driving that timeline?” or “Who else will need to be involved in this project?”
Summarise back to the customer – “So the main issue is downtime, and that’s affecting customer orders?”
Share observations with your sales person afterwards – If something feels important in the conversation, mention it.

The customer might come to the meeting and give you all the information on budget, authority, need and timeline and you won’t have to ask. But if they don’t then make sure you do ask. These are important pieces of information to have so you can provide the correct quote or information for a customer in order to win the deal or sale.

Conclusion

BANT isn’t just a sales tool — it’s a framework that helps technical experts understand the bigger picture. When you listen for Budget, Authority, Need and Timeline, you’re not selling, you’re helping the customer get to the right outcome faster. You make the conversation smoother, and you help shape solutions that genuinely solve problems.

So next time you’re in a meeting, tune into the subtle hints customers drop. You’ll be surprised how much influence you have simply by noticing the details that others miss.

What is a tfvars file in Terraform and how do you use it?

Sarah Lean 🏴󠁧󠁢 — Tue, 16 Dec 2025 08:01:00 +0000

When you are using Terraform, one of the key principles is that you can write reusable and scalable code that can be used in multiple environments without you having to rewrite or duplicate it.

And this is where the tfvars file comes in. This file allows you to define and customise variable values quickly and efficiently making your deployments more consistent and much easier to manager.

What is a tfvars file in Terraform?

A tfvars file in Terraform is used to define input variable values for a Terraform configuration. This file allows you to supply values for variables, making it easy to customise deployments for different environments (such as dev, test, or prod).

There are a number of ways you can customise variables within a Terraform deployment; however using a tfvars file is the most common and efficient.

How to use tfvars files?

The best way to show you how to use a tfvars file is to walk through some example code. Let’s set up a project to define an Azure resource group,

# Define the Resource Group
resource "azurerm_resource_group" "resource_rg" {
  name = "rg-example"
  location = "uksouth"
  tags = {
    Environment = "Demo"
    Owner   = "Sarah Lean"
  }

You can find the full code here.

This base code works, however, we’ve hard coded information here, that will make it hard for us to use within other environments and we’ll need to duplicate code and ultimately waste a lot of engineer time changing those hard code values.

So let’s create some variables, we want variables for:

The resource group name
Location
Tags

Within your project folder, create a file called variables.tf and we’ll define our variables in there. Within each variable, we’ll include a description and a default value.

variable "Resource_group_name" {
  description = "The name of the resource group"
  type        = string
  default     = "azurergtechielass"
}
variable "Location" {
  description = "The Azure region to deploy resources in"
  type        = string
  default     = "Sweden Central"
}
variable "Environment" {
    description = "The environment for the resources"
    type        = string
    default     = "Demo"  
}
variable "Owner" {
    description = "The owner of the resources"
    type        = string
    default     = "Techie Lass"  
}

Now that our variables are defined, we need to change the Terraform code to refer to the variables.

# Define the Resource Group
resource "azurerm_resource_group" "resource_rg" {
  name     = var.Resource_group_name
  location = var.Location
  tags = {
    Environment = var.Environment
    Owner       = var.Owner
  }
}

Now if we were to deploy the Terraform code it would work fine and deploy an Azure resource group, using all the default values we defined in our variables.tf file.

Let’s create a tfvars file

Instead of using the default values, let’s define our own using the terraform.tfvars file.

Within your project folder, create the terraform.tfvars file and assign a value to each variable like this:

Resource_group_name = "techielass-demo-rg"
Location = "France Central"
Environment = "Blog"
Owner = "Sarah"

If we run a terraform plan we’ll see that Terraform is now pulling in the values from the tfvars file and not using any of the default values that we set initially.

Terraform plan command with tfvars file

Using multiple tfvars files for different environments

The benefit of using tfvars files for your variables means you can separate tfvars files for each environment, for example:

Dev.tfvars
Test.tfvars
Prod.tfvars

And then when you are running your deployment, you change your plan and apply commands to point to the correct tfvars file:

terraform plan -var-file="dev.tfvars"
terraform apply -var-file="dev.tfvars"

This means you don’t have to rewrite your code for each environment, and tweaking a tfvars file requires minimal time, meaning deployments can be faster.

Summary

Using a tfvars file as part of your Terraform deployments makes your code more flexible, reusable and efficient. By separating your variable values from your main configuration code you can avoid hardcoding values and make your code easier to maintain and scale across multiple environments.

How to use comments in Terraform

Sarah Lean 🏴󠁧󠁢 — Thu, 11 Dec 2025 13:36:03 +0000

In any type of code, there are moments when comments are useful for adding context or clarification. They help others quickly understand the purpose behind your work, improving how they interact with the code and reducing confusion.

In this blog, we’ll look at the different types of comments you can use in Terraform and how they can help keep your code clear and maintainable.

Types of comments in Terraform

Terraform supports two main types of comments, both designed to help add context or explanations to your code.

Single-line comments : Start with a # or // and are used for brief explanations or disabling specific lines of code.

Multi-line comments : These are enclosed in a comment block between /* and */ and are using longer explanations or commenting out blocks of code.

Regardless of which type you use, Terraform ignores comments entirely—they have no impact on the execution of your code.

How to add single-line comments in Terraform files

Single-line comments either start with a # or //. Both are supported, and you can use them interchangeably. Which one you use is entirely up to your personal preference. I personally use #.

Let’s look at some examples:

Terraform comments example

How to add multi-line comments in Terraform files

For multi-line comments, Terraform uses the standard /* ... */ syntax. Everything between these markers is treated as a comment and will not affect the execution of your code.

Let’s take a look at an example:

Terraform multi-line comment example

You can also use multi-line comments to temporarily disable code. In the example, you can see a section commented out, and my editor (VS Code) changes the text colour to make that visually clear.

Terraform multi-line comment example

💡

If you are enjoying this blog you might enjoy:

Best practices for commenting in Terraform code

Comments can be powerful when used well, helping future you (and your teammates) make sense of decisions, processes, and intent behind certain configurations. Below are some best practices to help keep your Terraform code clean and understandable.

Focus on intent : Your Terraform code should be mostly self-explanatory. Use comments only when they genuinely add value or explain decisions.
Manual processes : Some configurations require manual steps. Use comments to flag any actions that need to happen before the code is executed, helping ensure nothing is overlooked..
Avoid sensitive information : Never include passwords, API keys, or other sensitive information in comments.
Avoid over commenting : Too many comments can clutter the code. Only include them where they genuinely help.
Standardise the comment style : Use a consistent format for comments, especially when working in teams, to help reduce confusion.

Conclusion

Comments can improve efficiency and collaboration, making your Terraform code easier to understand and maintain. The key is finding the right balance, too few comments and helpful context is lost, too many and your code becomes harder to read.

Aim for a healthy balance between comments and documentation. Keep longer explanations in proper documentation, leaving your Terraform files clean, clear, and easy to follow.

Deploying an Azure VM into an Availability Zone with Terraform

Sarah Lean 🏴󠁧󠁢 — Tue, 09 Dec 2025 08:01:00 +0000

High availability is a consideration that every Architect needs to think about when building cloud infrastructure. In Azure, Availability Zones help you achieve resiliency by distributing your resources across physically separate locations within a region. This ensures that even if one zone experiences downtime, your resources remain available.

Terraform, as an Infrastructure-as-Code (IaC) tool, makes deploying these resources simple, repeatable, and allows you to version control deployments. In this post, I’ll show you how to deploy an Azure Virtual Machine (VM) in a specific Availability Zone using Terraform.

Prerequisites

Before you start, you’ll need:

An Azure subscription.
Azure CLI is installed on your machine.
Terraform is installed on your machine.
Basic Terraform knowledge

Terraform configuration overview

I have uploaded the full Terraform configuration to GitHub so that you can retrieve the code from the repository there. I’ve tried to keep it small and tidy, with just three files:

variables.tf – defines the availability zone
main.tf – contains all the resource definitions
outputs.tf – prints out some deployment information at the end

Choosing a zone: variables.tf

We’ve defined a variable file, keeping it simple now, with the Azure Subscription ID and Azure Availability Zone in there.

variable "availability_zone" {
  description = "Azure availability zone (1, 2, or 3)"
  type        = string
  default     = "1"
}

This variable lets you choose which zone your VM should be placed in.

Azure identifies zones with string values "1", "2", and "3", so the Terraform variable is a string rather than a number.

Randomising the region: a quick detour

Before we get to the VM, there’s a small but fun addition in main.tf: a random region selector.

locals {
  azure_regions = [
    "ukwest",
    "westeurope",
    "francecentral",
    "swedencentral"
  ]
  selected_location = element(local.azure_regions, random_integer.region_index.result)
}
resource "random_integer" "region_index" {
  min = 0
  max = length(local.azure_regions) - 1
}

Each time you deploy, Terraform picks a random region from that list. This is something I use more often than not in my demos, but it might not be something you want to do in production, as you will probably need the predictability of where your resources are deployed.

Placing the VM in a zone: main.tf

The main.tf file might look busy at first glance. That’s because it handles a complete virtual machine deployment with all the necessary components within the file, such as resource group, virtual network, subnet, network security group (NSG), NIC, virtual machine and also saving the private key for access to the VM.

I’ve included all of this configuration to make it a great starter set for you; however if you already have existing networking, you can plug the VM into that.

The key section we want to focus on is when you are defining the VM configuration, you can define the availability zone that the VM should deploy into:

resource "azurerm_linux_virtual_machine" "vm" {
  name                = module.naming.linux_virtual_machine.name_unique
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  size                = "Standard_B1s"
  admin_username      = "azureuser"
  network_interface_ids = [
    azurerm_network_interface.nic.id
  ]
  zone = var.availability_zone
  admin_ssh_key {
    username   = "azureuser"
    public_key = tls_private_key.vm_key.public_key_openssh
  }
  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }
  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts-gen2"
    version   = "latest"
  }
}

How to deploy

To deploy this Terraform configuration, follow these steps:

Open a terminal and download the code to your machine:

git clone https://github.com/weeyin83/terraform-azure-vm-az.git

Open up your favourite editor, I like VS Code, and open up the Terraform folder you’ve just copied.

Create a new file named terraform.tfvars in the project folder. Add your details to it:

azure_subscription_id = "your-subscription-id"
availability_zone     = "1"  # Options: "1", "2", or "3"

Specifying your specific information and choices.

Once you’ve saved the file. Open up your terminal again, this time you need to log in to your Azure subscription.

Az login

Once logged in you can start the Terraform deployment. Prepare Terraform and download provider modules:

Terraform init

Then we can run the plan command to understand what the Terraform configuration will do:

Terraform plan

Once you are happy, you can confirm the deployment using:

Terraform apply -auto-approve

Within a few minutes, the resources will have been deployed and you can SSH using the output information to the Linux VM. And you can also check the Azure portal to check the availability zone deployment.

Conclusion

Deploying VMs in specific Availability Zones is a small Terraform configuration change, but can make a big difference in your resources’ resilience and allow you to follow design choices by your architects. Terraform helps you automate and manage this process efficiently, ensuring your infrastructure is reliable and easy to maintain.

What is Chaos Engineering?

Sarah Lean 🏴󠁧󠁢 — Tue, 02 Dec 2025 08:01:00 +0000

Technology has come a long way, but no system is ever completely safe from failure. Over the years, I’ve worked on and designed systems that try to reduce the risk of outages or failures, but nearly all systems experience some kind of downtime. Even the big companies are not immune to it, so how do they make sure their systems and services are reliable when something inevitably goes wrong?

That’s where chaos engineering comes in. It’s a practice that helps teams build more resilient systems by finding weaknesses before they cause real outages. In this blog post, we’ll explain what chaos engineering is in simple terms, how it relates to DevOps and Site Reliability Engineering (SRE).

What is Chaos Engineering?

Chaos Engineering is a methodology that IT teams can use to identify vulnerabilities in complex systems by intentionally injecting failures into the system and observing how that system responds.

Think of it like office fire drills, where they test that everyone knows where the fire exits are, fire alarm sounds, door opens etc.

Chaos Engineering is rooted in the principle of intentionally introducing faults into the system to bring benefits to the system in the longer run, such as increased system resilience, improved incident response, and validation of redundancy and failover mechanisms.

The evolution and history of Chaos Engineering

Most people associate the creation of Chaos Engineering with Netflix, however an AWS engineer called Jesse Robbins is also instrumental in the creation of chaos engineering practices.

Jesse drew on his experiences of being a volunteer firefighter to introduce the concept of GameDay at Amazon in the early 2000s, to simulate major failures in Amazon’s systems, test and improve their resilience.

Meanwhile, Netflix was looking at exploring ways to enhance resilience in their systems and in 2010 Netflix introduced a tool called Chaos Monkey which was designed to randomly terminate instances within their production environment to ensure that the system could tolerate failures without impacting users.

While both were working independently, both contributions were essential in shaping the modern practices of chaos engineering that are widely adopted today.

Chaos Engineering in SRE and DevOps

Chaos engineering is not just a testing technique; it’s a mindset that fits perfectly with Site Reliability Engineering (SRE) and DevOps practices.

SRE teams focus on building systems that are reliable, scalable, and resilient. Chaos engineering gives SREs a proactive way to validate system reliability before real incidents occur.

By running controlled chaos experiments, SRE teams can measure system reliability against SLIs (Service Level Indicators) and SLOs (Service Level Objectives), confirming that uptime and performance targets are met as well as identifying hidden weaknesses in infrastructure, dependencies, and failover mechanisms before they cause downtime.

And chaos engineering complements DevOps by promoting a culture of collaboration, continuous improvement, and shared responsibility for system reliability.

DevOps teams often integrate chaos experiments into CI/CD pipelines, running small, controlled tests after each deployment to ensure new code doesn’t break critical services. They may also run “game days”, where developers and operations staff deliberately trigger failures in a safe environment to practice response and improve system resilience.

By embedding chaos engineering into everyday DevOps and SRE practices, teams learn to anticipate failures, respond faster, and deliver more reliable systems and software.

Azure Chaos Studio

Chaos engineering is no longer just an experiment for a few tech giants, it’s becoming a standard practice for companies.

Microsoft offers Azure Chaos Studio, a managed service that enables teams to safely run chaos experiments in their Azure environments, helping organisations test resiliency across virtual machines, databases, and other cloud resources.

You can configure tests to simulate real-world failures against your virtual machines, Kubernetes clusters, databases and network components, all within a safe and monitored environment. You can run tests and leverage Azure Monitor and Application Insights to track system behaviour and understand the impact of failures.

Conclusion

Chaos engineering isn’t about breaking things for the sake of it, although that can be interesting; chaos engineering is focused on building confidence in your systems and making them more resilient before real incidents happen.

By intentionally testing failures your IT, DevOps and SRE teams can identify weaknesses, improve incident response and validate redundancy mechanisms.

Have you introduced chaos engineering into your IT practices?

Azure Storage Mover: How to migrate files from AWS S3 to Azure

Sarah Lean 🏴󠁧󠁢 — Tue, 25 Nov 2025 08:09:00 +0000

Moving files between environments can be a headache. Whether it’s from on-premises to Azure, or from AWS to Azure, there’s always the same challenge: how do you do it securely, at scale, and without reinventing the wheel? Traditionally, you might reach for tools like AzCopy, Azure Data Box, or Azure Migrate, but there’s a new option designed to make migrations smoother: Azure Storage Mover.

In this post, I’ll walk you through what Azure Storage Mover is, highlight its new cloud-to-cloud migration capability for moving data from Amazon S3 to Azure Blob Storage, and show you how to get started.

What is Azure Storage Mover?

Azure Storage Mover became generally available in February 2022, it was launched as a fully managed hybrid migration service that made moving your files and folders to Azure easy.

Azure Storage Mover can scale to meet the size of the migration you are trying to run, and jobs can be run as one offs or they can be run multiple times meaning you can sync deltas of any changes.

Earlier in 2025, a new feature was added to Azure Storage Mover, cloud-to-cloud migration. This allows you to securely transfer data from Amazon Simple Storage Service (Amazon S3) to Azure Blob Storage.

This feature is still in public preview, so is subject to change and there are some limitations to the product at the moment:

Private networking is not currently supported. The cloud-to-cloud feature securely transfers data by limiting S3 access to trusted Azure IP ranges, thus ensuring a controlled move of data over the public internet.
Each job supports the transfer of up to 10million objects.
A maximum of 10 migration jobs can happen at one time within a subscription.
If the data is stored within AWS Glacier or Deep Archive you must rehydrate it before you start the migration.

Create Azure Storage Mover resource

The first step you need to do to migrate data from AWS is create an Azure Storage Mover resource.

Go to the Azure Portal and in the top search bar search for Storage Movers.

Azure Portal, storage mover

Click on Create and you will be presented with the wizard asking for information about subscription, resource group, name and region for setting up the service. Fill in the relevant information and click on Next.

Azure Portal, storage mover

The next question set in the wizard is about monitoring, I’d recommend setting up logs that are sent to a Log Analytics workspace so you have logs to troubleshoot if things don’t go to plan.

The next screens within the wizard are about Azure Tags and confirming you are happy with the choices you have made. Click on Review + Create when you are happy to create the resource.

Create a multicloud connector for AWS

The next step is to connect a multicloud connector that allows you to securely connect AWS to Azure.

Navigate within the Storage Mover resource you just created and click on Overview then select the Multicloud migration tab.

Within the Multicloud migration tab, click on Create multicloud connector to open the Add AWS connector page.

Azure Portal, storage mover

Within this wizard you will be asked for information around resource group, subscription, the name of the connector, the Azure region and then which AWS account to associate the connector with and read resources from.

You have the option to pick a single account or use an organization account. For this example I am selecting a single account.

Azure Portal AWS Connector

Within the next screen you are asked which solutions you’d like to use with this connector. You have the option of Inventory , Arc onboarding and Storage - data management. For this example we’re going to add Inventory and Storage - data management.

Azure Portal AWS Connector

When you add the inventory solution you will be asked questions like which AWS services you wish to discover, which permissions you wish the connector to have, how often to want the scan to occur and which regions you want included in the scan.

Azure Portal AWS Connector

Configure as appropriate to your organisation and needs.

On the next screen, you will be given an AWS CloudFormation template to download or copy. You should take this and deploy it within your AWS environment, then come back and complete the wizard within Azure.

💡

This CloudFormation template sets up AWS IAM roles and an OIDC identity provider to allow Microsoft Azure services to securely access AWS resources. Azure authenticates via the OIDC provider using a connector ID, and the template outputs the ARNs of both roles for easy reference.

Configure source and target endpoints

Now that your AWS connector is set up and configured. You need to concentrate on your source and target endpoints. Now it’s assumed that you already have an endpoint in AWS, which will be an S3 account filled with files and folders.

If you don’t already have an Azure Storage account set up to receive the data, now is the time to do that. Also set up a container or file share within the storage account that you want the data to move to.

Configure project and job definitions

The setup is now complete, so it’s time to create a migration project and job definition.

A project allows you to organise large migrations into smaller, more manageable chunks, while a job describes resources and migration options. For example you can have a job set up to migrate a specific folder within the S3 bucket to a specific Azure Storage blob container and then set up another job to move other folders to an Azure Storage file share.

Within your Storage Mover resource click on Project Explorer on the left hand side. Then click on Create Project. Give your project a name and description and create.

Azure Portal storage mover

Once your project is created, click within it and then click on Create job definition.

Azure Portal storage mover

You’ll first be asked to give your job a name and description then asked to define the migration type, in this example we’re using cloud to cloud (preview).

Azure Portal storage mover

The next questions ask about the source, this is where you can define which S3 bucket you are moving data from. You have the option to take the whole bucket, or specific folders.

Azure Portal storage mover

Once you’ve configured this move to the next screen to configure the target, or Azure storage account you wish the files to move to. You have the choice of moving them to a Blob container or a File share within the storage account. And you also have the choice of defining a specific folder within either to move the files.

Azure Portal storage mover

The last screen you need to select an option in is what type of copy you want to do, a Merger content into target or Mirror source to target. Understand which option suits your scenario best.

Azure Portal storage mover

Mirror source to target: Makes the target an exact copy of the source. Extra files in the target are deleted, and everything else is updated to match the source.

Merge content into target: Updates files in the target to match the source but keeps any extra files already in the target. Renamed folders can sometimes create duplicates.

Once you’ve configured the job and it’s created you can now start it running.

Azure Storage Mover

Monitor migration progress

Within the Azure Storage Mover blade itself, you can see some visual progress of your jobs, successful jobs, failed jobs, files copied, files failed, etc.

And if you set up logs to go Log Analytics you are able to query logs there as well.

If you run the KQL query StorageMoverJobRunLogs within your Log Analytics workspace you will see all the jobs that have run, success or failure.

Azure Log Analytics

For more sample KQL queries to use, you can check out the official documentation.

Running regular syncs

The Azure Storage Mover is great if you need to sync files once, and you can do multiple syncs. For example, you can run the job initially to get the files into Azure, but then if you want to do a delta sync a week later, you can run your job manually again.

If you wish to run the job on a schedule or automate the running of it. You can use the Azure CLI command:

az storage-mover job-definition start-job \
  --resource-group <resource-group-name> \
  --storage-mover-name <storage-mover-name> \
  --project-name <project-name> \
  --job-definition-name <job-definition-name>

Or you can use the PowerShell command:

Start-AzStorageMoverJobDefinition `
  -ResourceGroupName <resource-group-name> `
  -StorageMoverName <storage-mover-name> `
  -ProjectName <project-name> `
  -JobDefinitionName <job-definition-name>

Both commands need the following parameters defined:

--resource-group : The name of the resource group containing your Storage Mover resource.

--storage-mover-name : The name of your Storage Mover resource.

--project-name : The name of the project within your Storage Mover.

--job-definition-name : The name of the job definition you wish to execute.

Final thoughts

Azure Storage Mover can help make cloud migrations easier, more secure and flexible. Whether you need to move files from on-premises, another cloud or sync deltas regularly, Storage Mover gives you a fully managed and scalable solution.

The new cloud-to-cloud migration feature even though still in preview simplifies the transfer of data from Amazon S3 to Azure Blog Storage while still maintaining security and cloud.

Cost Optimization in Azure: Using the FinOps Toolkit to Save Money

Sarah Lean 🏴󠁧󠁢 — Thu, 06 Nov 2025 08:01:00 +0000

Cost optimisation. It’s important in all walks of life, whether you are looking after your household bills or your cloud environment.

When we look at Azure there are tools and mechanisms that can help you monitor your costs, from Azure Advisor to Cost Alerts.

Within this blog post we’ll look at some of the resources with the Azure FinOps toolkit that can be deployed to help keep a monitor of your costs.

What Is the Azure FinOps Toolkit for cost optimization in Azure?

The Azure FinOps toolkit is a set of resources that can help you manage your Azure Costs and FinOps journey. There are alerts, workbooks and PowerBI reports that can be deployed.

It is an open-source project that is maintained and owned by Microsoft but the community over the years has also contributed to it.

There are two resources within the toolkit that I would recommend you look at as the very minimum you can do for cost optimisation.

How to use the FinOps Toolkit Alerts for Azure Cost Savings

Within the toolkit is something called “FinOps alerts”. This resource is a Logic App than can be scheduled to run regularly and check if you have any of the following that might be costing you money unnecessarily:

Idle App Gateways
Idle disks
Idle IP Address
Idle Load Balancers
Disk snapshots older than 30 days
Stopped virtual machines

The Logic App checks the subscriptions you tell it to and if it finds any of the above resources it generates an email that you can send to a person in your team or your IT Service Desk to action.

It’s a light weight deployment that can be up and running within 5-10minutes.

Let’s walk you through the deployment.

The first step is to visit: https://microsoft.github.io/finops-toolkit/alerts#deploy

Click on the correct Deploy button on the website, in this example I am selecting Deploy to Azure.

Azure FinOps Toolkit

This will launch the Azure ARM template custom deployment within the Azure portal. You will be asked which subscription, resource group, Azure region, and the name you wish to use for the Logic App.

Once you’ve filled in the information click on Review + Create. Then click on Create.

Azure Portal custom deployment

It will take a few minutes for the deployment to complete. Once it has there are some things you need to configure for the Logic App to work.

Go into the Logic App and click on Edit.

Azure Logic App

If you click on the Recurrence step you can configure how often you want the Logic App to run, by default it will run once a week.

Click on the Set alert recipient step. Within the value section, enter the email address where you want the email to be sent.

Azure Logic App

Now click on Included subscriptions , within the value section enter the subscription ID or IDs you want the Logic App to scan.

The format for just one subscription should be:

["12345678-aaaa-bbbb-cccc-1234567890ab"]

The format for multiple subscription IDs should be:

[
  "11111111-1111-1111-1111-111111111111",
  "22222222-2222-2222-2222-222222222222",
  "33333333-3333-3333-3333-333333333333"
]

Azure Logic App

If there are any subscriptions you’d like to exclude from being scanned, make sure you enter that information within the Excluded subscriptions.

Next scroll down to the bottom of the Logic App and click on the Send an email (v2) step. Click on change connection , then select ** Add new**. It will ask you to sign into your M365 account and confirm the connection with your M365 to be able to send the email.

Azure Logic App

Don’t forget to click on Save after you have made the changes.

Azure Logic App

You can now manually start the Logic App by clicking on Run.

Analysing Azure Costs with FinOps Toolkit Workbooks

Azure workbooks can provide an interactive way to view and analyse data. Within the Azure FinOps toolkit are two workbooks, one called Governance and one called Optimisation.

The Optimisation workbook gives you a comprehensive overview of your Azure environment's resource usage, aligning with the Well-Architected Framework Cost Optimisation pillar.

The Governance one provides a comprehensive overview of the governance posture of your Azure environment.

To deploy these workbooks, head over to https://microsoft.github.io/finops-toolkit/workbooks

Click on the deploy button for you, in this example, I am going to select Deploy to Azure.

Azure FinOps Toolkit

This will launch the Azure Portal and the custom Azure ARM template deployment. You’ll be asked to select a subscription, a resource group, an Azure region and a name to prefix each workbook with.

Click on Review + Create. Then click on Create.

Azure custom deployment within the Azure Portal

It will take a few minutes for the workbooks to be deployed. You can go to the deployed resources and start to view and interact with the workbooks.

They are great for spotting issues with your governance and also where you can make some cost savings and optimisations within your environment.

Final Thoughts on Cost Optimization in Azure

The Azure FinOps toolkit is a powerful collection of resources to help you implement FinOps practices and monitor cost optimization in your Azure environment. Even using just the alerts and workbooks, you can quickly identify idle resources, spot opportunities to save money, and keep your cloud spending under control.

Take the time to explore the toolkit, experiment with its features, and tailor it to your organisation’s needs. By proactively monitoring your environment, you’ll not only reduce costs but also gain better visibility into your cloud resources, a key step toward more efficient, sustainable cloud operations.

Automating Azure SFTP deployment with Terraform

Sarah Lean 🏴󠁧󠁢 — Tue, 04 Nov 2025 08:01:00 +0000

In a previous blog, I walked through how to set up SFTP on Azure step-by-step through the Azure Portal. That’s a great way to get familiar with the service, but if you're deploying this regularly, across different environments, for multiple clients, or as part of a DevOps process, you need a way to automate it.

That’s where Terraform comes in.

Terraform is an Infrastructure as Code (IaC) tool that allows you to define and deploy Azure resources using configuration files. This means you can create your Azure SFTP setup in a version controlled way and replicate it in multiple environments with minimal effort.

The Terraform Code

I’ve published a GitHub repository containing the Terraform configuration you need to create:

An Azure resource group
A premium block blob storage account
SFTP enabled on that storage account
A local SFTP user with password authentication
An initial container for file storage

You can clone the repo and follow the tutorial below to deploy the SFTP setup to suit your needs.

git clone https://github.com/weeyin83/sftp-azure-terraform.git
cd sftp-azure-terraform

Pre-requisites

An Azure subscription
Basic understanding of Azure
Basic understanding of Terraform
Visual Studio Code (or similar) installed on your machine
Azure CLI installed on your machine
Terraform installed on your machine

Customising the deployment

Within the GitHub repo I have created the following files:

main.tf - Main Terraform configuration
variables.tf - Variable definitions
outputs.tf - Output definitions

Within the variables.tf file, I have defined defaults for each variable that needs inputs. You can either change that file directly, or, the way I prefer to work, create a .tfvars file and define the variable details there.

To do that, create a new file and name it something like prod.tfvars.

Within the file copy the following and then replace them with values that make sense for your deployment

location = "yourazurelocation"
account_replication_type = "LRSorZRS"
container_name = "containername"
sftp_local_user = "username"
tag_environment = "environmentname"
tag_project = "projectname"
tag_creator = "creatorname”
azure_subscription_id = "azuresubscriptionid"

With this file in place we can start to deploy the Terraform code. Ensure that you are are logged into your Azure environment through your command line tool. First, run terraform init in the command line. This will download any required providers needed to deploy the Terraform code.

Then run terraform plan -var-file="prod.tfvars". This will plan out any changes and new resources that need created within your environment to match the template file.

Then you can run _ terraform apply -var-file=”prod.tfvars” , if you add on _-auto-approve then it will deploy the resources without any further prompts or confirmation from yourself.

💡

If you need a refresher on Terraform and the deployment process you can check out my "Introduction to Terraform” blog post.

Once the deployment is finished, the console will output the SFTP hostname and username you need to connect. The password will not be shown initially, as it is a sensitive value.

Terraform output

To see the password you can type the following into the console:

terraform output -raw sftp_password

This will display the password in clear text for you.

You have now created the Azure SFTP setup and have the information required to connect to it and upload, download and share files.

Managing costs

Just like I mentioned in the manual setup guide, remember SFTP in Azure costs $0.30/hour while it’s enabled. If you don’t need it running 24/7, consider automating the enable/disable process. This can be handled with the Azure CLI, PowerShell, an Azure Automation Runbook, or you could even re-run the Terraform template, changing line 69 of the main.tf file to “false” to disable the SFTP feature.

Wrapping Up

Using Terraform to deploy Azure SFTP means you can spin up secure file transfer endpoints quickly and consistently. However, if you are new to the Azure SFTP offering, I recommend checking out my original blog post for a deeper explanation of what SFTP is, how Azure supports it, and how to connect.

What is Grafana?

Sarah Lean 🏴󠁧󠁢 — Thu, 30 Oct 2025 08:01:00 +0000

Monitoring is essential to the health and performance of any IT system, whether it’s running in the cloud, on-premises, or somewhere in between. Without the right visibility into your environment, issues can go unnoticed until they cause downtime or impact your users.

In this blog post, let’s explore one of the monitoring tools, Grafana.

What is Grafana?

Grafana is an open-source analytics and interactive monitoring platform. It allows you to ingest data from a variety of sources, query it, create alerts, and build dashboards to visualise trends and performance metrics.

The visualisations and alerts help you transform raw metrics into actionable insights, allowing you to identify patterns, troubleshoot issues, and keep your infrastructure and applications healthy.

Grafana is fully open-source and backed by a large, active community. This gives you the flexibility to develop and share your own plugins or take advantage of those built by others.

You can choose to self-host Grafana, managing updates, backups, and scaling, or opt for a managed solution like Azure Managed Grafana, which handles all of that for you.

What data sources does Grafana use?

Grafana supports a wide variety of data sources, both out of the box and through community-developed plugins. Out of the box, the built-in data sources Grafana supports are

Cloud platforms : AWS CloudWatch, Azure Monitor, Google Cloud Monitoring

Time-series databases : InfluxDB, Graphite, OpenTSDB, Prometheus

SQL databases : Microsoft SQL Server, MySQL, PostgreSQL

Tracing & logging : Jaeger, Zipkin, Tempo, Loki

Other tools : Alertmanager, Elasticsearch, Pyroscope, TestData

Grafana features

Grafana has a rich set of features designed to make monitoring and data visualisation intuitive and powerful. You can create highly customisable dashboards, these dashboards provide a central place to view your infrastructure and application health at a glance. Complementing this is the alerting system that allows you to set up rules based on your data queries so you can receive timely notifications through channels like email or Slack, helping you to act on issues quickly.

For teams that want to integrate monitoring into their workflow or automate management tasks Grafana offers a comprehensive API that lets you programmatically manage dashboards, data sources and users. And sharing is straightforward too, you can easily share live dashboards or snapshots with colleagues helping to foster collaboration and work on troubleshooting any issues together.

In addition to those core features, Grafana supports templating to create dynamic dashboards, annotations to mark significant events on graphs, and a wide range of plugins for extended functionality.

When should Grafana be used?

Grafana shines when you need to aggregate data from multiple sources and visualise it in one unified dashboard. It excels at querying time-series events, analysing logs, and building custom queries to surface the exact insights you’re after.

Even if you only have a single data source, Grafana is still a powerful tool. It helps you track infrastructure utilisation, application performance, or even website user activity—all from one interface.

Azure Monitor dashboards with Grafana

In 2025, Microsoft introduced Azure Monitor dashboards with Grafana in public preview. This feature allows you to create Grafana dashboards free using data from Azure Monitor, metrics, logs, traces, Azure Monitor managed service for Prometheus and Azure Resource Graph data sources.

Dashboards with Grafana

This preview feature enables you to use Grafana’s powerful visualisations without the burden of managing or paying for a full Grafana deployment. You can create and edit dashboards directly in the Azure portal or deploy them using ARM or Bicep templates. You can build dashboards from scratch or import existing ones from the Grafana community.

There are some limitations with this feature as it doesn’t support Grafana evaluated alerts, reports, library panels, snapshots, playlists, app plugins, and copying panels across different dashboards.

While available at no extra cost in preview, usage may incur charges depending on the underlying data sources and Azure Monitor usage.

Azure Managed Grafana

Azure Managed Grafana is a fully managed Grafana service operated and supported by Microsoft. It’s optimised for Azure, with built-in support for Azure Monitor and Azure Data Explorer, along with integrated user authentication via Microsoft Entra. This makes it ideal for organisations that want to use Grafana’s full capabilities without the operational overhead of managing infrastructure, updates, or scaling.

Azure Managed Grafana

With high availability, automated upgrades, and integration into the Azure ecosystem, Azure Managed Grafana is a great option for teams focused on observability but short on time or resources for managing self-hosted deployments.

Conclusion

Monitoring is a critical part of maintaining a healthy environment, and Grafana offers a powerful, flexible platform to visualise and understand your data — no matter the system or source.

If you’re already using Azure Monitor, the Azure Monitor dashboards with Grafana preview is an excellent way to start exploring Grafana’s capabilities without the setup burden. Why not try creating your first Grafana dashboard today and see how it can transform your approach to monitoring?

How to onboard a Windows Server to Azure Arc

Sarah Lean 🏴󠁧󠁢 — Wed, 29 Oct 2025 08:01:00 +0000

Managing servers across on-premises, multi-cloud, and edge environments can quickly become complex. Microsoft Azure Arc helps solve this challenge by extending Azure’s management and security capabilities to servers running outside of Azure. In this guide, we’ll walk you through the process of onboarding a Windows Server to Azure Arc, from registering the required Azure resource providers to installing the Arc agent. Whether you’re testing with a single machine or rolling out at scale, you’ll see the different options available and how to get started.

Prerequisites

A Windows Server (2012 or later) with outbound internet access or proxy setup.
An active Microsoft Azure subscription

Register Azure resource providers

An Azure resource provider is a collection of REST operations that provide functionality for an Azure service.

To use Azure Arc-enabled servers, the following Azure resource providers must be registered in your subscription:

Microsoft.HybridCompute
Microsoft.GuestConfiguration
Microsoft.HybridConnectivity
Microsoft.AzureArcData

To enable them, you can use Azure PowerShell, Azure CLI or the Azure portal. We’re going to use Azure CLI this time.

Head over to https://shell.portal.com

Azure Portal CLI

Paste the following code into your shell window:

az provider register --namespace 'Microsoft.HybridCompute'
az provider register --namespace 'Microsoft.GuestConfiguration'
az provider register --namespace 'Microsoft.HybridConnectivity'
az provider register --namespace 'Microsoft.AzureArcData'

Azure Portal CLI

Options to onboard a Windows Server

There are multiple ways to install the Azure Arc agent onto an existing Windows server:

Add a single server
Add multiple servers
Add Windows Server with the installer
Add servers from AWS
Use the built-in Azure Arc Setup within Windows Server 2022 and later

For the “add a single server” and “add multiple servers” options, both require you to run a script on the server. The single server option is a script that is run on the target server and prompts you for your Azure login, so this is great for small environments, or maybe trying to get the agent installed on a troublesome server, but it’s not ideal if you have a large number of servers to get the Agent rolled out to.

The multiple server option is a script that handles authentication through a service principal, and you have the ability to use the script as something you run on servers manually, or run through tools like Configuration Manager, Group Policy or Ansible, enabling you to scale quickly and easily with your roll out of the agent.

The option to download a Windows Server Arc installer downloads an EXE that you run within the server and it will give you a graphical user interface to interact with to ensure the Arc agent is installed and registered to your Azure environment.

With the multicloud connector within the Azure portal, you can connect AWS resources to Azure using the Azure Arc agent.

And the last option available for Windows is within Windows Server itself. Since Windows Server 2022 an option has been built into the management of the server that allows you to walk through a wizard and connect your server to Azure using the Azure Arc agent. You can find the option to do that within the Server Manager.

Install Azure Arc on a single Windows server

From the Azure Portal , search for Server - Azure Arc

Click on the generate script box below Add a single server

Azure Portal Azure Arc

You will be met with a wizard asking for some information. You are asked to select the subscription, resource group, operating system (OS), connectivity and region. For this tutorial, ensure you select Windows as the OS and move to the next step.

Azure Portal Azure Arc

The next step is to populate any values for the suggested tags, or you can create your own.

Azure Portal Azure Arc

The last screen will show you the command to run on the Windows server. Copy this script and head over to your server.

Azure Portal Azure Arc

Open the Terminal on your server and paste in the script.

The script will run through and will open a browser for you to authenticate to your Azure environment.

Once the script has finished running, it will have installed the Azure Arc agent and connected it to your Azure environment.

If you head back into the Azure portal, you will see it listed as a connected server.

Azure Portal Azure Arc

What now?

With your servers Azure Arc enabled you have a lot of new avenues open to you. One of the biggest advantages is the ability to manage your on-premises and multi-cloud Windows Servers using the same Azure tools you already rely on in the cloud, such as Azure Policy, Defender for Cloud, etc.

If you are using Windows Server licences with Software Assurance (SA) you can also look at enabling Advanced Windows Server Management capabilities, which will give you access to things like:

Azure Update Manager
Azure Change Tracking and Inventory
Azure Machine Configuration
Remote Support

If you’re running older versions of Windows Server 2012, SQL Server 2012, or SQL Server 2014 Azure Arc can make obtaining and applying Extended Security Updates (ESU) much easier. Traditionally, ESUs required Software Assurance and a fair bit of manual setup and commercial negotiating, but with Azure Arc you can:

Seamlessly enable ESUs on eligible servers through the Azure portal.
Centralise billing for ESUs alongside your other Azure resources.
Automate patch delivery by combining ESUs with Azure Update Manager, reducing the risk of missed critical updates.

This integration means you can keep legacy systems secure while planning migrations or modernisation projects, without sacrificing visibility or adding extra complexity.

Estimate cloud costs with Terraform and Infracost

Sarah Lean 🏴󠁧󠁢 — Tue, 28 Oct 2025 08:17:23 +0000

Costing out your infrastructure has always been a challenge. Trying to compare vendors and options. It can be very time-consuming.

In this blog post, I aim to demonstrate how you can integrate a tool called Infracost into your Infrastructure as Code (IaC) workflow to help you accurately estimate cloud costs.

What is Infracost?

Infracost is a tool designed to estimate the cost of your infrastructure based on what you are deploying via your Infrastructure as Code (IaC) configurations.

It analyses what is being defined and deployed within your IaC files and provides a detailed overview of what costs you will encounter. When using Infracost, it allows your engineering teams to understand what impact deploying those resources will have and allow them to have the correct information to make informed decisions.

Currently, Infracost works with Azure, AWS and Google Cloud, but only works with Terraform. But the team is hoping to extend support to Pulumi, CloudFormation and Kubernetes. It can also be integrated into your CI/CD tooling, and support GitHub, GitLab and Azure Repos.

How to install Infracost and register

There are a few options in terms of how to install Infracost. I run Windows and use Chocolatey to help me install software so I am going to use that. For the other options, see the official documentation.

choco install infracost -y

After installing it, make sure it works by checking the version of it:

infracost –version

Once you have the software installed, you need to register to be able to use the tool. You can either sign up using your GitHub or Google account by running the following command:

infracost auth login

Estimating cloud costs with Infracost and Terraform

Now let’s use Infracost to estimate the cost of an Azure deployment defined in Terraform.

Let’s prepare some Terraform to estimate the cost of.

terraform {
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
      version = "~> 3.0"
    }
    azapi = {
      source = "Azure/azapi"
      version = ">= 2.2.0, < 3.0.0"
    }
  }
backend "azurerm" {
    resource_group_name = "rg-terraformstate"
    storage_account_name = "terraformstatetechielass"
    container_name = "tfstate"
    key = "tfdemo.env0.tfstate"
  }
}

provider "azurerm" {
  features {}
}

provider "azapi" {
  # Configuration options
}

resource "azurerm_resource_group" "rg" {
  name = "rg-demo-vm"
  location = "UK South"
}

resource "azurerm_virtual_network" "vnet" {
  name = "vnet-demo"
  address_space = ["10.0.0.0/16"]
  location = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

resource "azurerm_subnet" "subnet" {
  name = "subnet-demo"
  resource_group_name = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes = ["10.0.1.0/24"]
}

resource "azurerm_network_interface" "nic" {
  name = "nic-demo"
  location = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

  ip_configuration {
    name = "internal"
    subnet_id = azurerm_subnet.subnet.id
    private_ip_address_allocation = "Dynamic"
  }
}

resource "azurerm_windows_virtual_machine" "vm" {
  name = "win-vm-demo"
  resource_group_name = azurerm_resource_group.rg.name
  location = azurerm_resource_group.rg.location
  size = "Standard_D4s_v3"
  admin_username = "azureuser"
  admin_password = "P@ssword1234!"
  network_interface_ids = [
    azurerm_network_interface.nic.id,
  ]

  os_disk {
    caching = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "MicrosoftWindowsServer"
    offer = "WindowsServer"
    sku = "2019-Datacenter"
    version = "latest"
  }
}

We're creating an Azure Virtual Machine (VM) and supporting resources within our Terraform. Using that, let’s look at what the cost will look like for them. To do that, you must first go to the directory that holds your configuration files and run the following command:

infracost breakdown -- path .

Infracost output of estimated costs

There is also a VS Code Extension available for Infracost. It can help show you as you write the code what the price of your resources will be.

Infracost within VS Code showing estimated costs

Infracost Pricing

There are several plans available depending on how you want to use Infracost. There is a free plan with limited functionality that can be great for individual engineers or home projects. However, there are two paid plans available for those seeking more functionality and for larger teams.

The paid plans offer the ability to create dashboards, tagging policies, FinOpspolicies, Jira integration, custom price books, and much more, which will improve your FinOps practices.

Final Thoughts

Infracost brings much needed cost visibility into your infrastructure workflow. Whether you are experimenting on your own projects or working on production workloads. It's a great way to align technical decisions with financial impact.