You probably don't need AWS

Last year we went through the AWS bill for a business whose website was, functionally, a brochure. Ten pages, a contact form, a few hundred visitors a day. The site had been built by an outsourced developer who was long gone, and the account was costing about US$170 a month: WordPress on an EC2 instance, a managed RDS database, a NAT gateway nobody could explain, and a second instance that turned out to be the developer’s staging copy, still running two years after handover.

Nobody chose that setup. The developer followed a deployment guide, clicked through the VPC wizard, took the defaults and moved on to the next client. After handover, nobody at the business knew which pieces were safe to turn off, so they paid the whole bill, every month, for years. A hundred and seventy US dollars won’t ruin anyone. It was just buying nothing, because a free static host could have served those same ten pages faster.

We see versions of this all the time, often at the end of a cheap outsourced build where the developer knew how to switch AWS on but not why. So it’s worth walking through what you’re really paying for, when it’s justified, and when the honest answer is a hosting bill close to zero.

Why AWS ends up on the invoice

AWS wins by default, and the defaults have little to do with your website.

Developers know it, so quoting it is safe. It’s on their CV, and “we deployed to AWS” sounds more serious in a proposal than “we put it on a $10 server”. Agencies standardise on it because one platform is easier to support than five. And the word “scalable” does a lot of quiet work in sales conversations, because nobody wants to be the person who said no to growth.

None of those are bad reasons for the vendor. They’re just not your reasons. Your reason for choosing infrastructure should be the shape of the workload, and most small business workloads have a very unglamorous shape: modest traffic, predictable hours, small data, and a strong preference for the bill staying flat.

AWS is priced for the opposite shape. It’s metered, elastic and billed in US dollars, which means it rewards workloads that spike and punishes the ones that just sit there. A NAT gateway alone runs about US$45 a month in the Sydney region before it processes a byte. An application load balancer is US$25 or so before traffic. Add a small EC2 instance, a managed database and bandwidth out, and a site doing nothing much clears a couple of hundred Australian dollars a month at current exchange rates.

Then there’s the cost that never shows on the bill: someone has to understand it. VPCs, security groups, IAM roles, instance patching, snapshot policies. Either you pay a person to hold that knowledge, or you don’t and you find out during an outage that nobody knows how the thing is wired. A big cloud account you don’t understand is a liability, not an asset. We’ve written before about what happens when your supplier is the only one holding the keys, and an over-complicated AWS account is one of the more effective locks.

When AWS is worth every cent

This isn’t an anti-AWS article. We use it, and for the right workload it’s clearly the correct call.

It makes sense when traffic really does spike: ten or a hundred times over baseline, seasonal crushes, campaign launches. It makes sense when you need a managed service that would be expensive to replicate, like S3 for large object storage, SES for transactional email at volume, or the queueing and machine learning services. Compliance can force the decision too, when a client contract dictates specific regions, certifications and audit trails. And if you already employ people who know AWS well, the cost curve looks completely different with someone competent driving.

The test isn’t whether AWS can host your workload. It can host anything. The test is whether the things you’re paying a premium for are things your workload does. Paying for elasticity on a site with flat traffic is like leasing a road train to do the school run.

Some websites shouldn’t have a hosting bill at all

Here’s the part that surprises people: a decent share of business websites don’t need a server.

If your site is content, and most brochure sites, marketing sites, portfolios and documentation sites are exactly that, it can be built as a static site. HTML, CSS, JavaScript, generated once at build time, served as plain files. No database to secure, no server to patch, nothing to fall over at 2am.

Static files are so cheap to serve that several providers do it for free, and not trial-free. Cloudflare Pages serves static sites with unmetered bandwidth and requests on its free plan, from data centres that include Australian cities, so it’s quick for local visitors too. GitHub Pages is free for public and modest private use. Netlify’s free tier includes 100GB of bandwidth a month, which is far more than most small business sites will ever touch.

This website is a static Hugo build. It happens to live on a small VPS we already run, but it could move to Cloudflare Pages this afternoon without a code change, and the hosting line on the bill would be zero. A contact form doesn’t change that, because form endpoints, payment links and booking widgets can all run on third-party services or tiny serverless functions while the site itself stays static.

Static also tends to be fast, and speed is money in a way most owners underestimate: slow pages lose enquiries long before anyone complains about them.

If a vendor quotes you ongoing cloud hosting for a ten-page marketing site, ask them why the site needs a server at all. There are legitimate answers. “That’s how we always do it” isn’t one of them.

The $10 server in the middle

Between “free static hosting” and “full cloud account” sits the option that gets skipped most often: a small virtual private server.

A VPS from DigitalOcean, Vultr, Hetzner or an Australian provider like Binary Lane costs between $5 and $20 a month, and a single one of those machines will comfortably run a business application, a database, a booking system and a website for a company with dozens of staff. Modern small servers are absurdly capable. The workloads most businesses run stopped being hard for the hardware years ago.

The trade is honest and easy to state. A VPS is a fixed, predictable cost with no metering surprises, and you own the whole stack. In exchange, someone has to maintain it: security updates, backups, monitoring. That’s a real job, but it’s a small and well-understood one for this class of machine, and it can be part of a support arrangement without the supplier taking custody of your accounts.

The managed platforms sit nearby: Fly.io, Railway, Render, Vercel and friends will run dynamic apps with generous entry tiers and less operational work. They’re a fine choice, with one caution. Most of them are metered above the free allowance, and metered pricing plus an unexpected traffic spike is the mechanism behind every surprise-bill story, whether the meter belongs to Firebase, Vercel or AWS itself. A $10 VPS falls over when it’s overwhelmed. A metered platform stays up and sends you the bill. Decide which failure you’d rather have before launch day, not after.

One more caution on free tiers generally: they’re pricing strategy, not charity. The generous limits exist to get you onto the platform, and they can change, as anyone who hosted on Heroku’s free dynos found out when they were withdrawn in 2022. Free is a great price, but keep your site portable enough that a policy change is an afternoon’s migration rather than a crisis.

Working out what you actually need

Before anyone quotes you hosting, you should be able to answer five questions. If your vendor can’t answer them about your own project, that tells you something too.

1. Is the site content or an application? If nothing changes per visitor, it’s content, and static hosting at $0 should be the starting assumption.
2. What’s the traffic shape? Steady and modest suits a fixed-price VPS. Spiky suits elastic infrastructure. “It might grow one day” is not spiky; you can migrate when it does.
3. Where does the data live, and does it matter? Customer records, health information or government work may constrain you to Australian regions, which affects provider choice more than price does. Related reading: data sovereignty and Australian AI.
4. Who maintains it, and what happens when they leave? Whatever you pick, the accounts should be yours, the setup documented, and another developer able to take over.
5. What does the bill look like on the worst day? Fixed-cost hosting has a known worst case. Metered hosting doesn’t, unless you’ve set budgets and alerts, so if you go metered, set them before launch.

Run those honestly and the answer for a lot of businesses is a static site for the marketing front door, a small VPS or managed platform for the internal app, and no AWS account anywhere. The answer for some businesses really is AWS, chosen for a stated reason with a named person who understands the account. Both are fine. The expensive outcome is the one in that opening story: enterprise infrastructure by default, doing brochure work, billed in US dollars, understood by nobody.

Rangefront Labs builds websites and custom software with the hosting decision made on purpose, in writing, with the accounts in your name. If you’d like a second opinion on a hosting quote or a bill that feels too big for what the site does, send it over and we’ll tell you what we’d do instead.