Using Azure AI Infrastructure Optimization From a .NET Application

Choosing infrastructure for a cloud application usually involves more than selecting a VM with enough CPU and memory.

A .NET application may need a particular amount of memory, network capacity, storage performance, processor architecture, or accelerator support. When several workloads are involved, maintaining these decisions manually can become difficult.

An AI infrastructure optimization workflow can help a .NET application evaluate workload requirements and identify suitable Azure infrastructure options.

The important part is to treat optimization as a recommendation layer rather than allowing an AI result to directly create production infrastructure.

This article shows how to structure a .NET application around an Azure AI infrastructure optimization workflow, how to model workload requirements, how to keep SDK integration isolated, and how to validate recommendations before deployment.

Where Infrastructure Optimization Fits in a .NET Application

A typical application deployment pipeline may look like this:

Developer Request
       |
       v
Workload Requirements
       |
       v
.NET Optimization Service
       |
       v
Infrastructure Recommendation
       |
       v
Policy Validation
       |
       v
Deployment Automation
       |
       v
Azure Resources

The .NET application does not need to contain hard-coded rules for every VM family.

Instead, it can collect requirements and pass them to the infrastructure optimization layer.

For example:

Application:
.NET API

CPU:
8 cores

Memory:
32 GB

Storage:
Premium SSD

Region:
East US

GPU:
Not required

The optimization layer evaluates those requirements and returns suitable infrastructure candidates.

Why Use a .NET Service Layer

A common mistake is placing SDK-specific calls directly inside controllers, background jobs, or deployment handlers.

For example, this creates tight coupling:

public async Task<IActionResult> Recommend()
{
    // SDK calls
    // Authentication
    // Requirement mapping
    // Recommendation processing
    // Policy validation

    return Ok();
}

A better design separates responsibilities:

Controller
    |
    v
IVmOptimizationService
    |
    v
Azure Optimization Client
    |
    v
Azure Infrastructure

This gives the application a clear boundary between business logic and Azure SDK integration.

Define Workload Requirements

Start by defining a model that describes the workload rather than a specific VM.

public sealed class WorkloadRequirements
{
    public int MinimumCpuCores { get; init; }

    public int MinimumMemoryGb { get; init; }

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

    public string Architecture { get; init; } = "x64";

    public bool RequiresGpu { get; init; }

    public int ExpectedNetworkMbps { get; init; }

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

This model can be extended as the application grows.

The important principle is that the input describes what the workload needs.

It should not contain fields such as:

public string VmSize { get; init; }

That would mix requirements with the recommendation.

Create a Recommendation Service

Create an abstraction around the optimization workflow:

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

The rest of the application can depend on this interface instead of the underlying SDK.

A recommendation model can contain the result and explanation:

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

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

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

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

This separation makes the recommendation process easier to test.

Register the Service With Dependency Injection

A standard ASP.NET Core application can register the service through dependency injection.

builder.Services.AddScoped<IInfrastructureOptimizationService,
    InfrastructureOptimizationService>();

The implementation can then contain the Azure-specific integration.

public sealed class InfrastructureOptimizationService
    : IInfrastructureOptimizationService
{
    public async Task<VmRecommendation> RecommendAsync(
        WorkloadRequirements requirements,
        CancellationToken cancellationToken)
    {
        // Map requirements to the Azure optimization workflow.
        // Call the configured Azure SDK/client.
        // Convert the result into the application's model.

        await Task.CompletedTask;

        return new VmRecommendation
        {
            VmSize = "candidate-vm-size",
            Region = requirements.Region,
            Reason = "Candidate satisfies the supplied workload requirements."
        };
    }
}

The example intentionally keeps the SDK-specific operation behind the service boundary.

The exact SDK client, package name, namespaces, and API methods should match the Azure SDK version used by the project.

Authentication Should Stay Outside Business Logic

Azure SDK integrations should normally use Microsoft Entra-based authentication rather than embedding credentials in application code.

A common .NET pattern is:

using Azure.Identity;

var credential = new DefaultAzureCredential();

The application can then use the credential with the appropriate Azure client.

The benefit of this approach is that the same application can use different supported authentication sources depending on its environment.

For local development, developers can authenticate through their Azure development identity.

In Azure-hosted environments, managed identity can be used where supported.

Do not put client secrets directly into:

appsettings.json

or source code.

Add an API for VM Recommendations

Once the service is registered, an API endpoint can expose the recommendation workflow.

For example:

app.MapPost("/infrastructure/recommend",
    async (
        WorkloadRequirements requirements,
        IInfrastructureOptimizationService service,
        CancellationToken cancellationToken) =>
    {
        var recommendation =
            await service.RecommendAsync(
                requirements,
                cancellationToken);

        return Results.Ok(recommendation);
    });

A client could submit:

{
  "minimumCpuCores": 8,
  "minimumMemoryGb": 32,
  "region": "East US",
  "architecture": "x64",
  "requiresGpu": false,
  "expectedNetworkMbps": 1000,
  "storageType": "Premium SSD"
}

The API should return a recommendation that the deployment workflow can evaluate.

Do Not Deploy Immediately After a Recommendation

The most important production rule is to introduce a validation stage.

Requirements
      |
      v
Optimization
      |
      v
Recommendation
      |
      v
Policy Validation
      |
      v
Deployment Approval
      |
      v
Azure Deployment

For example, an organization may allow only:

Regions:
East US
West Europe

Architectures:
x64

Maximum VM cost:
Defined by platform policy

GPU:
Allowed only for approved workloads

The optimization system may recommend a technically valid VM that violates one of these policies.

The policy layer should reject it before deployment.

Validate the Region

Region should be part of the original workload requirements.

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

A recommendation that ignores region can be unusable in production.

Region can affect:

• VM family availability
• Capacity
• Pricing
• GPU availability
• Quotas
• Disk options
• Application latency

The .NET application should therefore treat the target region as a hard deployment constraint when required.

Handle Multiple Recommendations

A useful infrastructure tool should not always return only one candidate.

Consider this result:

Recommended:
Candidate A

Alternative:
Candidate B

Memory-optimized:
Candidate C

A .NET application can represent this with a collection:

public sealed class InfrastructureRecommendation
{
    public IReadOnlyList<VmCandidate> Candidates { get; init; }
        = Array.Empty<VmCandidate>();
}

For example:

public sealed class VmCandidate
{
    public string VmSize { get; init; } = string.Empty;

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

    public bool Recommended { get; init; }
}

This allows the platform to show alternatives instead of presenting the first result as the only valid answer.

Add Cost and Policy Validation

Infrastructure optimization should not be based only on technical capacity.

A simple validation service can reject candidates that violate organizational rules.

public bool IsAllowed(VmCandidate candidate)
{
    if (string.IsNullOrWhiteSpace(candidate.VmSize))
    {
        return false;
    }

    return true;
}

In a real platform, this service could validate additional rules such as:

Approved VM families
Approved regions
Maximum monthly cost
GPU restrictions
Architecture restrictions
Security requirements

Keep these rules separate from the Azure optimization SDK.

This makes policy changes easier without modifying the integration layer.

Use Background Processing for Large Optimization Workflows

Not every infrastructure optimization request should run inside an HTTP request.

For a simple recommendation, an API request may be sufficient.

For a larger workflow involving several workloads:

Application Portfolio
       |
       v
Queue
       |
       v
Background Worker
       |
       v
Optimization Service
       |
       v
Policy Validation
       |
       v
Recommendation Store

A background worker can evaluate many applications without keeping an HTTP request open.

The results can then be stored for later review.

Store Recommendation History

Infrastructure recommendations can be useful later when investigating why a VM was selected.

A recommendation record might contain:

Application:
Order API

Requirements:
8 CPU / 32 GB

Region:
East US

Recommended VM:
Candidate A

Recommendation Time:
Recorded timestamp

Policy Result:
Approved

Deployment Result:
Successful

Avoid storing credentials or sensitive configuration in this history.

The recommendation history should contain the information required for auditing and troubleshooting, not secrets.

Add Observability

The optimization service should produce structured logs.

For example:

logger.LogInformation(
    "Infrastructure recommendation requested for region {Region} with {Cpu} CPU cores and {Memory} GB memory.",
    requirements.Region,
    requirements.MinimumCpuCores,
    requirements.MinimumMemoryGb);

Also log:

• Request identifier
• Workload identifier
• Region
• Recommendation result
• Validation result
• Deployment result
• Duration
• Failure reason

Do not log authentication tokens, client secrets, or other sensitive credentials.

Testing the Optimization Service

Because the SDK is isolated behind an interface, unit testing becomes easier.

For example:

public sealed class FakeOptimizationService
    : IInfrastructureOptimizationService
{
    public Task<VmRecommendation> RecommendAsync(
        WorkloadRequirements requirements,
        CancellationToken cancellationToken)
    {
        return Task.FromResult(new VmRecommendation
        {
            VmSize = "test-vm",
            Region = requirements.Region,
            Reason = "Test recommendation"
        });
    }
}

Tests can then validate application behavior without calling Azure.

Important test cases include:

• Missing region
• Unsupported architecture
• Minimum CPU requirement
• Minimum memory requirement
• GPU requirement
• Invalid storage requirement
• No suitable candidate
• Policy rejection
• Azure API failure
• Timeout
• Authentication failure

Common Mistakes

Calling the SDK directly from controllers

This makes testing and maintenance harder.

Keep SDK integration inside a dedicated service.

Hard-coding VM sizes

Infrastructure options change over time. Hard-coded mappings quickly become difficult to maintain.

Trusting the recommendation blindly

A recommendation is an input to the deployment process, not a replacement for policy validation.

Ignoring authentication boundaries

Do not embed Azure credentials inside application configuration or source code.

Returning only a VM name

A recommendation should explain why the candidate was selected and what constraints still need validation.

Logging sensitive Azure information

Infrastructure logs should contain enough information for troubleshooting without exposing credentials or secrets.

Best Practices

• Keep Azure SDK code behind an interface.
• Use dependency injection throughout the .NET application.
• Use supported Azure authentication mechanisms.
• Treat region as an explicit requirement.
• Separate workload requirements from infrastructure recommendations.
• Validate recommendations against organizational policies.
• Return alternatives when multiple candidates are suitable.
• Keep deployment automation separate from recommendation logic.
• Add structured logging and correlation IDs.
• Store recommendation history without secrets.
• Unit test the application without requiring live Azure calls.
• Re-evaluate infrastructure recommendations when workload requirements change.

Troubleshooting

Advantages and Disadvantages

When to Use This Approach

Using an infrastructure optimization workflow from a .NET application makes sense when infrastructure selection is part of an internal platform, deployment portal, migration tool, or automated provisioning process.

It is especially useful when several development teams need to provision workloads using consistent infrastructure rules.

For a single small application, introducing an optimization service may add unnecessary complexity. The architecture becomes more valuable as the number of workloads, deployment choices, regions, and infrastructure policies increases.

Summary

A .NET application can use an Azure AI infrastructure optimization workflow as a dedicated recommendation layer between workload requirements and infrastructure deployment.

The most maintainable architecture keeps the Azure SDK behind an application service, uses dependency injection, authenticates through supported Azure identity mechanisms, and separates technical recommendations from organizational policies.

The recommendation should not directly create production resources. Validate region, architecture, quotas, security requirements, cost limits, and workload compatibility before deployment.

With this separation, infrastructure optimization becomes a reusable part of a .NET developer platform instead of a collection of hard-coded VM selection rules.