“How much RAM do I need?” is the single most expensive question in Windows VPS planning. Over-specify and you pay every month for idle cores; under-specify and SQL Server starts paging to disk, IIS request queues climb, and every user blames the hosting provider. This guide is a sizing reference: it maps the four most common Windows Server workloads — IIS/.NET, SQL Server, Active Directory, and Remote Desktop Services — to concrete vCPU and RAM figures, with the reasoning behind each number.
Sizing starts with the workload, not the price. If you are still deciding what a Windows VPS is in the first place, start with our Windows VPS guide and come back here with a workload in mind.
The three numbers that matter: vCPU, RAM, and disk IOPS
vCPU is the easiest to oversell and the hardest to measure. A “4 vCPU” plan on an oversubscribed host can behave like a single core under contention. RAM is the opposite: you can measure exactly how much a workload holds, and Windows will happily use every gigabyte you give it. Disk is the quiet third axis — a SQL Server with plenty of RAM but 200 IOPS of shared storage will still crawl during a checkpoint.
- vCPU — size to peak concurrent CPU, not average. Plan for 30–50% sustained headroom so a single spike does not queue.
- RAM — the primary lever. Each Windows Server 2022 instance idles at roughly 1.0–1.5 GB. Add the workload’s working set on top.
- Storage — demand SSD/NVMe. Latency above 10 ms at the guest level will be visible as application stalls long before the disk looks “full”.
Workload sizing reference table
| Workload | vCPU | RAM | Storage | Notes |
|---|---|---|---|---|
| Single low-traffic IIS site (static, <50k hits/day) | 2 | 4 GB | 60 GB SSD | Worker process + 2–3 app pools; keep RAM above 4 GB to leave room for Windows Update. |
| ASP.NET / .NET Core API, moderate traffic | 4 | 8 GB | 100 GB NVMe | Allow ~1 GB per 4–6 concurrent app pool working sets. |
| IIS + SQL Server, small line-of-business app | 4–8 | 16 GB | 200 GB NVMe | Cap SQL with max server memory at 70% so IIS keeps its headroom. |
| SQL Server standalone, production OLTP | 4 | 16 GB | 250 GB NVMe | Minimum sensible production floor. Below 16 GB, buffer cache pressure dominates. |
| SQL Server, mid-size DB (50–200 GB) | 8 | 32 GB | 500 GB NVMe | Separate tempdb onto its own volume where possible. |
| Active Directory Domain Controller | 2 | 4 GB | 80 GB SSD | DC for <500 users. AD is light; DNS and replication consume most of it. |
| File/print + AD role combination | 2–4 | 8 GB | 150 GB | Add ~2 GB per 100 GB of actively served file data for caching. |
| RDS session host (10–15 light users) | 4 | 16 GB | 150 GB NVMe | Budget 1–1.5 GB per concurrent user for Office + browser. |
| RDS session host (25 users, Office-heavy) | 8 | 32 GB | 250 GB NVMe | Watch per-user memory; Outlook alone can hold 400–800 MB each. |
| Build/CI agent (.NET, MSBuild) | 4–8 | 16 GB | 200 GB NVMe | MSBuild and NuGet restore are bursty; leave core headroom. |
Sizing IIS and .NET applications
IIS itself is cheap; the application pool working sets are what you size for. A useful starting formula: RAM = 1.5 GB (OS) + (concurrent app pool working sets × average working set) + 1 GB margin. A typical ASP.NET Core service holds 150–300 MB per app pool under load; a legacy ASP.NET MVC app with lots of caching can hold 500 MB or more.
# See which app pools are actually holding memory
Get-Process -Name w3wp |
Select-Object Id, @{n='PoolMB';e={[math]::Round($_.WorkingSet64/1MB)}}, StartTime
# Map process to app pool
Import-Module WebAdministration
Get-IISAppPool | Select-Object Name, State, ProcessModel.IdIf you can only add one resource, add RAM before vCPU for IIS. Thread-pool starvation is usually a symptom of garbage collection pressure caused by a small heap, not insufficient cores. Set gcServer: true in runtimeconfig.json for throughput-oriented .NET Core APIs, and give the app pool a private memory limit only as a safety valve, never as a sizing tool.
Sizing SQL Server
SQL Server will consume all available memory for buffer cache unless you stop it, which is why an unbounded SQL instance on a shared VPS eventually starves everything else. Cap it explicitly:
-- Leave at least 4 GB (or 20%) for the OS and other roles
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', 12288; RECONFIGURE; -- 12 GB of a 16 GB box
-- Baseline: how much buffer cache is actually in use
SELECT object_name, counter_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE counter_name IN ('Page life expectancy','Buffer cache hit ratio','Page reads/sec');Page Life Expectancy below 300 seconds is the classic signal that you are short on RAM. For CPU, count cores the way SQL does: 4 cores = 8 logical schedulers on hyper-threading. A useful heuristic is 2–4 active cores per 100 concurrent user connections for OLTP, with MAXDOP set to the number of physical cores up to 8.
Sizing Active Directory
AD is the least demanding Windows Server role and the one people most often over-provision. A domain controller for up to 500 users runs comfortably on 2 vCPU and 4 GB RAM. The exceptions that push you to 4 vCPU / 8 GB are: hosting DNS with heavy query volume, running additional roles (Certificate Services, File Services), or serving more than about 2,000 objects with frequent LDAP searches.
- Place
NTDS.ditand its logs on separate virtual disks if the provider allows it; a single busy volume causes checkpoint stalls that users perceive as slow logons. - Never size a DC for “just” 2 GB — Windows Server Domain Services plus DNS plus the OS will consume it and event log shipping will start failing.
- For two DCs in a VPS environment, run them on separate hosts or at least separate physical nodes so a hypervisor maintenance event cannot take both down.
Sizing Remote Desktop Services
RDS is the workload where “per-user” sizing is unavoidable, and where storage IOPS decides user satisfaction. Plan for these per-session budgets:
| User profile | RAM per session | Notes |
|---|---|---|
| Single business app, text-based | 300–500 MB | Thin-client style workloads. |
| Office + browser, light use | 1.0–1.5 GB | The common small-business case. |
| Office + browser + heavy Excel macros | 1.5–2.5 GB | Excel itself can hold hundreds of MB per workbook. |
| CAD / engineering app | 3–6 GB | Move to dedicated session hosts or a GPU-backed VM. |
On top of per-user memory, add 2 GB for the OS and 1–2 GB for the RDS role services. So 15 light users implies 16 GB; 25 Office-heavy users implies 32 GB. CPU-wise, RDS sessions are bursty — 4 vCPU per 10–15 light users is a reasonable starting ratio, and concurrency is usually 40–60% of named users during business hours.
Common sizing mistakes
- Counting vCPU as dedicated cores. Shared plans oversubscribe. If your workload is latency-sensitive, ask for dedicated or near-dedicated cores.
- Forgetting the update tax. WSUS, Defender scans and cumulative updates routinely demand 1–2 GB of transient RAM.
- Sizing the paging file off. Windows needs pagefile headroom for crash dumps and commit charge; leave the system-managed pagefile on a fast volume.
- Ignoring backup and antivirus agents. They add 200–500 MB and meaningful IOPS, especially during full scans.
- Growing only disk. If you consistently exceed 70% RAM utilization at peak, adding disk will not help — resize RAM.
A practical sizing workflow
# Measure against your current peak, not a single sample
Get-Counter '\Memory\Available MBytes','\Processor(_Total)\% Processor Time' -SampleInterval 5 -MaxSamples 60 |
Export-Counter -Path C:\perf\baseline.blg -Force
# Then decide: more RAM or more vCPU?
# Rule of thumb: >70% memory committed at peak => add RAM
# >80% CPU sustained for 5+ min => add vCPUThe right order of operations is: pick the workload, apply the table above, run it for two weeks with a performance baseline, then resize once based on real data. If you need to compare Windows VPS options across multiple providers with different vCPU/RAM ratios, do that comparison on price-per-GB-of-RAM first — RAM is what your workloads will actually consume.
Related reading: SQL Server performance tuning on a Windows VPS, Windows Server performance monitoring tools, and Windows VPS vs Linux VPS if you are still deciding on the platform.
