Question: what is the effective overhead of Windows Azure?

Problem: If memory is swapped out often, the application will come to a grinding halt. Renting a larger instance costs money. By knowing what I need, I can simply calculate what I should rent.


I've been running Azure compute roles for quite some time now. However, something that I still don't have a firm grip on is the 'overhead' that Microsoft Azure adds to the instances. Overhead is primarily 'memory' here.

More details: these are .NET role instances, 1 role per VM.

Basically what I would like to do is calculate how much memory my application uses and relate that to the instance size (e.g. if I have an application that I know to effectively use 400 MB of memory, I want to calculate if I should use a 768 MB role or a 1.3 GB role).

Reasons for this question

The reasons why I want to do this are plentyful; I can choose to optimize the memory pressure in the program if I'm just above a certain memory limit, I can choose to rent another instance if that's more cost-effective, I can decide to use more instances, etc. Without the proper information, I find it impossible to make these business cases.

Examples of information I'm looking for

Overhead comes in a variety of ways:

  • Overhead of worker role VM. Cost in terms of memory / CPU?
  • Enabling remote desktop / remote debugger. Cost in terms of memory / CPU?
  • Overallocation of virtual machines on physical machines. E.g. if I have 14 XS instances that use 768 MB on 1 physical machine, and that physical machine has 8 GB of memory, it means 2 GB will be swapped out. How much memory (%) can I effectively count on?
  • Other stuff that affects memory?

Basically I'm happy with anything that boils down to [effective memory] = [program memory cost] * a + b; where b can be a configuration setting, a feature or a constant.

  • 2
    Why do you care? the overhead is host memory not guest memory - it's MS's 'cost' not yours
    – Chopper3
    Jul 13, 2015 at 10:12
  • 1
    @Chopper3 Because I've seen instances come to a grinding halt with lots of disk IO (I'm guessing: swap) although they've only used +/- 100 MB of memory. That's 'guest' I'm talking about, not host. I'm guessing swap because I'm not using the local disk; I'm only using cloud storage.
    – atlaste
    Jul 13, 2015 at 10:25
  • That could be due to serious over-consolidation on MS's part, we've no way of telling, they don't publish that kind of information. What I do know is that whatever you're doing, you're not directly in control of that kind of behaviour - though you could contact them and explain your observations, perhaps they could move your VM/s to a less constrained cluster - either way it'd not your behaviour that dictates this performance issue and nothing you can do would be predictable anyway - it's just how they're choosing to run their host estate.
    – Chopper3
    Jul 13, 2015 at 11:44
  • 1
    @Chopper3 Well, the reason I'm asking is because I'm not sure about that. F.ex. If Win2012 needs 400 MB to do its work (cache, services, etc), it makes sense to subtract that from the advocated 'memory' of the instance and calculate using that. Assuming an over-allocation of 20%, that leaves you with effectively 768 MB => (768 * 0.8 - 400) = 214 MB to play with. However, for me all of this is based on speculation, so perhaps an expert has some more insight about how to calculate this.
    – atlaste
    Jul 13, 2015 at 11:51
  • 2
    I don't mean this to sound horrid but I think you need to learn more about how hypervisors use memory as you seem to be overcomplicating matters - if you've bought say 1GB of memory then that's what the hypervisor gives your VM, it doesn't care about what's OS, what's app, what's data etc., it just gives you the memory - if MS aren't reserving all of that memory for you then that's their policy and a commercial decision, not a technical issue you can control directly.
    – Chopper3
    Jul 13, 2015 at 12:14

1 Answer 1


It's hard to find this kind of information as it's never publicly announced by Microsoft, and lots of factors comes into play on deciding how much RAM the OS will use, however I will try to answer to the best of my ability based on the usage of VMs inside Azure, since basically VMs and role instances are using the same OS, the difference between them would be who's in charge of maintenance, how availability is configured, auto scaling... etc.

Microsoft says that to install Windows 2012 R2 Server, you will need at least 800 MB of RAM. After the installation is done, you can go as low as 512 MB of RAM and the OS would still run, You may use this number as a Base for how much Windows Server needs RAM to run. You can squeeze it to go beyond the 512 MB mark by removing GUI and scaling back to Server Core Installation

You can measure the memory overhead by firing up a couple of test machines using different sizes, RDP to the machine and see where Windows is resting on the memory front, I have done an exercise like that a while ago and the below table summarize my findings, note that all the VMs are installed with GUI.

VM tier with RAM - RAM consumed by OS

A0 768 MB - 500/600 MB

A1 1.75 GB - 750/900 MB

A2 3.5 GB - 850/1000 MB

Anything you use right after this stage, the OS would sit comfortable within the 1.5 GB limit. Since you're using roles instances, I would throw more RAM to each instance by a small margine and calculate my way from there.



  • Thanks for providing me with an answer. What's also interesting is that I haven't considered the possibility that worker roles without remoting might be server core instances.
    – atlaste
    Jul 14, 2015 at 6:13
  • Noor, so far it turns out to be correct with my observations. I'm still curious about the worker roles / server core combination; if you disable remote desktop and remote forwarder + module, I'd say it should deploy as server core, but I have no way to validate that. Either way, I'll accept this answer.
    – atlaste
    Jul 17, 2015 at 7:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .