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:
Candidate | CPU | Memory | Network | Storage | Use |
|---|
Candidate A | Meets | Meets | Meets | Meets | Preferred |
Candidate B | Exceeds | Meets | Exceeds | Meets | Performance option |
Candidate C | Meets | Exceeds | Meets | Meets | Memory-heavy option |
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:
- VM availability in the target region.
- Subscription quota.
- Required disk support.
- Network requirements.
- Architecture compatibility.
- Application licensing requirements.
- Expected workload behavior.
- Cost limits.
- Security requirements.
- 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
Problem | Possible Cause | What to Check |
|---|
No suitable VM returned | Requirements are too restrictive | CPU, memory, GPU, region, storage |
Recommended VM cannot deploy | Regional capacity or quota | Subscription and regional quota |
Application fails after deployment | Architecture mismatch | Application binaries and dependencies |
Performance is poor | Missing workload requirement | Network, storage, memory, GPU |
Recommendation changes frequently | Dynamic infrastructure options | Treat result as a candidate list |
Cost is higher than expected | Oversized VM | Review actual utilization |
SDK integration is difficult to test | SDK tightly coupled to application | Introduce an abstraction layer |
Advantages and Disadvantages
Advantages | Disadvantages |
|---|
Reduces manual VM comparison | Recommendation still needs validation |
Can consider multiple infrastructure requirements | SDK capabilities depend on the supported API surface |
Easier to integrate into internal platforms | Adds another component to the deployment workflow |
Helps standardize infrastructure decisions | Poor input produces poor recommendations |
Can support automated optimization workflows | Cost and organizational policies still require separate handling |
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.
Azure VM sizesAzure infrastructure optimizationVM recommendations.NETworkload requirementscloud cost optimization
Join the conversation! Your thoughts help the community grow.