Tailwind: Reaching 99.99% and Paying for It
Tailwind runs a public web app in West Europe. The web tier is 6 Standard_D4s_v3 VMs in a single availability set behind a Standard Load Balancer; the app tier is 2 VMs, and SQL Server runs on a single IaaS VM. The availability objective is 99.99%, and an audit found the web tier went offline for 22 minutes when one West Europe datacenter lost power. Deployments use a custom script extension that installs the application and takes about 35 minutes per VM, so a rolling deployment takes over three hours. Monthly spend is €46,000, of which €9,000 is a dev/test subscription where 14 VMs run 24x7 but are used only 09:00–18:00 on weekdays. The web tier is CPU-bound at 80% between 10:00 and 16:00 and idle overnight.
1. What must change architecturally for the web tier to have a defensible 99.99% claim, and why does the current availability set fail the audit?
Read the worked answer
The availability set is the reason, not the load balancer.
An availability set separates VMs across fault domains and update domains within one datacenter. It raises the SLA to 99.95% and protects against rack and host failure and planned maintenance - it cannot protect against a datacenter power loss. The 22-minute outage is exactly the failure mode an availability set does not cover.
Change:
- Deploy the web tier across availability zones in West Europe, with at least two VMs in each of two or more zones. Standard Load Balancer is zone-redundant and will front them.
- Two VMs spread across zones is the minimum for the 99.99% VM SLA; one VM alone is 99.9% with premium storage, and two VMs in the same zone is not a zonal deployment.
- Follow the dependency chain. The SLA claim covers the VMs, not the solution. The app tier's 2 VMs and the single SQL Server VM are still single points of failure - zone-redundant SQL (Always On availability group across zones, or a zone-redundant managed instance) is required, otherwise the web tier's 99.99% is decoration.
- If the objective must also survive a regional failure, zones are insufficient; that needs a second region plus Front Door or Traffic Manager, and a cross-region data strategy.
2. Recommend how to reduce the €9,000 dev/test spend without breaking developer workflows.
Read the worked answer
Attack hours first, then SKU, then rate.
- Auto-shutdown / auto-start. 14 VMs used 09:00–18:00 on weekdays are powered ~168 hours a week but needed ~45. Auto-shutdown at 19:00 and scheduled start at 08:00 removes roughly 60% of compute hours - the single largest lever.
- Subscription pricing. Move the subscription to a Dev/Test offer if the team qualifies (Visual Studio subscribers). This gives discounted rates on Windows and SQL and, importantly, no production SLA - acceptable for dev/test.
- Right-size SKUs. Dev/test VMs are usually idle-heavy; B-series burstable SKUs handle low baseline CPU far cheaper than D-series.
- Commit where the load is constant. For the handful of VMs that must stay up 24x7 (build agents, shared services), buy 1-year reserved instances - but do not reserve the ones you just started shutting down nightly.
Sequencing matters: shut down first, then measure actual sizes, then reserve. Reserving before the schedule change locks in capacity for VMs that no longer run.
3. A deployment takes over three hours. Reduce it while keeping the ability to roll back, and address the daytime CPU ceiling.
Read the worked answer
The custom script extension is doing build work at deploy time. Every instance downloads and installs the application for 35 minutes, and a rolling upgrade serializes those windows.
Deployment fix:
- Bake the application into an image and publish it to Azure Compute Gallery as a versioned image. Deployment then becomes allocate + attach + health-check, measured in minutes. Gallery versioning gives rollback: redeploy the previous image version.
- Run the fleet on a VM scale set (Flexible) with a rolling upgrade policy -
maxBatchInstancePercentandmaxUnhealthyInstancePercentbound the blast radius, and the upgrade respects health probes rather than a fixed sleep. - Keep the custom script extension only for last-mile configuration (secrets, environment tags), not installation.
Daytime CPU: 80% at peak and idle overnight is the textbook autoscale profile. Scale out on a CPU rule with a cool-down, set a minimum of 3 instances spread across zones so scaling in never collapses to a single fault domain, and keep the maximum above the observed peak. The overnight idle window is also when the rolling upgrade should run.