Azure services offer different features and pricing tiers. Once you’ve chosen a plan, don’t leave its features unused. Find ways to fully leverage them to maximize your investment. Also monitor your billing patterns: it’s wise to check if there’s a pricing model better suited to your actual service usage.

Example Scenario

Contoso University uses a COTS (commercial off-the-shelf) system that helps teachers manage courses and students register. This system is connected to a cloud-based education management platform, which the university plans to fully migrate to in a few years. For now, it wants to optimize costs for the custom integration parts.

The COTS solution is generally considered a black box, except for its database, which runs on Azure Database for MySQL. The custom integration is a durable Azure function running in parallel on a Standard App Service plan, which previously hosted the university’s website (now retired). This durable function is a Python app that uses Azure Storage and synchronizes data nightly between the MySQL database and the cloud API.

Fully utilize the value of your resources

Buy only what you need, and use everything you pay for.

Some resource SKUs include built-in performance, security, or reliability features. If you pay for them, make sure you use them. And if you don’t need them, choose a simpler SKU to save money.

Contoso’s Challenge

The durable function runs on a Standard App Service plan originally sized for a public website, now retired.

The team never reassessed the SKU, so it continues paying for unused features and capacity.

It doesn’t know which features are truly necessary for the integration workload.

Approach and Results

The team reviews the current App Service plan and concludes that the integration doesn’t require as much scalability or performance. It migrates the function to a lower-tier plan, compatible with durable functions but much cheaper.

It also checks the MySQL SKU and confirms it fits the current workload.

These changes reduce costs without affecting performance or reliability.

Optimize high-availability design

Favor active-active or active-only models over active-passive, especially if you’ve already paid for resources.

An active-passive model can lead to idle resources. Switching to active-active can help handle load spikes without extra cost. If your recovery objectives can be met with an active-only model, you can eliminate passive resource costs entirely.

Contoso’s Challenge

The COTS application uses Azure Database for MySQL Flexible Server with high availability in the same zone, which involves a standby server. Automatic backups are enabled.

Recovery objectives are:

• RPO (Recovery Point Objective): 12 hours
• RTO (Recovery Time Objective): 3 hours during school hours

Tests show these objectives can be met through automatic failover or restore from backup.

Approach and Results

The team reassesses the cost-benefit ratio of high availability, knowing the service costs twice as much as a single instance.

It tests creating a new instance and restoring from backup and finds the objectives are still met. It decides to remove the standby instance.

The disaster recovery plan is updated, and the team saves money with this new configuration.

Smartly adjust capacity on demand

Scale capacity based on actual needs.

Instead of provisioning for maximum usage all the time, increase capacity when demand rises and reduce it when it falls. This approach aligns costs with real usage.

Contoso’s Challenge

The integration function runs nightly, but the App Service plan stays active all day.

The university pays for unused compute resources most of the time.

The team hasn’t explored sleep or auto-scale options.

Approach and Results

The team configures the App Service plan to reduce capacity outside active hours.

It considers migrating the function to Azure Container Apps or the Azure Functions Consumption plan, which can scale to zero.

It sets up alerts to monitor usage and adjust scaling rules.

These changes reduce waste and align costs with actual usage.