Cloud vs On-Premise Server Costs in Australia: A 36-Month Comparison

An Australian business facing a server refresh usually gets two numbers: a quote for new hardware and a rough monthly figure for cloud. Neither one answers the question. The useful answer comes from a 36-month model that puts the full cost of owning and operating a server against the full cost of running the same workload in Azure or AWS, with the same assumptions on both sides, migration shown separately from steady state. Build that model properly and you get something worth more than the decision itself: a known monthly run rate, a capital cycle you no longer have to fund every three to five years, and a recovery capability most SMEs cannot justify buying in hardware.

Thirty-six months is the right window because it matches the warranty and depreciation cycle on most SME server purchases. Anything shorter flatters on-premise, because the capital is already spent and the failure risk has not arrived yet. Anything longer flatters cloud, because you start charging the on-premise column for a second refresh that may never happen.

What actually belongs in the on-premise column

The hardware quote is the smallest honest part of it. A defensible total for keeping the workload in your comms room or a rack at a colocation facility includes:

• Server hardware, plus the storage and memory you will add in year two when the database grows
• Extended warranty or next-business-day support beyond the standard term
• Hypervisor and operating system licensing, and SQL Server licensing if it applies
• Power and cooling, or the monthly rack and cross-connect fee if the kit is in a datacentre
• The internet connection the workload depends on, and any redundancy on it
• Backup software, backup target hardware or cloud backup storage, and offsite retention
• Disaster recovery: a second box somewhere, or a replication service, plus the cost of testing it
• Endpoint and server security tooling, patch management and monitoring
• Administration labour, internal or outsourced, including after-hours patching windows
• An allowance for downtime, costed at whatever an unplanned day offline is worth to the business

That last line is the one most comparisons skip, and it is the one that moves the result. If a four-hour outage costs the business nothing much, on-premise looks fine. If a day of lost production or billable hours is material, the on-premise column has to carry either that risk or the cost of removing it.

What belongs in the cloud column

Compute is the headline and rarely the majority of the bill after year one. Model the same workload in an Australian region with:

• Right-sized VMs or managed database instances, not a like-for-like copy of your current over-provisioned hardware
• Managed disk or EBS storage at the performance tier the application actually needs
• Backup storage at your real retention, including any immutable or long-term tier
• Outbound data transfer, priced from the published Azure bandwidth rates or the AWS equivalent, based on a measured estimate of what leaves the region each month
• Public IPs, NAT gateways, load balancers, VPN or ExpressRoute circuits
• Log ingestion and retention, which has a habit of becoming a line item nobody forecast
• A support plan, if the business needs a response commitment
• High availability across availability zones, if the recovery objectives require it
• The management layer: whoever patches, monitors, backs up and responds

Both providers direct customers to their workload-specific calculators rather than list pricing, because region, operating system, commitment, licensing, storage, transfer and support all change the result. Build the scenario in the Azure pricing calculator and in the AWS equivalent with identical assumptions, and keep the saved estimate so you can rerun it when the design changes. Microsoft is explicit that calculator estimates depend on the customer's programme or offer, so a figure from a generic blog post is not your figure.

Licensing is the single biggest swing

A cloud comparison that pays retail for Windows Server and SQL Server on one side and reuses existing licences on the other is not a comparison. Microsoft's own pricing overview identifies Azure Hybrid Benefit as a cost-control mechanism for customers with eligible licences, and AWS offers both licence-included and bring-your-own-licence paths for the relevant services. Which one you can use depends on your Microsoft agreement, your Software Assurance position and the product in question.

Model at least four variants before you decide anything:

Comparing an Azure VM with Hybrid Benefit applied against an AWS licence-included instance produces a false result in Azure's favour, and comparing Windows on one platform against Linux on the other produces a false result in whichever direction suits the person building the sheet. Check the outsourcing and licence mobility terms in your agreement as part of this, not after.

Apply commitments after you have measured, not before

Commitment pricing is where the 36-month model gets interesting, and where businesses most often lock in a mistake. Microsoft says Azure reservations can reduce eligible service costs by up to 72 per cent on one- and three-year terms, with upfront or monthly payment. The Azure Savings Plan for Compute uses an hourly spend commitment instead and advertises up to 65 per cent on select compute services, with the flexibility to accommodate changes in eligible compute usage. On the AWS side, Savings Plans also require a one- or three-year hourly commitment and, importantly, do not reserve capacity, while EC2 Reserved Instances are quoted at up to 72 per cent with one- and three-year standard terms and zonal options that do provide capacity assurance.

The discount is real. The trap is committing to the wrong shape. A reservation bought against your first-month, lift-and-shift instance sizes becomes stranded the moment you right-size, change instance family or re-platform the database. A savings plan keeps applying even if demand falls.

The sequence that works:

1. Migrate at pay-as-you-go rates and accept that the first invoices are the worst they will ever be.
2. Run for several weeks with real production load, through a month-end and any known peak.
3. Remove orphaned disks, idle VMs, unattached IPs and test environments nobody turned off.
4. Right-size against measured CPU, memory and IOPS, not against the old hardware spec.
5. Separate permanent baseline capacity from seasonal or project workloads.
6. Commit only the baseline, and only to the term you are confident about.

Model the 36 months both ways: pay-as-you-go throughout, and pay-as-you-go for the first quarter followed by commitment pricing on the measured baseline. The gap between those two lines is the value of doing the measurement properly, and it is usually larger than the gap between the two cloud providers. Sequencing that measurement and the right-sizing that follows it is a core part of how cloud migration and ongoing cost management is run, because the discount only sticks if the architecture underneath it has stopped moving.

Keep migration costs out of the run rate

Show migration as a separate, one-off block: discovery and dependency mapping, landing zone and identity design, network and firewall configuration, pilot migration, replication, cutover, rollback planning, post-migration performance tuning and decommissioning the old environment. Dependencies drive that effort far more than VM count does — Active Directory, DNS, certificates, file shares, hard-coded IP addresses, scheduled jobs and third-party integrations are where the surprises live.

Mixing migration into the monthly figure makes cloud look expensive in year one and cheap thereafter, which helps nobody. Keep them apart and the comparison stays honest.

The lines the model does not capture

Two things sit outside the spreadsheet and still belong in the decision.

The first is residency and sovereignty. Choosing an Australian region is not by itself proof that every replica, backup, log, metadata record and support interaction stays onshore. ASD's September 2026 Information Security Manual warns that outsourced cloud services may be offshore and subject to lawful or covert data collection without the customer's knowledge. Check it service by service, including replication settings, disaster recovery location, identity, monitoring and managed backup.

The second is control ownership. Moving a server to Azure or AWS does not transfer your Essential Eight obligations to the provider. The ACSC's maturity model FAQ treats cloud services and internet-facing network devices as online services within scope, and patching, MFA, administrative privilege restriction, application control and regular backups remain yours to implement and evidence. Whatever that costs — tooling, labour or a managed service — belongs in both columns, because you need it either way.

Start with a 30-day usage baseline

Before you price anything, pull a month of performance data off the existing server: peak and average CPU, memory, disk IOPS, storage consumed versus allocated, and how much data leaves your network each month. Write down your RPO and RTO as numbers the business has agreed to, not as aspirations. Those five measurements determine almost every input in the cloud column, and without them the calculator output is guesswork with decimal places.

If you would rather have that modelled than build it, Precision IT will run the 36-month comparison for your actual workload: a right-sized Azure and AWS estimate using identical assumptions, licensing modelled with and without Hybrid Benefit, egress and backup retention priced from your measured figures, migration costed separately from steady state, and a plain answer on whether the move pays for itself inside three years or whether you should buy the server. Request a consultation and tell us what is on the box today.