Is cloud storage more expensive than hardware?  A TCO view

*updated August 2026

I’ve been hearing more organizations ask whether cloud storage is simply too expensive compared with buying hardware. It’s a reasonable question—especially when cloud pricing is presented as a visible monthly number and hardware is evaluated as a one-time purchase. But that comparison often leaves out the operational costs, lifecycle risk, and capacity-flexibility tradeoffs that determine the real total cost of ownership. This post is written for infrastructure and IT leaders who need to evaluate cloud storage costs against traditional hardware purchases on equivalent terms.

You Pay for What You Control

Cloud storage often looks expensive because it exposes costs that on‑premises environments quietly hide. When you compare total cost of ownership—not just raw capacity—the story changes.

The useful comparison is not cloud capacity versus hardware capacity. It is cloud service cost versus the full cost of delivering storage as a reliable service: capacity, performance, availability, lifecycle management, facilities, labor, and risk.

Let’s start with a simple analogy, taken from a familiar example: pizza. Making pizza at home, picking it up partially prepared, ordering delivery, or dining out all result in the same end product—but the cost structure and responsibility change dramatically. Some options give you maximum control, others trade that control for convenience, consistency, and predictability. Infrastructure works the same way.

Figure 1- https://pragmaticworks.com/blog/this-week-in-data-pizza-and-the-cloud

The cloud does not look expensive because it is inefficient. It looks expensive because it exposes costs that on-premises environments often hide, underestimate, or defer. Hyperscalers also purchase hardware, power, and data center services at volumes individual organizations rarely match, so the comparison needs to account for both bundled operations and buying power. To understand the real economics, we have to look past hardware acquisition and examine what it takes to deliver storage as a service.

ksThe yellow boxes represent the layers the customer controls and pays for directly. That control can be valuable: teams can choose the brand, size, lifecycle, configuration, and cost profile that best fit their environment. But every layer of control also brings ownership responsibility, including planning, patching, monitoring, troubleshooting, support renewals, and refresh cycles.

Now let’s apply this to Azure NetApp Files (ANF). Azure NetApp Files is a PaaS storage service. With ANF, teams no longer manage storage firmware, controller upgrades, hardware refresh cycles, performance tuning under failure scenarios, or capacity planning against physical constraints.

And this model still leaves out several cost categories that are easy to treat as background expense but very real in a storage TCO analysis:

  • Electricity (40-60% of the total cost of a data center)
  • Cooling – Chillers, HVAC, and/or liquid cooling for high-performance systems
  • Labor – Network operations, server operations, facilities maintenance, cleaners
  • Network equipment
  • Uninterrupted Power Supplies
  • Racks, KVMs, cable arms, etc.
  • Security Systems and staff
  • Generators + Fuel
  • Fire suppression systems
  • Building rental + Parking
  • Building out a data center – raised floors, additional power, etc.

In infrastructure terms: availability engineering, performance headroom, patching, lifecycle management, and incident response need to be considered —they’re either handled explicitly or quietly absorbed by your team.

1yr TCO

For simplicity, this example models a 100TB storage requirement and focuses on first-year cost categories a buyer would commonly evaluate. Actual results will vary based on performance tier, utilization, regional pricing, resiliency requirements, discounting, and how much operational cost is already allocated to the storage environment.

Once you account for those operational realities, the cost comparison becomes less theoretical. Let’s look at what this actually means for a typical 100TB deployment.  On-premises, your costs would look something like this:

CategoryCost Range
Hardware (Drives, controllers, shelves)$42,000–$78,000
Networking gear$6,000–$18,000
Software licensing$12,000–$36,000
Annual support (hardware + software)$18,000–$42,000
Facilities / Power / IT labor$24,000–$52,000
 8.5K-18.8K/m or 102K-226K/yr

*Expect 20–35% higher hardware costs and 15–25% higher power/ops costs compared to 2024–2025 baselines.

That is a wide range, but the range is not a weakness of the estimate. It reflects how variable on-premises storage economics become once utilization, growth, support renewals, and failure scenarios are included.

Now compare that with Azure NetApp Files (ANF), which offers more predictable consumption-based pricing. While past pricing behavior does not guarantee future pricing, the buyer can evaluate ANF as an operating-cost model rather than a hardware-refresh commitment.

Total Estimated First‑Year Cost for 100TB ANF, East US

ComponentEstimated Cost
ANF Flexible Cool (75% cool)7.5K/m or 90K/yr
ANF Standard Cool (75% cool)8.5K/m or 102K/yr
ANF Flexible (no cool)11.3K/m or 135.6K/yr
ANF Standard (no cool)12.4K/m or 148.8K/yr

5yr TCO

With hardware, you must buy a large enough device to last the lifespan of the hardware.  Let’s consider a customer who starts with 100TB, grows 20% a year, and is comparing hardware and ANF to host their storage.

Realistically, many customers find that a large percentage of capacity can be tiered to cool storage because ANF tiers at the block level and restores in seconds. For this analysis, let’s model the numbers with 75% tiered to cool.

The tables above show that ANF can be more expensive in some scenarios, but it will often be the more cost-effective choice when utilization, tiering, operational burden, and growth uncertainty are included. Instead of committing capital up front, teams can pay monthly and adjust capacity as growth rates change.

Conclusion

A practical way to test the comparison is to ask three questions: What performance and availability level must the workload sustain? How much capacity is truly active versus cold or infrequently accessed? And which costs are already visible in the budget versus absorbed by facilities, operations, or another team? Those answers often matter more than the raw price per terabyte.

When people claim that cloud storage is more expensive than hardware, they’re often not wrong in a narrow, line‑item comparison. But that comparison rarely reflects equivalent costs. On‑premises storage absorbs power, cooling, facilities, labor, maintenance, and operational risk in ways that are difficult to quantify—and very easy to overlook. Cloud pricing, by contrast, makes those costs explicit.

When you factor in the full operational footprint, services like Azure NetApp Files stop looking disproportionately expensive and start looking predictable. That predictability—along with reduced operational burden and faster time to value—is what organizations are actually buying. The question, then, isn’t whether cloud storage costs more than hardware. It’s whether organizations are comparing the same thing at all.

For technical teams, this isn’t just a pricing discussion—it’s a decision about where operational complexity should live. Azure NetApp Files makes that complexity explicit, priced, and predictable instead of implicit, fragmented, and risky.  Before declaring cloud storage “too expensive,” ask whether your comparison includes the costs you’ve already normalized.

TL;DR: Cloud storage often looks more expensive than hardware when the comparison stops at capacity price. But once power, cooling, facilities, labor, maintenance, lifecycle risk, utilization, and growth uncertainty are included, services like Azure NetApp Files can deliver a more predictable—and often more comparable—total cost of ownership. Add hyperscaler buying power and consumption-based flexibility, and the hardware-versus-cloud comparison becomes less about price per terabyte and more about where you want operational complexity to live.

Azure Disk Encryption (ADE) vs Storage Service Encryption (SSE)

When talking about VM data encryption a lot of customers start looking at Azure Disk Encryption (ADE) and Storage Service Encryption (SSE).  These two offerings are similar, but unique.  Whether you stick with SSE (always enabled) or add ADE on top is up to you – really it depends on your security needs and design.

Below is my quick breakdown of the pros and cons to help you decide what is the best design for your organization.

SSE (default)

ADE

and thanks for Eric Marks for raising this question!

Free Azure Training Resources

When you’re getting started with Azure there is so much to learn and so little time!  Below is a quick summary of the resources I recommend to my customers as they start ramping.

Azure Hybrid Use Benefit – Staying Compliant

Update 08/30/2019 – see also https://docs.microsoft.com/en-us/windows-server/get-started/azure-hybrid-benefit#how-to-maintain-compliance

Hopefully by now you are familiar with the Azure Hybrid [Use] Benefit (https://azure.microsoft.com/en-us/pricing/hybrid-benefit/) which allows you to save ~45% off the list price for Windows VMs, SQL VMs, and Azure SQL in Azure.  For those organizations with an Enterprise Agreement that includes Software Assurance this is an easy way save in Azure.

Microsoft doesn’t talk as much about staying compliant – i.e. not using more licenses than your agreement provides.

As the customer, it is your responsibility to stay in legal compliance with your license agreement.  While we don’t have a single tool to facilitate this “true up” (after all, the licenses span Azure and your other environments), we do have a high-level process and clear ways to track AHUB usage.

1.  Check in Azure to see how many AHUB cores are deployed per https://docs.microsoft.com/en-us/windows-server/get-started/azure-hybrid-benefit#how-to-maintain-compliance

2.  Using your own tools, scan your other environments (on-premises and other clouds) to determine how many licenses are consumed outside Azure

3.  Review your agreement and see how many licenses you have paid for

Then simply do the math.

Licenses Paid – licenses used = Licenses remaining

If you used more licenses that you have paid for, you must purchase more licenses or turn off the Hybrid Use Benefit on servers that are in excess of your agreement (see https://www.youtube.com/watch?v=YPv5SpTbzWs&t=23s for instructions).

This is something that will be discussed at enterprise enrollment renewal – but ultimately it is YOUR RESPONSIBILITY to stay in compliance at all times.

Azure Design Considerations–Enrollments, Subscriptions, and Resource Groups

When I first meet with new Azure EA customers, one of their first topics is “how do I set this up?”  Azure is very flexible, but this means you have design decisions to make:

  • how many enrollments do I need?
  • should I use departments?
  • should I separate teams using subscriptions or resource groups?
  • where do I apply RBAC (define access)?

While there are wrong answers, there is no one right answer.  Each organization will need to evaluate their needs, organizational structure, and use case(s) to see what works best for them now.  And if things change in the future, this design should change too.

Let’s break down the different control points.

image

First off, consider if multiple enrollments are needed or if multiple subscriptions within a single enrollment will suffice.

Subscriptions Enrollments
Separate Invoice X
Able to view charges at this level X X
Can use unique AAD Tenant X X
Can view charges in EA Portal X X
Can share an ExpressRoute X X
Simple to Administer X

Then consider how to further separate resources leveraging subscriptions and resource groups:

Resource Groups Subscriptions
RBAC supported X X
Easy to view Billing X (in Azure portal only) X (in EA and Azure portal)
Resource can be shared across X (natively) Requires additional configuration and only some resources are supported
Azure Policy supported X X
Best for Sandbox X
Best for restricting access in a common environment (i.e. PROD) X
Simpler to Administer X Multiple subscriptions create administrative overhead
Can share a single ExpressRoute X X

Keep in mind subscriptions can be grouped and administered in a hierarchy using Azure Management Groups (https://docs.microsoft.com/en-us/azure/governance/management-groups/).  Management groups allow you to set Azure Policy and RBAC centrally for governance with low overhead support.

image

Finally, in the EA portal itself make sure you are thoughtful in how roles are assigned and controlled.:

image

That’s my two cents on how to get started, but keep in mind this is a journey.  I recommend lots of whiteboard sessions to play with the different options and then test them out again real-world use cases.  The best designs appropriately limit access but are easy to implement and maintain.

Renaming an Azure Windows VM (Managed Disks)

In Azure, the renaming of resources (such as a VM) isn’t allowed.  That is, you can rename the OS/FQDN name of the VM at any time, but the display name in Azure is locked in at creation time.  If this bugs you, vote up the feature request here: https://feedback.azure.com/forums/216843-virtual-machines/suggestions/6132055-rename-vm

In the meantime, by tweaking a Microsoft provided script we can easily rename a VM by deleting the VM object (keeping all disks, NICs, IPs, etc.) and then recreating the VM using those existing objects.  The whole process should take ~10min (although it will vary based on the number of disks and NICs attached).

The below PowerShell script will work as-is for Windows VMs using managed disks and can easily be tweaked to run with Linux VMs or those using storage accounts.

# Nicole Welch, 10 January 2019 
# Rename existing Windows VM in Azure Portal (resource name)
# Based on https://docs.microsoft.com/en-us/azure/virtual-machines/windows/change-availability-set

Add-AzureRmAccount

# Set variables
     $resourceGroup = "Demo"
     $oldvmName = "myVM"
     $newvmName = "newVM"

# Get the details of the VM to be renamed
     $originalVM = Get-AzureRmVM `
        -ResourceGroupName $resourceGroup `
        -Name $oldvmName

# Remove the original VM
     Remove-AzureRmVM -ResourceGroupName $resourceGroup -Name $oldvmName    

# Create the basic configuration for the replacement VM
    $newVM = New-AzureRmVMConfig -VMName $newvmName -VMSize $originalVM.HardwareProfile.VmSize
    Set-AzureRmVMOSDisk -VM $newVM -CreateOption Attach -ManagedDiskId $originalVM.StorageProfile.OsDisk.ManagedDisk.Id -Name $originalVM.StorageProfile.OsDisk.Name -Windows

# Add Data Disks
     foreach ($disk in $originalVM.StorageProfile.DataDisks) { 
     Add-AzureRmVMDataDisk -VM $newVM `
        -Name $disk.Name `
        -ManagedDiskId $disk.ManagedDisk.Id `
        -Caching $disk.Caching `
        -Lun $disk.Lun `
        -DiskSizeInGB $disk.DiskSizeGB `
        -CreateOption Attach
     }

# Add NIC(s)
     foreach ($nic in $originalVM.NetworkProfile.NetworkInterfaces) {
         Add-AzureRmVMNetworkInterface `
            -VM $newVM `
            -Id $nic.Id
     }

# Recreate the VM
     New-AzureRmVM `
        -ResourceGroupName $resourceGroup `
        -Location $originalVM.Location `
        -VM $newVM `
        -DisableBginfoExtension

Express Route: Error Setting up VPN Gateway

This week I hit a new oddity while working with a customer.  Yes, an Azure customer!

He had setup Express Route (ER) dozens of times before, but this time it just didn’t work!  He went thru the VPN gateway setup and when tried to save/create the gateway he got this:  Set-AzureVnetConfig : BadRequest: The virtual network xxxxxx has a gateway with connection type ‘Dedicated’, but you are not allowed to use the Express Route feature. Only users who are registered for Express Route can use ‘Dedicated’ gateways.  And without a working gateway, there is nothing to connect the ER to your Azure environment.

After a chat with some internal experts, I learned a little known fact: the ability use ER is actually a setting on your subscription!  While most subscriptions allow this by default, occasionally this is NOT the case.  When that happens, you just need to put in a request for Microsoft to enable that option and you’re good to go!

*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2015/08/azure-express-route-error-setting-up-vpn-gateway/

Learning Azure, aka “The Cloud”

I spend my days supporting Azure and SCOM here at Microsoft.  When I mention to my SCOM customers that I also do Azure, one of the first questions I get is “how do you learn Azure?”  I thought I’d take a little time to share my experiences and recommendations.  This isn’t a formal plan but rather my thoughts based on my own journey.

When I first heard about “the cloud” it was at MMS 2009 in Las Vegas.  My first thought was “this will never work for my company!” but I was wrong 🙂  Azure offers a pricing structure that most organizations can’t resist (only pay for what you use, lower operational costs, etc.) combined with short deployment timelines, impressive security compliance (https://www.microsoft.com/en-us/TrustCenter/Security/default.aspx), and reliability.  Needless to say I don’t know of a single organization that isn’t considering, if not already using, a public cloud.

First off, don’t put pressure on yourself to “learn Azure” or any cloud platform for that matter.  The cloud is a vast, ever-changing concept more than a “product” to be mastered.  Public clouds cover the entire stack (networking and server hardware thru applications) and very few of us would claim that broad mastery of our on-prem environments.    Add to that the fact that Azure is constantly evolving (a good thing!) and you have a moving target.  As to that point, with Azure (and as you’ve probably heard Windows 10) Microsoft is moving away from huge service packs to smaller, more frequent updates.  This means no waiting two years for a bug fix, product enhancement, or new feature set.  Awesome, right?  It also mean things you couldn’t do last month may now be possible as roughly monthly new features rollout complete with updates to the Azure PowerShell module.  If you are really going into the cloud, you’ll want to follow some key blogs (like https://azure.microsoft.com/en-us/blog/topics/announcements/) to ensure you always know “what’s new.”  That brings us back to the question of what your goal should be.  Personally I think your goal should be to become familiar with Azure, how on-prem solutions would look in the cloud, and where to go for answers when you get stumped.

So you want to start learning, but where to start?  With an Azure subscription.  Think of a subscription as setting up a line of credit…it establishes a payment method and is used to assign administrator access.  For many of us, we can use the monthly Azure credit that comes with our existing MSDN subscription.  If you don’t have an MSDN subscription, you can get a free Azure trial here: https://azure.microsoft.com/en-us/free/.  You get a set dollar amount to spend each month; when that runs out your environment is frozen until the next billing cycle begins.

Once you have a subscription, it’s time to dig in and try it out.  There are tons of how-to blogs so I’m not going to focus on that aspect rather focus on how to make the learning process as painless as possible.  Since I have a background in Windows server infrastructure, my first step was to setup a DC and new forest in the cloud (*note there are many Linux images available in Azure too!).  This grew into a SCOM 2012 R2 lab which I now use daily.

The key is to build something you will use regularly, isn’t a single-point-of-failure (in case you mess it all up or run out of a credits before the month-end), and ties into what you do regularly.  If you are in charge of the monthly patch cycle, maybe you test in the cloud first (it only takes minutes to build a IaaS VM).  Maybe you are a web guy…I’d setup an IaaS web server and then also do a PaaS website so you can get familiar with the differences, pros/cons of each.  Depending on who is paying for this subscription, you can even use it for personal content (family website, photo storage).  The objective is to use it fairly regularly so you become comfortable with Azure.

Tips

  • Try to use as many of the Azure features as possible.  I.e. use Azure Backup so you understand how that works, etc.
  • Make the most of your free money remember if you’re not using it, turn it off (VMs, services).  In Azure you pay for resources consumed and an online VM consumes resources 24/7.  Turn it off at night and on weekends to save money (there are some good blogs on how to use Azure automation to do this for you).
  • Pay attention to PaaS offerings (http://blogs.msdn.com/b/hanuk/archive/2013/12/03/which-windows-azure-cloud-architecture-paas-or-iaas.aspx)..  Most people start with IaaS (me included) since that’s our comfort zone…the server we can kick.  IaaS roughly allows you to recreate your on-prem environment in the cloud, but that leaves you responsible for the OS.  If possible use PaaS offerings to take one more layer of support off your shoulders.  You want to stop worrying about patches, disk space, OS performance, etc. right?  PaaS and SaaS allow you to stop supporting the server infrastructure and focus on the applications and services.  While using PaaS isn’t possible in all cases (sometimes you need control over OS and application settings that are not exposed in PaaS) but when it’s a viable option use it!

Honestly, coming from large servers environments Azure required me to grow my skill set.  Remember when I said the cloud covered the entire stack (OSI model)?  Most of use have spent our careers focused on a single layer, but Azure presents many layers via a single console to administrators.  No longer does the network team setup my subnets, the storage team my SAN disks, and the server team install my OS.  Instead when you install your first VM, you need to do all of this!  Knowing what to set in Azure (i.e. static IPs that on-prem would have been set via a network device) versus the OS was a challenge for me at first.  Most companies will have a few staffers who understand and design/setup the cloud aspect while everyone else just connects to VMs/applications “as usual,” so don’t let this scare you.  And for those in smaller organizations, you may already have the broader knowledge needed!

One last note….  Right now Azure is transitioning from the classic portal (manage.windowsazure.com) to the “new” portal (portal.azure.com).  You can think of this as the evolution of the cloud from v1 to v2.  V2 (the new portal) has a different backend that allows new features (role-based access!), faster deployment, and scales much larger.  Regardless of which portal is used, your resources can talk to each other (https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-arm-asm-s2s/).  I’d recommend playing in both environments as the classic portal will be around quite a while and the new portal is still rolling out features.

I hope this helps you figure out where and how to start your journey.  Good luck exploring this brave new world!

*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2016/02/learning-azure-aka-the-cloud/

Moving Azure Images from the Commercial to the Azure Government Cloud (MAG)

*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2016/04/moving-azure-provider-images-from-the-commercial-to-azure-government-cloud-mag/

Some times we see customers move Microsoft provided images from the Azure commercial cloud to the Azure Government (MAG) cloud.  While this is technically supported, there are several things to consider.  When using the Microsoft provided images, there are configuration settings that are specific to the cloud environment.  When you move the VM (by moving the VHD), you risk having the wrong settings for your new cloud location.

Below is a list of settings that need to be changed.  This is NOT comprehensive and will be updated as needed.  Keeping mind the various endpoint that are different as well (https://azure.microsoft.com/en-us/documentation/articles/azure-government-developer-guide/)

Commercial Value MAG Value
KMS kms.core.windows.net:1688 kms.core.usgovcloudapi.net:1688

Azure IaaS VMs and the Three (now Four!) R’s

When you have a problematic IaaS VM (won’t start, won’t stop, can’t RDP even though it worked just yesterday….) and you’ve exhausted your usual tricks, turn to the Three Four R’s (the “did you reboot?” of Azure).

  1. Restart – Most users will think of this, just be sure you restart (and I mean a stop and start, not the restart button) from Azure (portal or PS) and not from the VM.  The Azure restart will give the fabric a chance to look for issues and self-heal.  Note: If you have a classic VMs (old portal) this also applies to your cloud service.  I’ve seen VMs acting up due to issues with their cloud service.  You can try restarting the cloud service….but keep in mind all hosted VMs by the cloud service will be restarted as well!
  2. Resize – Resizing (esp. if you increase the VM size to the largest possible), it will recreate certain elements of the VM <-> Fabric connection and could even move you to a new cluster node on the backend.   Resize, test to confirm it’s working, and then size back to your original size.  You will get charged at the higher VM size rate, but if it’s only for 15min that’s a minimal cost.  *Note: if you’re in ARM (VMs deployed via the new portal, not a classic VM) you can directly redeploy to a new cluster node using Azure powershell: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-redeploy-to-new-node/ (step 4 below)
  3. Recreate – This one sounds scary, but if you make a note of your current configuration FIRST the recreation is quick (generally <20min) and relatively painless.  If you need to move your VM to a new cloud service, VNet, etc. or are having those “it’s just acting up” issues this is a good troubleshooting step to try out.   You basically are removing the Azure components and then recreating the Azure components (modifying if needed) — all while leaving your disks untouched.  See https://www.petri.com/recreate-virtual-machine-in-microsoft-azure  for step-by-step instructions.  *Note: The link is specific to ASM (classic portal) but the premise works for both classic and ARM VMs.
  4. Redeploy – Available in the new portal only for ARM VMs (not classic).  Effectively the same as a resize, only guaranteed that you change nodes.  https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-redeploy-to-new-node/

If these all fail, and you already confirmed there are no outages that could impact you (https://azure.microsoft.com/en-us/status/), it may be time to engage Microsoft.

See also https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-allocation-failure/

*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2016/05/azure-iaas-vms-and-the-three-rs/