Everything to the Cloud, Including the Drawings
An 85-person architecture firm runs 14 VMs on two hosts (32 cores and 512 GB RAM each) backed by a 40 TB SAN with 22 TB used. Workloads are two domain controllers, a file server, an ERP application with SQL Server, two CAD license servers, a VDI pool for 20 contract drafters, and backup. Provisioned vCPU totals 210; measured 95th-percentile CPU utilization across all VMs is 12%. Each month the firm sends roughly 6 TB of drawing sets to clients and receives 1 TB. The CFO has an IaaS quote priced per vCPU and per GB, plus egress. Backups go nightly to a tape library 40 minutes away that has never been restore-tested. ERP targets are 4-hour RTO and 1-hour RPO. Internet is a single 500/100 Mbps circuit.
1. Which of the 14 VMs move to IaaS, which stay on-premises, and which get redesigned? Justify each with the numbers given.
Read the worked answer
Stay on-premises:
- File server and drawing distribution. 6 TB per month of egress at roughly $0.08-0.09/GB is about $550 per month, or $6,600 per year, for traffic that today costs nothing at the LAN. Worse, 6 TB over a 100 Mbps upload is about 5.6 days at full line rate - the firm physically cannot deliver drawings on deadline from a cloud file server.
- VDI pool for 20 drafters. Latency and GPU sensitive, and it hangs off a single non-redundant circuit. One fibre cut stops all 20 contractors. Redesign this, don't lift-and-shift it.
- One domain controller. Authentication must survive a WAN outage; otherwise nobody logs in and nothing on-prem works.
- CAD license servers. LAN-bound, low value, high annoyance if migrated badly.
Move to IaaS:
- ERP and SQL Server if the vendor supports it - 4-hour RTO is genuinely easier to meet with cloud snapshots than with tape 40 minutes away.
- Second domain controller as a cloud DR DC.
- Backup target as immutable object storage.
Redesign: the VDI. If contractors must work remotely, budget a second diverse circuit and price per-session cloud VDI against the on-prem hardware refresh - do not assume it is cheaper.
Ask the CFO one question first: what problem is the migration solving? If the answer is "DR," most of it can be solved on-premises for far less.
2. The IaaS quote is priced per vCPU. Given 210 provisioned vCPU and 12% utilization, how do you rightsize, and what else in the quote will bite?
Read the worked answer
The provisioned estate is roughly double what it needs to be. 210 vCPU on 64 physical cores is a 3.3:1 overcommit, which is normal on-premises and financially painful in IaaS, where you pay for provisioned vCPU whether or not it runs. A 12% 95th percentile means most of those vCPUs are decoration.
Method:
- Collect 30 days of performance data at 5-minute granularity.
- Size each VM to its 95th percentile plus 30% headroom, with a floor of 2 vCPU.
- Do not size to one-second peaks; a batch job that spikes for 90 seconds is not a sizing input.
- Expected outcome: roughly 90-110 vCPU, halving the compute line item.
Memory is not free either. 1 TB provisioned cannot be safely overcommitted in IaaS. Measure active memory, not allocated memory - hypervisor ballooning statistics show which guests are holding RAM they never touch. Windows and SQL Server routinely run in half their allocated memory.
What will bite in the quote:
- Per-core software licensing. SQL Server and Windows Server per-core licensing can cost more than the compute it runs on. Confirm BYOL and license mobility rights before signing.
- Egress on backups restored for testing - DR tests generate the bill nobody budgets.
- Pricing model. Take committed/reserved pricing for the steady-state baseline and on-demand only for burst; paying on-demand for 24/7 workloads is the most common migration mistake.
3. The CFO says the cloud will also serve as DR. Assess that against the 4-hour RTO and 1-hour RPO.
Read the worked answer
Today's state already misses the target. Nightly tape gives a 24-hour RPO against a 1-hour requirement, and an untested tape 40 minutes away gives an unknown RTO. Before designing anything, run an actual restore of the ERP and SQL databases and time it. Most firms discover this number for the first time during an outage.
A cloud DR plan on a single circuit moves the single point of failure rather than removing it. With one 500/100 Mbps link and no diverse path, any WAN outage is a total outage for anything cloud-hosted - so the cloud becomes an additional dependency, not insurance.
Recommendation:
- Fix RPO first - hourly VM-level replication or snapshots to offsite object storage. This is achievable and cheap; tape is not.
- Keep a warm standby of the ERP in the cloud with a written runbook, and test failover quarterly, not annually. An untested runbook is a rumour.
- Add a second circuit on a physically diverse path, with 5G failover, before promising any RTO that depends on the internet. Price the circuit against the cost of four hours of downtime - it is usually the cheaper line item.
- Immutable, air-gapped copies. An attacker with domain admin can delete cloud backups along with production. Versioning and object lock are non-negotiable for ransomware.
Verification: the RTO claim is only credible once you have failed over and failed back, on a Saturday, with the team that will actually do it at 2 a.m.