Software infrastructure cost: a practical guide for founders

TL;DR: Software infrastructure cost is everything you pay to keep an app running, not just the cloud invoice. Engineering time is usually the biggest line and almost nobody counts it. Track five numbers, tag every resource from day one, and budget for the Australian extras: GST, data sovereignty, and a cloud bill priced in USD.

Most founders think their infrastructure cost is the number on the AWS invoice. It isn't. The invoice is the part you can see. The rest sits in engineering hours, licence fees, data transfer and the time your team loses to unplanned work.

Here's the thing. On a small team, the cloud bill is often the smallest line in the whole picture. An engineer spending a day a week on infrastructure costs more than most early-stage AWS accounts. If that time isn't in your model, your model is wrong.

This guide covers what actually counts as infrastructure cost, what pushes it up, how to track it, and the Australian details that generic cost calculators miss.

What counts as software infrastructure cost?

Everything you pay to keep the thing running. That splits into a few groups.

On the cloud bill:

• Compute. Instances, containers, node pools. Charged by the hour.
• Storage. Object storage, block volumes, database storage. Charged per GB a month.
• Egress. Data leaving your cloud region. One of the most underestimated lines for Australian apps serving overseas users.
• CDN. Delivery charges, billed separately from origin egress.
• Platform services. Managed databases, load balancers, API gateways, managed Kubernetes.
• Backup and recovery. Snapshots, cross-region copies, the tooling that meets your recovery targets.
• Monitoring. Log and trace ingest, plus retention. This one surprises teams at growth stage.
• CI/CD. Build minutes or the compute behind your own runners.

Not on the cloud bill:

• Licences and seats. Auth, payments, messaging, feature flags. Billed per seat or per event.
• Security tooling. Firewall rules, secrets management, vulnerability scanning.
• Internal labour. Engineering hours spent provisioning, patching, debugging and improving. Almost never counted. Usually the biggest number.
• External labour. Contractors, managed service providers, agencies.
• Facilities. Rack space, power and cooling, if any part of your stack is on-premises.

Costs compound as environments multiply. A staging environment that mirrors production doubles a lot of these lines. Keep the stack simple until real scale forces your hand.

What drives the cost up most?

Ranked by what we see hurt teams most often.

1. Engineering labour. The biggest driver at every stage. Moving to a managed platform can cut infrastructure hours down hard, and the engineering saving usually beats the slightly higher hosting bill.
2. Overprovisioned compute. Teams size for peak, then never revisit it. An instance sitting at single-digit CPU use is a normal finding on a first audit.
3. Storage with no retention policy. Logs, snapshots and backups pile up forever unless something deletes them. Cheap per GB. Not cheap at scale.
4. Egress. Australian regions charge for data leaving. Apps shifting large files or syncing big datasets overseas rack this up fast.
5. Unused licences. Seats bought for people who left. Audit them quarterly and claim them back.
6. Monitoring ingest. Sending every log line and every trace with no sampling is one of the fastest ways to get a shock invoice.
7. Multi-region failover. Running active-active across two regions roughly doubles compute and transfer. Confirm you actually need it first.

Soft costs dominate as systems grow. Engineering time, rework, and the delivery you didn't get because someone was firefighting. None of it appears as a line item. Budget for it anyway.

How the cost splits between people and machines

The mix shifts as you grow, and it shifts in a way most founders find backwards.

Early on, the cloud bill is trivial and labour is nearly everything. A couple of hundred dollars of hosting sits next to twenty hours a month of engineering time. The machines are cheap. The people are not.

At scale the cloud bill grows into real money. But labour grows too, because now you have someone whose job is infrastructure. The ratio evens out. It rarely flips.

That's the point. If you only track the invoice, you are tracking the part that matters least when you are small and about half of what matters when you are big.

For your accounts, tag every cost three ways: environment (production, staging, dev), product or feature, and customer or tenant if you run multi-tenant. That's the minimum needed to get a cost-per-customer number.

On Australian reporting, cloud hosting fees are generally operating expenditure. Some custom software development costs may qualify to be capitalised as an intangible asset, which changes how they land on your balance sheet. GST applies to most cloud services used here. This is general guidance. Confirm the treatment with your accountant.

How to measure and monitor your spend

Track five numbers every month.

• Monthly run rate. Cloud bill plus the engineering hours you allocated to infrastructure.
• Cost per environment. What production costs against staging and dev combined.
• Cost per feature or service. Needs resource-level tagging to work.
• Engineer hours on infrastructure. A weekly survey is enough. It doesn't need to be perfect.
• Incident cost. Unplanned hours multiplied by a loaded hourly rate.

Then track infrastructure spend as a share of revenue and watch the trend. The absolute number going up is fine if it's growing slower than revenue. The absolute number going up while revenue is flat is the thing to catch early.

For tagging, pick a convention on day one and enforce it with policy. Require `env`, `team`, `product` and `cost-centre`, and block anyone creating resources without them. Retrofitting tags across a live account is miserable work.

Review weekly at team level and monthly with the leadership group. Once a quarter, do a proper audit: untagged resources, orphaned snapshots, idle instances.

Start with the free tools. AWS Cost Explorer and the equivalents on the other clouds handle most of what a small team needs. Pay for a dedicated cost tool when your spend is big enough that a few percent of savings covers the licence.

Practical ways to cut spend without breaking your SLAs

1. Move to a managed platform where engineering time is the bottleneck. The hosting bill may rise a little. The time saving is usually bigger.
2. Right-size compute. Run your cloud's own sizing recommendations for a fortnight, then act on them. Fastest win on the invoice, most of the time.
3. Autoscale, and scale down out of hours. Non-production environments do not need to run overnight or on weekends. Production autoscaling needs load testing first.
4. Commit to capacity you're sure about. AWS publishes savings of up to 72% against on-demand pricing for one and three year commitments. Only commit to your confirmed baseline.
5. Cache, and put a CDN in front. Application caching and static assets on a CDN cut both origin compute and egress.
6. Set storage lifecycle rules. Move cold objects to archive tiers after a month or two. Delete old snapshots automatically.
7. Sample your monitoring data. Sampling cuts ingest cost sharply and you keep the diagnostic value. Most teams do not need every trace.
8. Audit licences monthly. Reclaim seats before the next billing cycle, not after.

One trade-off worth naming. Committed capacity locks you in for a year. If your architecture changes, you pay for capacity you no longer use. Start with a partial commitment covering the load you are confident about.

Cost scenarios for Australian apps

These are illustrative ranges built from common stack patterns, not a quote. Your region, traffic, team and vendor deals will move them. All figures are AUD and exclude GST.

Engineering hours above are costed at an illustrative loaded rate of $150 to $180 an hour. Use your team's real number. Add GST to vendor invoices where it applies.

Look at what moves between the rows. At MVP stage the swing factor is engineering time. At scale it's egress and monitoring ingest. That's why early builds should stay simple and add complexity only when traffic or compliance forces it. Our guide to what it costs to build a custom app covers the build side of the same question.

How to budget and forecast

1. Inventory everything. Export the billing data. List every active service, every SaaS tool, every contractor invoice.
2. Tag and allocate. Push costs onto environments and products using the convention above.
3. Normalise the history. Take three months of actuals for a baseline. Strip out one-off migration and incident spikes.
4. Add an incident average. Track unplanned engineering hours over the same period and fold the monthly average in.
5. Add a buffer. Fifteen to twenty percent covers growth, incidents and vendor price rises.
6. Model three futures. Flat growth, double the traffic, and a compliance event such as a new data residency rule. Show investors all three.

For board and investor decks, put cost per customer next to the absolute number. A rising total with a falling cost per customer is a healthy business. The reverse is the one to explain.

Outsource or keep it in-house?

Outsource when infrastructure is not your differentiator, when you need certifications you don't have in-house, or when you need to move faster than hiring allows. AI-Led has a good breakdown of the same call on the AI side in build versus buy.

Keep it in-house when infrastructure genuinely is the product, when you already have the people, or when data sovereignty rules make third-party access complicated.

When you're weighing up an Australian partner, ask:

• Do you host data in Australian data centres, and which ones?
• What is your incident response commitment, and how is it measured?
• How is GST handled on your invoices?
• Do we get a runbook and a proper handover at the end?
• Is pricing fixed, time and materials, or a managed monthly fee?

Red flags worth walking away from: no local data centre option for regulated work, vague GST treatment on quotes, no runbook, and USD-only pricing with no AUD equivalent.

How compliance and data sovereignty add cost

Australian businesses handling personal data fall under the Privacy Act and the Australian Privacy Principles. Health, finance and government work carries more on top, including assessment under IRAP for a lot of government workloads.

That adds cost three ways. It limits your region choice, and Australian regions cost more than US ones for the same compute. It requires audit and certification work, which means dedicated tooling, longer log retention and periodic assessments. And it often forces replication inside Australia for disaster recovery, which adds storage and transfer on top of a single-region setup.

None of this is a reason to avoid regulated work. It is a reason to price it properly before you sign.

How the exchange rate and GST hit your budget

The big clouds price Australian region services in USD. You pay in AUD at whatever the rate is that month. So your bill moves even when your usage doesn't. A ten percent fall in the AUD puts your cloud spend up ten percent for exactly the same consumption.

GST applies at ten percent to cloud services used here. The major providers are registered and include it on Australian invoices, which makes it claimable as an input tax credit if you're registered. Check the invoice carries an ABN before you claim.

For budgeting, model the spend in USD and apply a conservative exchange rate. Being pleasantly surprised beats the alternative.

Public cloud or a private datacentre?

Public cloud gives you pay as you go, no capital outlay and fast provisioning. You pay for that with a higher per-unit cost at sustained load, and USD pricing.

Co-location and private facilities give you predictable AUD costs, physical control, and better economics at high steady utilisation. You pay for that with capital expenditure, slow procurement, and the overhead of running hardware.

For most Australian founders, public cloud is the right default. Private infrastructure only starts to win when you have sustained predictable load, a cloud bill in the tens of thousands a month, strict latency needs, or a regulator who won't accept shared infrastructure.

Negotiating with vendors in Australia

Cloud providers negotiate. All the majors have committed-spend discount programs. Get your account manager on the phone once your monthly spend is into four figures and ask directly for a private pricing proposal. The worst outcome is no.

Check your contracts before the auto-renewal date. Most vendors want a month to three months notice if you're going to renegotiate, and that window closes quietly.

For Australian contracts specifically, make sure there's AUD pricing or a fixed exchange mechanism, clear GST treatment, and a data residency clause if the workload is regulated. A contract that says nothing about where data lives becomes a compliance problem later.

What goes wrong most often

The most common mistake is treating the cloud invoice as the infrastructure budget. A founder sees $1,500 a month and decides infrastructure is cheap. Then they work out their lead engineer spends a third of their week on it.

The second is over-engineering at MVP stage. Kubernetes, multi-region, a full monitoring stack, all before a single paying customer. It costs money and it slows delivery down. Early builds do better on managed services, adding complexity only when something forces the decision. Our piece on software scalability covers when that moment actually arrives.

The third is ignoring the Australian specifics. Egress within Australia is cheaper than sending data overseas, but it isn't free. Data sovereignty rules for health and government work add real cost that no generic pricing calculator models. And GST on cloud invoices is claimable, but only if someone in finance knows to look.

Teams that handle this well share one habit. They treat infrastructure cost as a product metric, not a finance job. Cost per customer, cost per environment and engineering hours on infrastructure get reviewed in the same meeting as feature velocity and uptime. AI Orchestrators makes a similar argument about measuring AI return properly instead of guessing at it.

Get a real number before you build

Most founders come to us after the cloud bill has outgrown revenue, or after realising their engineers spend half their week on infrastructure instead of product.

Devwiz has shipped 200+ apps, including work for the NSW Government, Briometrix, Vivid and Huskee. We run a discovery phase before any code gets written, which is where scope, architecture and the constraints that drive run cost get settled. Our white-label AI platform case study shows what that looks like on a multi-tenant build.

If you're planning a build or auditing a platform you already run, talk to us about AI app development or a custom software build. Founders can start on our tech for founders page. If you're the one who owns the architecture call, tech for CTOs is the better starting point.

Get a realistic number before you commit to an architecture. Changing your mind later is where the money goes.

Frequently asked questions

What is software infrastructure cost?

It covers everything needed to run an application: compute, storage, network egress, CDN, managed database services, backups, monitoring, CI/CD, third-party licences and security tooling. It also covers the engineering hours spent provisioning, patching and debugging all of it. That labour rarely appears on a cloud bill but is usually the largest single line in the real total.

How much should a startup spend on infrastructure?

There is no single right number, and any fixed percentage you see quoted is a rough guide at best. The more useful approach is to track infrastructure spend as a share of revenue and watch the trend over time. Spend rising slower than revenue is healthy. Spend rising while revenue is flat needs explaining. Pair it with a cost-per-customer figure before you take either number to a board.

Does GST apply to cloud services in Australia?

Yes, at ten percent. The major providers are GST registered in Australia and include it on Australian invoices, which makes it claimable as an input tax credit if your business is registered. Check the invoice carries an ABN before you claim, and confirm the treatment with your accountant.

Why does my cloud bill change when my usage doesn't?

The big cloud providers price Australian region services in USD, and you pay in AUD at the prevailing exchange rate. So the bill moves with the currency even when consumption is flat. A ten percent fall in the AUD raises your cloud spend by roughly the same amount for identical usage. Model your spend in USD and apply a conservative exchange rate assumption.

When does a private datacentre beat public cloud?

Rarely, for most founders. Private co-location starts to make sense when you have sustained and predictable compute load, a cloud bill running into the tens of thousands a month, strict latency requirements, or a regulator that will not accept shared infrastructure. Below that, the capital outlay, slow procurement and hardware management overhead usually cost more than they save.