Recommending Azure VM Sizes With the New AI Infrastructure Optimization SDK

Choosing the right Azure virtual machine size is often harder than creating the VM itself.

A workload may need more CPU, more memory, faster storage, higher network bandwidth, or a GPU. Choosing a VM based only on the number of CPU cores can lead to poor performance or unnecessary cloud spending.

The AI Infrastructure Optimization SDK is designed to help applications and automation workflows make infrastructure sizing decisions using workload requirements and Azure infrastructure information.

Instead of asking a developer to manually compare dozens of VM sizes, an application can evaluate requirements and produce a more practical recommendation.

This article explains how to approach VM-size recommendations with the SDK, what information should be considered, how to integrate the recommendation process into a .NET application, and what should still be validated before deploying the selected VM.

Why VM Size Selection Needs More Than CPU and RAM

A common approach is:

Application requires:
8 CPU
32 GB RAM

Choose a VM with:
8 CPU
32 GB RAM

This looks reasonable but ignores several important factors.

For example, two VMs with similar CPU and memory can have different:

• Network bandwidth
• Temporary disk performance
• Premium disk support
• IOPS limits
• GPU availability
• Architecture
• Regional availability
• Pricing
• Scaling characteristics

A production workload therefore needs a more complete requirement model.

Application Requirements
        |
        +-- CPU
        +-- Memory
        +-- Storage
        +-- Network
        +-- GPU
        +-- Architecture
        +-- Region
        +-- Availability
        |
        v
Infrastructure Optimization
        |
        v
Candidate VM Sizes
        |
        v
Validation
        |
        v
Deployment

The recommendation should be treated as a decision-support step rather than an automatic deployment command.

What the AI Infrastructure Optimization SDK Can Do

The SDK can be used as part of an infrastructure optimization workflow where workload requirements are evaluated against available Azure infrastructure options.

A typical workflow looks like this:

Collect workload requirements
          |
          v
Normalize requirements
          |
          v
Evaluate Azure VM candidates
          |
          v
Rank candidates
          |
          v
Review cost and constraints
          |
          v
Validate in the target region
          |
          v
Deploy

The useful part is that the recommendation logic can be integrated into an application or internal platform instead of maintaining a large collection of hard-coded VM-selection rules.

For example, an internal deployment tool could ask:

Workload:
.NET API

CPU:
8 cores

Memory:
32 GB

Region:
East US

Storage:
Premium SSD

Expected workload:
High network traffic

The tool can then evaluate suitable VM options and present the recommended candidates.

Start With a Workload Profile

Before asking any optimization system to recommend infrastructure, collect meaningful requirements.

A simple workload model might look like this:

public sealed class WorkloadRequirements
{
    public int MinimumCpuCores { get; set; }
    public int MinimumMemoryGb { get; set; }

    public bool RequiresGpu { get; set; }

    public string Region { get; set; } = string.Empty;

    public string StorageType { get; set; } = string.Empty;

    public int ExpectedNetworkMbps { get; set; }
}

This is more useful than passing only CPU and memory.

For example:

var requirements = new WorkloadRequirements
{
    MinimumCpuCores = 8,
    MinimumMemoryGb = 32,
    RequiresGpu = false,
    Region = "East US",
    StorageType = "Premium SSD",
    ExpectedNetworkMbps = 1000
};

The exact fields should match the requirements of the workload and the capabilities exposed by the infrastructure optimization workflow.

Separate Requirements From Recommendations

One of the most important design decisions is to keep workload requirements independent from VM recommendations.

Do not write:

if (cpu >= 8)
{
    vmSize = "specific-vm-size";
}

This creates a hard-coded decision tree that becomes difficult to maintain.

Instead:

Requirements
     |
     v
Optimization layer
     |
     v
Candidate VM sizes
     |
     v
Recommendation

The application should describe what it needs, not force the optimizer to choose one specific VM family.

This also makes the system easier to update when new Azure VM families become available.

Using the SDK From a .NET Application

The exact SDK package, namespaces, authentication model, and API surface depend on the Azure SDK version being used.

The application should therefore keep the optimization client behind its own service interface.

For example:

public interface IVmRecommendationService
{
    Task<VmRecommendation> RecommendAsync(
        WorkloadRequirements requirements,
        CancellationToken cancellationToken);
}

The application can then use:

var recommendation =
    await recommendationService.RecommendAsync(
        requirements,
        cancellationToken);

This approach avoids spreading SDK-specific types throughout the application.

It also makes testing easier because the application can use a mock recommendation service.

Designing a Recommendation Result

A useful recommendation should contain more than a VM name.

For example:

public sealed class VmRecommendation
{
    public string VmSize { get; set; } = string.Empty;

    public string Region { get; set; } = string.Empty;

    public string Reason { get; set; } = string.Empty;

    public IReadOnlyList<string> Constraints { get; set; }
        = Array.Empty<string>();
}

A recommendation might conceptually contain:

VM Size:
Candidate A

Region:
East US

Reason:
Meets CPU, memory, network, and storage requirements.

Constraints:
Requires Premium SSD support.
Validate regional capacity before deployment.

This makes the recommendation explainable.

Ranking Multiple VM Candidates

A production tool should usually avoid returning only one candidate.

Consider:

Multiple candidates allow developers or platform engineers to make the final decision.

For example, an application could present:

Recommended
Candidate A

Performance Alternative
Candidate B

Memory Alternative
Candidate C

This is more useful than treating an AI-generated recommendation as an absolute answer.

Include Region in the Recommendation

A VM size is not useful if it cannot be deployed in the required region.

The recommendation process should therefore include the target region:

var requirements = new WorkloadRequirements
{
    MinimumCpuCores = 8,
    MinimumMemoryGb = 32,
    Region = "East US"
};

Region affects more than latency.

It can affect:

• VM availability
• Supported VM families
• Pricing
• GPU availability
• Disk options
• Quotas
• Capacity

The recommendation should be validated against the actual deployment region before infrastructure is created.

Consider CPU Architecture

Architecture is another requirement that should not be ignored.

A workload may depend on:

• x64 binaries
• ARM64-compatible software
• Native libraries
• Specific container images
• Architecture-specific dependencies

For example, a deployment platform should not recommend an ARM-based VM simply because the CPU and memory requirements are satisfied.

The application compatibility layer should verify architecture before accepting the recommendation.

Include Storage Requirements

Storage requirements should be represented separately from VM compute requirements.

For example:

Compute:
8 CPU
32 GB RAM

Storage:
Premium SSD
1 TB
High IOPS

Network:
1 Gbps+

This prevents a compute recommendation from being treated as a complete infrastructure recommendation.

For database workloads, storage performance can be more important than adding additional CPU cores.

GPU Workloads Need Different Rules

AI inference, model training, rendering, and other accelerator workloads require GPU-aware recommendations.

For example:

Requires GPU:
Yes

Minimum GPU memory:
Required by workload

Expected inference load:
High

Region:
Target Azure region

A general-purpose CPU VM should not be selected simply because it satisfies the CPU and memory requirements.

The recommendation process should first establish whether the workload requires an accelerator and then evaluate compatible infrastructure.

Use Recommendations as a Guardrail

An internal platform can use the optimization SDK to prevent obviously unsuitable deployments.

For example:

Developer requests:
4 CPU / 16 GB

Optimization result:
Recommended VM: Candidate A

Developer requests:
4 CPU / 128 GB

Optimization result:
Reject Candidate A
Recommend memory-optimized candidates

The platform can also establish policies:

Minimum:
4 CPU

Maximum:
64 CPU

Allowed regions:
Approved regions

Allowed architectures:
Approved architectures

This combines optimization with organizational infrastructure policy.

Validate the Recommendation Before Deployment

An optimization result should not automatically become infrastructure.

Before deployment, validate:

1. VM availability in the target region.
2. Subscription quota.
3. Required disk support.
4. Network requirements.
5. Architecture compatibility.
6. Application licensing requirements.
7. Expected workload behavior.
8. Cost limits.
9. Security requirements.
10. Availability requirements.

This is especially important for production workloads.

Add Cost to the Decision

Performance alone should not determine the VM size.

A simple decision model is:

Technical requirements
        +
Availability
        +
Security
        +
Operational requirements
        +
Cost
        =
Final VM selection

For example, if two candidates satisfy the workload:

Candidate A
Meets requirements
Lower cost

Candidate B
Exceeds requirements
Higher cost

Candidate B is not automatically better.

The optimization workflow should help identify the technical candidates, while organizational cost policies determine which option is acceptable.

Common Mistakes

Selecting a VM using CPU count only

CPU count does not represent network, storage, memory bandwidth, GPU, or architecture requirements.

Hard-coding VM sizes

Hard-coded mappings become outdated when workload requirements or available VM families change.

Ignoring region

A VM family may not have the same availability in every Azure region.

Treating AI recommendations as deployment instructions

The recommendation should be validated against quotas, availability, security, and application compatibility.

Mixing business rules with SDK code

Keep infrastructure policies separate from the SDK integration.

Returning only one recommendation

Multiple candidates provide a better decision-making experience.

Best Practices

• Collect workload requirements before requesting recommendations.
• Keep the optimization SDK behind an application service interface.
• Include region, architecture, storage, network, and accelerator requirements.
• Return multiple suitable candidates when possible.
• Explain why a candidate was recommended.
• Validate regional availability before deployment.
• Apply organizational VM policies after optimization.
• Include cost in the final decision.
• Keep recommendation logic independent from deployment automation.
• Log recommendation inputs and outputs for troubleshooting.
• Re-evaluate recommendations when workload requirements change.
• Test recommendations using representative workloads before production rollout.

Troubleshooting

Advantages and Disadvantages

When This Approach Makes Sense

An AI-assisted infrastructure optimization workflow makes sense when an organization manages many workloads and VM choices are becoming difficult to maintain manually.

It can be particularly useful for internal developer platforms, deployment portals, infrastructure automation, and workload migration projects.

For a small application with one stable VM, manually selecting infrastructure may be simpler.

The value increases when there are many workloads, changing requirements, multiple regions, and different compute profiles.

Summary

Recommending Azure VM sizes with an AI Infrastructure Optimization SDK is primarily about improving the infrastructure decision process.

The important part is not simply asking an SDK for a VM name. A useful recommendation workflow starts with clear workload requirements, evaluates compatible infrastructure, considers region and architecture, includes storage and networking needs, and produces explainable candidates.

The final VM selection should still be validated against Azure availability, quotas, application compatibility, security requirements, and cost.

A good implementation keeps the optimization layer separate from deployment automation. This makes the system easier to test, update, and reuse as workloads and Azure infrastructure requirements change.