How to use Instance Mix with Azure Virtual Machine Scale Sets
When a Virtual Machine Scale Set needs to scale out, it normally uses a single VM size (also known as SKU). Whilst that is simple, it can also become a constraint. For example the scale out might be limited if that specific size has limited regional capacity, quota pressure, or a price profile that is not ideal for every scale-out event. Instance Mix for Azure Virtual Machine Scale Sets allows you to configure your scale out with more options by define multiple compatible VM sizes in a single scale set. When scaling out, Azure can choose from your list during provisioning based on the allocation strategy you select. What is Instance Mix? Instance Mix is a Virtual Machine Scale Sets capability that lets you specify up to five VM sizes for a single scale set that uses Flexible orchestration mode. Instead of setting the scale set to a single size such as Standard_D2s_v5 , you set the scale set SKU name to Mix and define the real VM sizes in the skuProfile . At provisioning time, Azure uses the skuProfile.vmSizes list and the selected allocation strategy to decide which VM size to deploy. The high-level model looks like this: { "sku": { "name": "Mix", "capacity": 2 }, "properties": { "skuProfile": { "vmSizes": [ { "name": "Standard_D2s_v5" }, { "name": "Standard_D2as_v5" }, { "name": "Standard_D2s_v4" } ], "allocationStrategy": "CapacityOptimized" } } } You can use this if your workload can run on more than one VM size and you want to improve provisioning success, optimize for cost, or align allocation with reservations or savings plans. When should you use Instance Mix? Instance Mix is a good fit when: Your application can run correctly on several similar VM sizes. You want scale-out to have more than one capacity option in a region. You run Spot VMs and want Azure to prefer lower-priced capacity when available. You have reservations for specific sizes, or want to favor VM sizes with better savings-plan economics, and need predictable priority. You want one scale set instead of several separate scale sets for equivalent worker capacity. It is usually best for stateless or horizontally scalable workloads, such as web front ends, API tiers, queue workers, batch workers, and other scale-out services where each instance performs the same role. Avoid using Instance Mix as a way to combine very different machines in one pool. For example, mixing a small general-purpose VM with a much larger memory-optimized VM can make capacity planning, load distribution, and performance troubleshooting harder. Best practice is to use sizes with similar vCPU and memory for balanced load distribution and similar VM types for consistent performance. Key requirements and limits Before you deploy, check these requirements: Requirement Detail Orchestration mode Instance Mix is available only for Virtual Machine Scale Sets using Flexible orchestration mode. Number of VM sizes You can specify up to five VM sizes. VM family support The Instance Mix skuProfile supports A, B, D, E, and F VM families. Architecture Do not mix CPU architectures. For example, do not mix Arm64 and x64 sizes in the same Instance Mix. Storage interface Do not mix incompatible storage interfaces such as SCSI and NVMe. Premium storage capability Do not mix VM SKUs that use premium storage with SKUs that do not. Security profile The selected sizes must use a compatible security profile. Local disk configuration The selected sizes must have a consistent local disk configuration. Quota You must already have quota for the VM sizes you include. Instance Mix does not request quota for you. Unsupported scenarios Instance Mix currently does not support Standby Pools, Azure Dedicated Host, Proximity Placement Groups, on-demand capacity reservations, or diffDiskSettings on the OS disk. Microsoft Learn currently states that all public Azure regions support Instance Mix. VM size availability and quota still vary by region and subscription, so you should check the exact sizes you plan to use before deploying. Choose an allocation strategy Instance Mix supports three allocation strategies. Strategy Best for Behavior LowestPrice Cost-sensitive and fault-tolerant workloads, especially Spot Azure prefers the lowest-priced VM sizes in the list while considering available capacity. It deploys as many of the lowest-priced VMs as capacity allows before moving to higher-priced sizes, so higher-cost sizes may be selected to secure capacity. This is the default strategy if you do not specify one. CapacityOptimized Production workloads where provisioning success is more important than the lowest possible price Azure prioritizes VM sizes that have the highest likelihood of available capacity in the target region. Cost is not considered, and higher-cost sizes may be selected to secure capacity. Prioritized Predictable ordering, reservations, or savings plan alignment Azure follows user-defined rank values on VM sizes when provided, subject to quota and regional capacity. Lower rank values have higher priority. This strategy is currently documented as preview. Rank note: Use rank only with Prioritized . Ranks are optional with Prioritized ; when specified, lower numbers have higher priority, and rank values can be duplicated or non-sequential. Omit ranks for LowestPrice and CapacityOptimized . For many operations teams, CapacityOptimized is a practical starting point for production scale sets because it is designed to improve the chance of successful provisioning. For Spot-heavy or highly cost-sensitive workloads, LowestPrice may be a better first choice. If you have reservations for specific sizes, or want to favor VM sizes with better savings-plan economics, use Prioritized and rank those reservation-backed or preferred sizes first. Walkthru Prereqs The commands below are Bash-specific. Use Azure Cloud Shell in Bash mode or another Bash environment with Azure CLI installed. You need: An Azure subscription. Permission to create resource groups, networking, and Virtual Machine Scale Sets. Azure CLI version 2.66.0 or later. An SSH-capable client if you plan to connect to the Linux instances. Check your Azure CLI version: az version --query '"azure-cli"' --output tsv Sign in and select the subscription you want to use: az login az account set --subscription "<subscription-id-or-name>" Set variables for the example: RG="rg-vmss-instancemix-demo" LOCATION="australiaeast" VMSS="vmss-instancemix-demo" ADMIN_USER="azureuser" You can change LOCATION to another public Azure region if you don't feel like sharing a datacenter rack with drop bears and the occasional kangaroo. Keep the VM sizes in the examples compatible if you change regions or families. Step 1: Check VM size availability in the region Before creating the scale set, check that the candidate VM sizes are available in your target region and subscription. az vm list-skus \ --location "$LOCATION" \ --resource-type virtualMachines \ --size Standard_D \ --all \ --output table For this walkthrough, we will use these D-series sizes: Standard_D2s_v5 Standard_D2as_v5 Standard_D2s_v4 In the az vm list-skus output, check the Restrictions column. If a size is restricted in your region or subscription, choose another compatible size or deploy in a different region. Step 2: Check quota Instance Mix does not automatically request quota. If one size in the mix lacks quota, Azure can try another size from the list that has quota. If none of the eligible sizes has enough quota, deployment or scale-out can fail. Check current regional VM quota and usage: az vm list-usage \ --location "$LOCATION" \ --output table Look for: Total Regional vCPUs The family quota rows that match your selected VM sizes, such as DSv5, DASv5, or DSv4 family vCPUs If quota is too low, either request a quota increase or choose sizes that have available quota in the target region. Step 3: Create a resource group Create a resource group for the demo: az group create \ --name "$RG" \ --location "$LOCATION" Step 4: Create a VM Scale Set with Instance Mix The key settings are: --orchestration-mode Flexible --vm-sku Mix --skuprofile-vmsizes --skuprofile-allocation-strategy Create the scale set: az vmss create \ --resource-group "$RG" \ --name "$VMSS" \ --location "$LOCATION" \ --orchestration-mode Flexible \ --image Ubuntu2204 \ --vm-sku Mix \ --skuprofile-vmsizes Standard_D2s_v5 Standard_D2as_v5 Standard_D2s_v4 \ --skuprofile-allocation-strategy CapacityOptimized \ --instance-count 2 \ --admin-username "$ADMIN_USER" \ --generate-ssh-keys This creates a Flexible orchestration scale set with two instances. Because the scale set uses Instance Mix, the scale set SKU name is Mix , and the allowed VM sizes are stored in skuProfile.vmSizes . Do not expect every VM size in the list to appear immediately. Azure may deploy all initial instances using the same VM size if that satisfies the selected allocation strategy and capacity is available. The point of Instance Mix is to give Azure more eligible choices during provisioning and scaling. Step 5: Verify the Instance Mix configuration View the complete skuProfile : az vmss show \ --resource-group "$RG" \ --name "$VMSS" \ --query "skuProfile" \ --output jsonc Example output: { "allocationStrategy": "CapacityOptimized", "vmSizes": [ { "name": "Standard_D2s_v5" }, { "name": "Standard_D2as_v5" }, { "name": "Standard_D2s_v4" } ] } View only the configured VM sizes: az vmss show \ --resource-group "$RG" \ --name "$VMSS" \ --query "skuProfile.vmSizes[].name" \ --output tsv View only the allocation strategy: az vmss show \ --resource-group "$RG" \ --name "$VMSS" \ --query "skuProfile.allocationStrategy" \ --output tsv List the current instances and their VM sizes. Because Flexible orchestration instances are standard Azure VMs, use az vm list for full instance details and filter by the scale set resource ID: VMSS_ID=$(az vmss show \ --resource-group "$RG" \ --name "$VMSS" \ --query id \ --output tsv) az vm list \ --resource-group "$RG" \ --query "[?virtualMachineScaleSet.id=='$VMSS_ID'].{Name:name, VMSize:hardwareProfile.vmSize, ProvisioningState:provisioningState}" \ --output table Step 6: Scale out and observe allocation Scale the set from two instances to five: az vmss scale \ --resource-group "$RG" \ --name "$VMSS" \ --new-capacity 5 List the instances again: VMSS_ID=$(az vmss show \ --resource-group "$RG" \ --name "$VMSS" \ --query id \ --output tsv) az vm list \ --resource-group "$RG" \ --query "[?virtualMachineScaleSet.id=='$VMSS_ID'].{Name:name, VMSize:hardwareProfile.vmSize, ProvisioningState:provisioningState}" \ --output table You may see one VM size or several VM sizes. The result depends on allocation strategy, quota, regional capacity, and the sizes in your skuProfile . Step 7: Add autoscale Instance Mix does not require autoscale, but it becomes especially useful when a workload scales out under demand. Autoscale asks the scale set to add instances; Instance Mix gives Azure multiple eligible VM sizes to use for those new instances. Create an autoscale profile: az monitor autoscale create \ --resource-group "$RG" \ --resource "$VMSS" \ --resource-type Microsoft.Compute/virtualMachineScaleSets \ --name "vmss-autoscale" \ --min-count 2 \ --max-count 10 \ --count 2 Create a scale-out rule that adds two instances when average CPU is greater than 70 percent for five minutes: az monitor autoscale rule create \ --resource-group "$RG" \ --autoscale-name "vmss-autoscale" \ --condition "Percentage CPU > 70 avg 5m" \ --scale out 2 Create a scale-in rule that removes one instance when average CPU is less than 30 percent for five minutes: az monitor autoscale rule create \ --resource-group "$RG" \ --autoscale-name "vmss-autoscale" \ --condition "Percentage CPU < 30 avg 5m" \ --scale in 1 Tune these thresholds for your workload. Scale out aggressively enough to protect availability, and scale in conservatively enough to avoid unnecessary churn. Step 8: Update the VM sizes in the mix You can change the VM sizes in an existing Instance Mix configuration. The important detail is that updating --skuprofile-vmsizes replaces the full list. It does not add or remove a single size incrementally. For example, this command replaces the mix with four sizes: az vmss update \ --resource-group "$RG" \ --name "$VMSS" \ --skuprofile-vmsizes Standard_D2s_v5 Standard_D2as_v5 Standard_D2s_v4 Standard_D2as_v4 If you want to remove a size, specify the full list of sizes you want to keep. If you want to add a size, specify the full existing list plus the new size. Verify the new list: az vmss show \ --resource-group "$RG" \ --name "$VMSS" \ --query "skuProfile.vmSizes[].name" \ --output tsv Step 9: Change the allocation strategy You can also update the allocation strategy. For example, this changes the walkthrough scale set from its original CapacityOptimized strategy to LowestPrice . Use this as a real update example, not as a blanket production recommendation: az vmss update \ --resource-group "$RG" \ --name "$VMSS" \ --set skuProfile.allocationStrategy=LowestPrice When you change the allocation strategy, existing VMs are not immediately reshaped. The new strategy takes effect after the scale set scales in or out. If you change from Prioritized to another allocation strategy, Microsoft Learn notes that you must first nullify the priority ranks associated with the VM sizes. Step 10: Enable Instance Mix on an existing scale set You can enable Instance Mix on a separate existing scale set if it uses Flexible orchestration mode, does not already use Instance Mix, and the selected VM sizes are compatible. Do not run this procedure against the $VMSS scale set created earlier, because that scale set is already Instance Mix-enabled. The required settings are: Set sku.name to Mix . Set sku.tier explicitly to null unless you have confirmed it is already null or absent. Provide at least one VM size in skuProfile.vmSizes . Provide an allocation strategy, or let Azure use the default lowest-price strategy. Set a separate variable for the existing scale set you want to convert: EXISTING_VMSS="my-existing-flex-vmss" Example: az vmss update \ --resource-group "$RG" \ --name "$EXISTING_VMSS" \ --set sku.name=Mix sku.tier=null \ --skuprofile-vmsizes Standard_D2as_v4 Standard_D2s_v5 Standard_D2as_v5 \ --set skuProfile.allocationStrategy=CapacityOptimized As with other Instance Mix updates, existing VM instances are not necessarily changed immediately. The configuration is used for subsequent scale actions. Portal procedure If you prefer the Azure portal: Go to Virtual machine scale sets. Select Create. On the Basics tab, choose the subscription, resource group, scale set name, region, image, and administrator settings. Set Orchestration mode to Flexible. In the Size section, choose Select up to 5 sizes. Select up to five compatible VM sizes. Choose the Allocation strategy. If you choose Prioritized (preview), a Rank size section appears below Allocation strategy. Select Rank priority to open the prioritization blade and order the VM sizes based on your preferred priority. Complete the remaining tabs for networking, management, health, scaling, and advanced settings. Select Review + create, then create the scale set. After deployment, open the scale set and check the Overview blade. In the Properties section, check Size for the configured VM sizes and Management for the allocation strategy. Operational tips Use similar sizes for predictable application behavior For web, API, and worker tiers, choose sizes with similar vCPU and memory. This makes autoscale behavior easier to reason about and helps load distribution remain balanced. Do not rely on Instance Mix as a quota workaround Instance Mix can use another listed size if one size lacks quota, but it does not request quota for you. Check quota before production deployment, especially if your autoscale maximum is high. Align reservations and savings plans with Prioritized Reserved instance pricing and savings-plan discounts can apply with Instance Mix. If you want to consume reservation-backed sizes first, or favor sizes with better savings-plan economics, use the Prioritized strategy and rank those sizes first. Use Spot Priority Mix for Spot plus Standard Instance Mix can be used with both Spot and Standard VMs. The Instance Mix FAQ says to use Spot Priority Mix when you need a defined split between Spot and Standard capacity. Caveat: Instance Mix supports B-family sizes for regular capacity, but Azure Spot VMs do not support B-series or promo versions of any size. If your scale set will use Spot capacity, choose Spot-supported sizes for the mix. Be careful with unsupported properties If a deployment template includes unsupported properties such as Azure Dedicated Host, on-demand capacity reservation, Standby Pools, Proximity Placement Groups, or OS disk diffDiskSettings , remove those settings before using Instance Mix. Troubleshooting common deployment errors Error code Meaning Fix SkuProfileAllocationStrategyInvalid The allocation strategy is not valid. Use CapacityOptimized , Prioritized , or LowestPrice for the allocation strategy. SkuProfileVMSizesCannotBeNullOrEmpty No VM sizes were provided. Add at least one VM size to skuProfile.vmSizes . SkuProfileHasTooManyVMSizesInRequest More than five VM sizes were specified. Reduce the list to no more than five VM sizes. SkuProfileVMSizesCannotHaveDuplicates The same VM size appears more than once. Remove duplicate VM sizes. SkuNameMustBeMixIfSkuProfileIsSpecified A skuProfile was provided, but sku.name is not Mix . Set sku.name to Mix . SkuTierMustNotBeSetIfSkuProfileIsSpecified sku.tier is set when using Instance Mix. Set sku.tier to null or omit it. SkuProfileScenarioNotSupported The template includes a property not supported with Instance Mix. Remove unsupported properties such as host groups, capacity reservations, or standby pool settings. Instance Mix gives your operations team a practical way to make scale sets more flexible. By defining several compatible VM sizes and selecting the right allocation strategy, you can improve scale-out success, give Azure more capacity choices, and better align VM allocation with cost or reservation goals. For most production workloads, start with similar VM sizes, verify regional availability and quota, use Flexible orchestration mode, and test scale-out behavior before relying on the configuration in a critical environment. Further reading on Microsoft Learn: Use multiple Virtual Machine sizes with instance mix Create a scale set using instance mix Orchestration modes for Virtual Machine Scale Sets Update instance mix settings on an existing scale set Instance Mix FAQ and troubleshootingThe Microsoft Azure Infra Summit 2026 Schedule Is Live.
Hello Folks, I promised the full agenda would drop soon. Today’s the day. The schedule is locked in, the approved sessions are on the board, and I want to walk you through what three days of deep-technical, engineering-led Azure content looks like. A quick refresher before we get into the content: this event is free, it’s virtual, and it’s built by engineering for engineering. Most sessions are at the L300–L400 level, which means we’re skipping the marketing slide and getting straight to the architecture, the gotchas, and the “here’s what actually happens in production” stories you came for. We’re starting at 8:00 AM Pacific each day and running solid technical content through the afternoon. You can still register here (https://aka.ms/MAIS-reg) We organized the three days around the pillars our community keeps coming back to, Build, Operate, and Optimize. Day 1 leans into Build so you leave the keynote with momentum, Day 2 bridges Build into Operate (where most of us actually spend our workdays), and Day 3 is pure Optimize, resiliency, cost, performance, and networking, before we close things out. The full 3-day agenda (all times Pacific) Online Schedule Here Day 1, Tue, May 19 · BUILD Day 2, Wed, May 20 · BUILD + OPERATE Day 3, Thu, May 21 · OPTIMIZE + Closing 8:00 KEYNOTE: Welcome & Azure Infrastructure Vision 8:00, Build and Optimize a Data Lakehouse for Unified Data Intelligence 8:00, Achieving Zonal Resiliency in Azure Infrastructure 9:00, Build a Sovereign Private Cloud with Azure Local 8:45, Designing Azure Networks That Scale: From Small Deployments to Enterprise-Grade 8:30, Architecting Resilient Azure Platforms: Durable Functions, Cosmos DB, and DR by Design 9:45, The Azure Deployment Agent: How AI Turns a Prompt into a Production-Ready Workload 9:30, From Alert to Resolved: Building a Self-Healing Azure Platform with SRE Agent 9:00, Optimizing EDA & HPC Pipelines on Azure: High-Performance Shared Storage with Azure NetApp Files 10:15, ALZ IaC Accelerator: Deploy Your Azure Platform Landing Zone with IaC 10:15, Agentic Migrations & Modernization 9:30, Elastic SAN for AVS Datastores: Best Price-Performance External Storage 11:00, Building Secure, Well-Architected Azure Workloads by Default with Azure Verified Modules and GitHub Copilot 10:45, Simplifying File Share Management and Control for Azure Files 10:00, Premium SSD v2 Disk: Best Price-Performance Block Storage for VMs and Containers 11:45, Best Practices for Infrastructure as Code CI/CD on Azure 11:30, Marketplace Image Protection: Safeguarding Workloads Through Patching and Graceful Deprecation 10:45, Optimizing File Storage for AI and Cloud-Native Workloads on Azure 12:30, Modern Ingress for AKS: Introducing Application Gateway for Containers (AGC) 12:00, Operating Hybrid at Scale: Real-World Azure Arc Patterns for Governance, Security, and Cost Control 11:30, Cut Storage Costs, Boost ROI: Optimizing Your Storage TCO on Azure Object Storage 13:15, End-to-End Security on AKS Using Azure Application Gateway for Containers with Managed Cilium 12:45, Run At-Scale On-Premises and Cloud Assessments and Migrations to Azure Storage 12:15, How to Build Resilient Networks Using Azure Networking, What’s New in Azure Software Load Balancing 14:00, Deployment Stacks: Getting Started 13:30, Modernize VDI with Azure Files and Entra Cloud-Native Identities 13:00, AKS Networking at Scale, CNI, Security, and Multi-Cluster Networking with Accelerated Performance 14:30, Accelerating Automated VM Image Pipelines with Azure Image Builder and Azure Compute Gallery 14:15, Operating Azure Backup at Scale: Day-2 Excellence for IaaS, PaaS, and Storage Workloads 13:45, Kubenet Deprecation, Futureproofing AKS IPAM and Dataplane Configurations 15:00, Troubleshooting Kubernetes Networking with an AI Diagnostic Assistant 14:15, Implement Zero-Tolerance Downtime Web Apps with Azure Front Door 14:45, Closing: Azure Infrastructure Applied Skills and Certifications What to do right now Block your calendar, May 19, 20, and 21, 8:00 AM PT start each day. Check out www.azureinfrasummit.com for more information. Register, it’s free. Pick your sessions, the online schedule has ICS files for each session. Build your personal track across Build, Operate, and Optimize. Bring your team, the agenda is deliberately wide: platform engineers, SREs, storage folks, network folks, AKS operators, IaC builders, and backup/DR owners will all find their sessions. We put a lot of work into making sure every slot earned its place, these are engineering-delivered, production-grounded, no-fluff sessions. The speakers are the people shipping the features you’re using in Azure. Can’t wait to see you online May 19–21. Until then, Cheers! Pierre RomanJoin us at Microsoft Azure Infra Summit 2026 for deep technical Azure infrastructure content
Microsoft Azure Infra Summit 2026 is a free, engineering-led virtual event created for IT professionals, platform engineers, SREs, and infrastructure teams who want to go deeper on how Azure really works in production. It will take place May 19-21, 2026. This event is built for the people responsible for keeping systems running, making sound architecture decisions, and dealing with the operational realities that show up long after deployment day. Over the past year, one message has come through clearly from the community: infrastructure and operations audiences want more in-depth technical content. They want fewer surface-level overviews and more practical guidance from the engineers and experts who build, run, and support these systems every day. That is exactly what Azure Infra Summit aims to deliver. All content is created AND delivered by engineering, targeting folks working with Azure infrastructure and operating production environments. Who is this for: IT professionals, platform engineers, SREs, and infrastructure teams When: May 19-21, 2026 - 8:00 AM–1:00 PM Pacific Time, all 3 days Where: Online Virtual Cost: Free Level: Most sessions are advanced (L300-400). Register here: https://aka.ms/MAIS-Reg Built for the people who run workloads on Azure Azure Infra Summit is for the people who do more than deploy to Azure. It is for the people who run it. If your day involves uptime, patching, governance, monitoring, reliability, networking, identity, storage, or hybrid infrastructure, this event is for you. Whether you are an IT professional managing enterprise environments, a platform engineer designing landing zones, an Azure administrator, an architect, or an SRE responsible for resilience and operational excellence, you will find content built with your needs in mind. We are intentionally shaping this event around peer-to-peer technical learning. That means engineering-led sessions, practical examples, and candid discussion about architecture, failure modes, operational tradeoffs, and what breaks in production. The promise here is straightforward: less fluff, more infrastructure. What to expect Azure Infra Summit will feature deep technical content in the 300 to 400 level range, with sessions designed by engineering to help you build, operate, and optimize Azure infrastructure more effectively. The event will include a mix of live and pre-recorded sessions and live Q&A. Throughout the three days, we will dig into topics such as: Hybrid operations and management Networking at scale Storage, backup, and disaster recovery Observability, SLOs, and day-2 operations Confidential compute Architecture, automation, governance, and optimization in Azure Core environments And more… The goal is simple: to give you practical guidance you can take back to your environment and apply right away. We want attendees to leave with stronger mental models, a better understanding of how Azure behaves in the real world, and clearer patterns for designing and operating infrastructure with confidence. Why this event matters Infrastructure decisions have a long tail. The choices we make around architecture, operations, governance, and resilience show up later in the form of performance issues, outages, cost, complexity, and recovery challenges. That is why deep technical learning matters, and why events like this matter. Join us I hope you will join us for Microsoft Azure Infra Summit 2026, happening May 19-21, 2026. If you care about how Azure infrastructure behaves in the real world, and you want practical, engineering-led guidance on how to build, operate, and optimize it, this event was built for you. Register here: https://aka.ms/MAIS-Reg Cheers! Pierre RomanOverview of Azure Workload Modernization
Azure workload modernization generally means shifting from traditional deployment options, such as running a workload within a VM, to more cloud native components, such as functions, PaaS services, and other cloud architecture components. Shift from VMs to PaaS and Cloud-Native Services: By replatforming to services like Azure App Service for web apps, managed databases (e.g. Azure SQL Database), or container platforms (e.g. Azure Kubernetes Service (AKS)), you offload infrastructure management to Azure. Azure handles patches, scaling, and high availability, so your team can focus on code and features. (Learn more: https://learn.microsoft.com/azure/app-modernization-guidance/plan/plan-an-application-modernization-strategy#iaas-vs-paas) Immediately Leverage Azure’s Built-in Capabilities: You can light up Azure’s ecosystem features for security, compliance, monitoring, and more. For example, without changing any code you can enable Azure Monitor for telemetry and alerting, use Azure’s compliance certifications to meet regulatory needs, and turn on governance controls. Modernizing a workload is about unlocking things like auto-scaling, backup/DR, and patch management that will be handled for you as platform features. (See: https://learn.microsoft.com/azure/well-architected/framework/platform-automation) Treat Modernization as a Continuous Journey. Modernizing isn’t a single “big bang” rewrite, it’s an ongoing process. Once on Azure, plan to iteratively improve your applications as new services and best practices emerge. Implement DevOps pipelines (CI/CD) to regularly deliver updates and refactor parts of the system over time. This allows you to adopt new Azure capabilities (such as improved instance types, updated frameworks, or new managed services) with minimal disruption. By continually integrating improvements – from code enhancements to architecture changes – you ensure your workloads keep getting more efficient, secure, and scalable. (See: https://learn.microsoft.com/azure/app-modernization-guidance/get-started/application-modernization-life-cycle – continuous improvement approach) Use Containers and Event-Driven Architectures to Evolve Legacy Apps: Breaking apart large, tightly-coupled applications into smaller components can drastically improve agility and resilience. Containerize parts of your app and deploy them to a managed orchestrator like Azure Kubernetes Service (AKS) for better scalability and fault isolation. In an AKS cluster, each microservice or module runs independently, so you can update or scale one component without impacting the whole system. In addition, consider introducing serverless functions (via Azure Functions) or event-driven services for specific tasks and background jobs. These approaches enable on-demand scaling and cost efficiency – Azure only runs your code when triggered by events or requests. Adopting microservices and serverless architectures helps your application become more modular, easier to maintain, and automatically scalable to meet demand. (Learn more: https://learn.microsoft.com/azure/architecture/guide/architecture-styles/microservices and https://learn.microsoft.com/azure/azure-functions/functions-overview) Modernize Security and Identity: Update your application’s security posture to align with cloud best practices. Integrate your apps with Microsoft Entra ID for modern authentication and single sign-on, rather than custom or legacy auth methods. This provides immediate enhancements like multi-factor authentication, token-based access, and easier user management across cloud services. Additionally, take advantage of Azure’s global networking and security services, for example, use Azure Front Door to improve performance for users worldwide and add a built-in Web Application Firewall to protect against DDoS and web attacks. By using cloud-native security services (such as Azure Key Vault to manage app secrets and certificates, or Microsoft Defender for Cloud for threat protection), you can significantly strengthen your workload’s security while reducing the operational burden on your team. (See: https://learn.microsoft.com/entra/identity/intro and https://learn.microsoft.com/azure/frontdoor/front-door-overview)Managed Instance on Azure App Service: What IT/Ops Teams Need to Know
Azure App Service has long been one of the most reliable ways to run web apps on Azure, giving teams a fully managed platform with built‑in scaling, deployment integration, and enterprise‑grade security. But for organizations that need more control, expanded flexibility, or the ability to run apps that have additional dependencies, the new Managed Instance on Azure App Service (preview) brings a powerful new option. Vinicius Apolinario recently sat down with Andrew Westgarth, Product Manager for Azure App Service to talk through what Managed Instances are, why they matter, and how IT/Ops teams can take advantage of the new capabilities. What Managed Instances Bring to the Table Managed Instances (MI) deliver the App Service experience you know with added flexibility for additional scenarios. You get the same PaaS benefits—patching, scaling, deployment workflows—but with the control typically associated with IaaS. Some of the highlights we discussed: App Service and Managed Instance on Azure App Service — What are the main differences and what scenarios MI is focusing on. Consistent App Service experience — Same deployment model, same runtime options, same operational model. App service experience for different audiences — How IT/Ops teams can leverage MI and what does it mean for development teams. Features IT/Ops Teams Will Appreciate Beyond the core architecture, MI introduces capabilities that make day‑to‑day operations easier: Configuration (Install) Script — A new way to customize the underlying environment with scripts that run during provisioning. This is especially useful for installing dependencies, configuring app and OS settings, installing fonts, or preparing the environment for the workload. RDP Access for Troubleshooting — A long‑requested feature that gives operators a secure way to RDP into the instance for deep troubleshooting. Perfect for diagnosing issues that require OS‑level visibility. Learn more about Managed Instance on Azure App Service (preview): Documentation: https://aka.ms/AppService/ManagedInstance Hands On Lab: https://aka.ms/managedinstanceonappservicelab Blog: https://aka.ms/managedinstanceonappservice Ignite session: https://ignite.microsoft.com/en-US/sessions/BRK102Azure Migration Challenges (and how to resolve them)
Moving workloads to Azure is rarely plug-and-play. Here are some workarounds for challenges organizations encounter when planning and executing migrations. Server Migration Legacy OS & Software Compatibility Old, out-of-support operating systems may not run in Azure or may perform poorly. Tightly coupled apps tied to specific hardware or OS versions are hard to replicate. Fix: Run compatibility assessments early. Upgrade or patch the OS before migrating, or refactor the workload to run on a supported OS. Performance Sizing On-prem VMs may rely on fast local SSDs or low-latency network links you won't get by default in Azure. Undersizing means poor performance; oversizing means wasted spend. Fix: Use Azure Migrate's performance-based recommendations to right-size your VMs. Network & Identity Integration Migrated servers still need to communicate with on-prem resources and authenticate users. Splitting app servers and auth servers across environments breaks things fast. Fix: Design network topology & identity infrastructure before you move anything. Move workloads that have interdependencies together. Governance & Cloud Sprawl On-prem controls (naming conventions, equipment tags) don't automatically follow you to the cloud. Spinning up resources with a click leads to sprawl. Fix: Set up Azure Policy from day one. Enforce tagging, naming, and compliance rules as part of the migration project—not after. Skills Gaps On-prem server experts aren't automatically fluent in Azure operations. Fix: Invest in cloud operations training before and during the migration. Database Migration Compatibility Not every database engine or version maps cleanly to an Azure equivalent. Fix: Run the Azure Data Migration Assistant early to verify feature and functionality support. Post-Migration Performance Performance depends on the hosting ecosystem; what worked on-prem may not translate directly. Fix: Revisit indexing and configuration after migration. Use SQL Intelligent Insights and Performance Recommendations for tuning guidance. Choosing the Right Service Tier Azure offers elastic pools, managed instances, Hyperscale, and sharding—picking wrong may be costly. Fix: Profile your workload with your DBA and use Azure Migrate's Database Assessment for sizing suggestions. Security Configuration User logins, roles, and encryption settings must migrate with the data. Fix: Map every layer of your on-prem security configuration and implement corresponding controls post-migration. Data Integrity Data types, constraints, and triggers must come over intact with zero loss or corruption. Fix: Use reliable migration tools, test multiple times, and validate row counts and key constraints. Plan cutover during low-usage windows and always have a rollback plan. Application Migration Legacy App Complexity Custom and legacy apps carry years of accumulated config files, hard-coded paths, IP addresses, and environment-specific logging. Each app can feel like its own mini migration project. Fix: Use Azure Migrate's app dependency analysis to map what each app needs before you touch it. Dependency Conflicts Apps may depend on specific framework versions, libraries, or OS features that aren't available or supported in Azure. Fix: Identify and resolve dependency gaps early. Consider containerizing or refactoring apps to isolate them from environment differences. Scale of Effort Dozens or hundreds of apps, each with unique characteristics, create a massive manual workload. Fix: Automate everything you can. Use porting assistants and batch migration tooling to reduce repetitive tasks. Key Takeaway Start assessments early, automate aggressively, set up governance from day one, and train your team before the move—not after. The most likely cause of a migration failure comes from skipping the prep work.Migration, Modernization & Agentic Tools
This video covers Migration, Modernization, and Agentic tools. Agentic tools introduce autonomy, continuous optimization, and context‑aware decision‑making into the migration lifecycle. Instead of treating migration as a one‑time lift‑and‑shift, they operate as ongoing systems that: Discover and map environments dynamically Recommend modernization paths based on real telemetry Automate execution steps end‑to‑end Continuously validate, optimize, and remediate after landing in Azure This shifts migration from a project to a self‑improving system. This video provides an overview of new tools in Azure Copilot and GitHub Copilot that you can use when migrating and modernizing. These tools provide the following benefits: Agents can classify workloads into migrate/modernize/rebuild patterns based on performance, code structure, and operational signals. Agents can execute migration waves automatically—copying data, validating cutovers, sequencing dependencies, and rolling back if needed. Agentic tools can continuously tune cost, performance, resiliency, and security posture using telemetry and policy-driven actions. Agentic tools can ensure governance is embedded into the migration engine—ensuring workloads land compliant, secure, and aligned with enterprise standards. Autonomous discovery and automated execution remove weeks of manual effort. Parallelized migration waves become safe because the system understands dependencies. Automated validation reduces human error during cutover. Refactoring recommendations are grounded in code and performance analysis. Agentic tools keep optimizing cost, security, and resilience—closing the loop between migration and operations.
Automating Large‑Scale Data Management with Azure Storage Actions
Azure Storage customers increasingly operate at massive scale, with millions or even billions of items distributed across multiple storage accounts. As the scale of the data increases, managing the data introduces a different set of challenges. In a recent episode of Azure Storage Talk, I sat down with Shashank, a Product Manager on the Azure Storage Actions team, to discuss how Azure Storage Actions helps customers automate common data management tasks without writing custom code or managing infrastructure. This post summarizes the key concepts, scenarios, and learnings from that conversation. Listen to the full conversation below. The Problem: Data Management at Scale Is Hard As storage estates grow, customers often need to: Apply retention or immutability policies for compliance Protect sensitive or important data from modification Optimize storage costs by tiering infrequently accessed data Add or clean up metadata (blob index tags) for discovery and downstream processing Today, many customers handle these needs by writing custom scripts or maintaining internal tooling. This approach requires significant engineering effort, ongoing maintenance, careful credential handling, and extensive testing, especially when operating across millions of item across multiple storage accounts. These challenges become more pronounced as data estates sprawl across regions and subscriptions. What Is Azure Storage Actions? Azure Storage Actions is a fully managed, serverless automation platform designed to perform routine data management operations at scale for: Azure Blob Storage Azure Data Lake Storage It allows customers to define condition-based logic and apply native storage operations such as tagging, tiering, deletion, or immutability, across large datasets without deploying or managing servers. Azure Storage Actions is built around two main concepts: Storage Tasks A storage task is an Azure Resource Manager (ARM) resource that defines: The conditions used to evaluate blobs (for example, file name, size, timestamps, or index tags) The actions to take when conditions are met (such as changing tiers, adding immutability, or modifying tags) The task definition is created once and centrally managed. Task Assignments A task assignment applies a storage task to one or more storage accounts. This allows the same logic to be reused without redefining it for each account. Each assignment can: Run once (for cleanup or one-off processing) Run on a recurring schedule Be scoped using container filters or excluded prefixes Walkthrough Scenario: Compliance and Cost Optimization During the episode, Shashank demonstrated a real-world scenario involving a storage account used by a legal team. The Goal Identify PDF files tagged as important Apply a time-based immutability policy to prevent tampering Move those files from the Hot tier to the Archive tier to reduce storage costs Add a new tag indicating the data is protected Move all other blobs to the Cool tier for cost efficiency The Traditional Approach Without Storage Actions, this would typically require: Writing scripts to iterate through blobs Handling credentials and permissions Testing logic on sample data Scaling execution safely across large datasets Maintaining and rerunning the scripts over time Using Azure Storage Actions With Storage Actions, the administrator: Defines conditions based on file extension and index tags Chains multiple actions (immutability, tiering, tagging) Uses a built-in preview capability to validate which blobs match the conditions Executes the task without provisioning infrastructure The entire workflow is authored declaratively in the Azure portal and executed by the platform. Visibility, Monitoring, and Auditability Azure Storage Actions provides built-in observability: Preview conditions allow customers to validate logic against a subset of blobs before execution Azure Monitor metrics track task runs, targeted objects, and successful operations Execution reports are generated as CSV files for each run, detailing: Blobs processed Actions performed Execution status for audit purposes This makes Storage Actions suitable for scenarios where traceability and review are important. Common Customer Use Cases Shashank shared several examples of how customers are using Azure Storage Actions today: Financial services: Applying immutability and retention policies to call recordings for compliance Airlines: Cost optimization by tiering or cleaning up blobs based on creation time or size Manufacturing: One-time processing to reset or remove blob index tags on IoT-generated data These scenarios range from recurring automation to one-off operational tasks. Getting Started and Sharing Feedback Azure Storage Actions is available in over 40 public Azure regions. To learn more, check out: Azure Storage Actions product page: https://azure.microsoft.com/en-us/products/storage-actions Azure Storage Actions public documentation: https://learn.microsoft.com/en-us/azure/storage-actions/storage-tasks/storage-task-quickstart-portal Azure Storage Actions pricing page: https://azure.microsoft.com/en-us/pricing/details/storage-actions/ For questions or feedback, the team can be reached at: storageactions@microsoft.com
