Azure Compute Fleet: Fix Setup & Configuration Errors

Getting the Azure Compute Fleet setup started correctly in the portal avoids a surprising number of downstream headaches. The fleet creation UI is not surfaced from the standard "Virtual Machines" blade, that trips people up right away.

Here's the exact navigation path:

1. Sign in to portal.azure.com.
2. In the top search bar, type Compute Fleet. Under the results, select the result listed under Marketplace, not Services. This distinction matters; selecting the wrong result drops you in the wrong blade.
3. On the Compute Fleet Marketplace page, click Create.
4. In the Basics tab under Project details, confirm the correct subscription. If you're working across multiple tenants or subscriptions, double-check here, I've seen engineers burn 30 minutes wondering why quota errors show up, only to realize they were deploying into a dev subscription with a 10-VM cap.
5. Create a new resource group. The docs suggest naming it something like myFleetResourceGroup. Keep it descriptive, something like rg-computefleet-prod-eastus saves a lot of confusion when you have multiple fleets.
6. Set the fleet name under Instance details.

For the image selection, Azure Compute Fleet supports Windows Server images and Linux images including RHEL, CentOS, Ubuntu, and SLES. Pick the image that matches your workload. If you're running containerized jobs, Ubuntu LTS with Docker pre-installed is a common choice.

What you should see if this step worked: The Basics tab validates cleanly with no red error indicators, and you can advance to the next tab. If you see a subscription or region validation error here, that's your first sign of a quota or access issue, resolve that before going further.

This is the step most people rush through, and it causes more ongoing headaches than anything else in the Azure Compute Fleet configuration. Your allocation strategy determines how the fleet picks VMs when provisioning, and a bad match between strategy and workload means you'll either overpay or constantly fight capacity gaps.

Azure Compute Fleet offers distinct allocation strategies for Spot VMs and Standard VMs. Here's how to think about each:

For Spot VMs:

• Lowest price, Fleet picks whichever SKUs are currently cheapest. Great for fault-tolerant batch jobs where cost is king and eviction is tolerable.
• Capacity optimized, Fleet picks SKUs with the most available capacity, reducing eviction risk. Good for jobs where interruption is expensive even if you're using Spot.
• Price & capacity balanced, A blend of both. This is the right default for most workloads. It's what I'd recommend starting with unless you have a specific cost target or uptime requirement that forces you toward one extreme.

For Standard (pay-as-you-go) VMs:

• Lowest price, Picks the cheapest standard SKUs in your allowed list. Works well when your SKU preference list is broad.
• Prioritized, Respects the order of your SKU list. You define priority, and the fleet honors it. Use this when you have infrastructure requirements that mandate specific VM families.

To set the strategy in the portal, look for the Allocation strategy section within the fleet creation wizard. Set it separately for Spot and Standard if you're mixing both types.

One thing the Azure Compute Fleet docs don't shout loudly enough: you can also mix purchasing models inside a single fleet, Reserved Instances, Savings Plans, Spot, and pay-as-you-go all coexist. There's no extra charge from Microsoft for running a fleet itself. You only pay for the underlying VMs launched per hour.

What you should see: After selecting strategies, the configuration panel shows your combined fleet setup without errors. If the strategy dropdown is grayed out, check whether you accidentally left the fleet type as a one-time request rather than a managed fleet, the UI behavior differs between those two modes.

Target capacity is where Azure Compute Fleet gets powerful, and where it's easy to misconfigure in ways that cause silent failures. You set target capacity separately for Spot VMs and pay-as-you-go VMs. These are independent numbers, and the fleet manages them independently based on your workload.

To configure this correctly:

1. In the fleet creation wizard, locate the Target capacity section.
2. Enter your desired Spot VM count and your desired Standard VM count separately. The combined total across all fleets in a region cannot exceed 100,000 VMs, and a single fleet is capped at 10,000 VMs.
3. Decide on Minimum starting capacity. This field tells Azure: "Don't finish the deployment unless you can give me at least this many VMs." If you set this too high relative to regional availability, the entire deployment will fail with a capacity error.

Here's the exact behavior described in the official docs, and it's worth understanding precisely: if your target is 100 VMs and your minimum starting capacity is 20, the deployment only succeeds if Azure can provision at least 20. If regional capacity is tight and only 15 are available, you get a hard failure, not a partial deployment.

Important constraint: If you configure your fleet with Maintain capacity as the capacity preference type, you cannot set a minimum starting capacity. Azure takes over that responsibility automatically and attempts to keep the fleet at your target. This is the right mode for long-running services where you need consistent compute.

# To check current regional quota usage via Azure CLI:
az quota show \
  --resource-name "computeFleets" \
  --scope "/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{region}"

What you should see: After entering capacity values, the portal validates the numbers against your current quota. If you see a red warning about quota limits before you even try to deploy, you need to request a quota increase first via the Azure portal's Quotas blade.

One of the more underused features of Azure Compute Fleet is attribute-based VM selection. Instead of manually listing every VM SKU you'll accept, you tell the fleet what your workload actually needs, a certain amount of memory, a vCPU range, storage type, and Azure picks from whatever SKUs satisfy those attributes at any given moment. This is especially valuable for Azure Compute Fleet Spot configurations where SKU availability shifts constantly.

To set this up in the portal:

1. In the VM configuration section, look for the option to specify VM sizes. You'll see two modes: Specify VM sizes (manual list) and Let Azure Compute Fleet decide based on attributes.
2. Select the attribute-based option.
3. You can then set constraints for:
   • vCPU range, e.g., minimum 4 vCPUs, maximum 32
   • Memory range, e.g., minimum 16 GB RAM
   • Local storage, whether local temp disk is required
   • VM architecture, x64 vs. Arm64 if your workload cares

The advantage here is significant: instead of a static SKU list that can run dry on capacity, you're effectively giving the fleet a wide pool to draw from. If the D4s_v5 is fully allocated in your region, the fleet can fall back to E4s_v5 or any other SKU that meets your attribute thresholds. This is why attribute-based VM selection in Azure Compute Fleet dramatically reduces capacity-related deployment failures.

Note that attribute-based selection is currently in Preview. That means the UI might have rough edges, and you should test in a non-production environment before counting on it for critical workloads. The feature is surfaced in the portal as of the latest update cycle.

# Example ARM template snippet for attribute-based selection:
"vmAttributes": {
  "vCpuCount": {
    "min": 4,
    "max": 32
  },
  "memoryInGiB": {
    "min": 16
  },
  "localStorageSupport": "Excluded"
}

What you should see: The portal displays a summary of matching VM SKUs based on your attribute filters. If the count of matching SKUs shows as very low (under 5), consider loosening your constraints, a narrow attribute set behaves the same as a short manual SKU list and carries the same capacity risk.

If you're running Spot VMs inside your Azure Compute Fleet, and most people are, because that's where the cost savings come from, eviction is not an if, it's a when. Azure Compute Fleet has built-in eviction handling, but you have to configure it correctly or you'll find your fleet silently shrinking over time.

Here's what happens when a Spot VM gets evicted:

• The eviction can be triggered by Azure needing that capacity back (a capacity eviction) or because the Spot price exceeded your maximum price threshold (a price eviction).
• Azure Compute Fleet can automatically attempt to replace evicted Spot VMs to maintain your target capacity, but this only happens if your fleet is configured with Maintain capacity mode.

To verify your eviction replacement is configured:

1. Open your fleet resource in the Azure portal.
2. Under Configuration, confirm the capacity type is set to Maintain capacity rather than Request capacity (one-time).
3. Check your allocation strategy for Spot VMs. If it's set to Lowest price, you're most exposed to eviction. Consider switching to Capacity optimized or the balanced option if eviction frequency is hurting your workload.

You should also make sure your applications running on these VMs handle eviction gracefully. Azure sends a 30-second eviction notice to the VM before termination. Your app should listen for the scheduled events endpoint to catch this signal and checkpoint work before the VM goes away:

# Poll the Instance Metadata Service for scheduled eviction events:
curl -H "Metadata: true" \
  "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01"

If EventType returns Preempt, your VM has 30 seconds. Use that window to flush state, write checkpoints, or gracefully drain connections.

To monitor evictions at the fleet level, check the fleet's Activity log in the portal. Eviction events appear there with timestamps and affected VM instance IDs, which helps you correlate evictions with workload failures.

What you should see: In a healthy fleet under Maintain capacity mode, the instance count under Overview should hover near your target even after eviction events. If it keeps dropping, your allocation strategy may not have access to enough diverse SKUs to replace evicted capacity, widen your SKU list or switch to attribute-based selection.