Shared hosting or AWS, and how to actually choose

A shop owner in Thane asked me last month whether he should move his website to AWS. His site is eleven pages of text and photographs about industrial valves. It gets about four hundred visitors a month. Someone had quoted him ₹4,000 a month to “migrate to cloud infrastructure”.

The honest answer was that AWS would make his website slightly worse and considerably more expensive. But the answer is not always that, and the difference matters, so here is how to work it out for yourself.

Start with the only question that matters

Does anything have to be worked out while your visitor waits?

If your site shows the same pages to everyone and you change them when you feel like it, nothing is worked out on demand. Your pages can be served as finished files. This is the cheapest and fastest possible arrangement and it is what most business websites should be.

If your site takes payments, checks stock, logs people in, or stores what they type, then something must happen live, and you need a machine that stays awake to do it.

Everything below follows from which of those two you are.

If nothing is worked out live

You do not need shared hosting or a server. You need a place to put files and a network to serve them from.

Served this way, a small business site costs somewhere between nothing and a couple of hundred rupees a month in storage and transfer, because you are paying for bytes moved rather than for a machine that idles twenty-four hours a day. The pricing is public and worth reading rather than taking my word for: storage is billed per gigabyte per month and transfer per gigabyte out. At small business volumes both numbers round to almost nothing.

It is also the safest arrangement you can have. There is no server process listening, no admin panel to brute force, no plugin to leave unpatched. The usual ways a small business website gets defaced simply do not apply.

If something is worked out live

Now you are choosing between shared hosting and a server, and the difference is who is responsible when it breaks.

Shared hosting puts your site on one machine with a few hundred others. It is cheap because the cost of that machine is divided. In India it is typically advertised somewhere between ₹150 and ₹500 a month on a two or three year prepay, and it renews higher, which is the part people forget. You get a control panel, you do not touch the operating system, and if a neighbour on your machine gets busy your site slows down. For a brochure site with a contact form this is genuinely fine and I will not pretend otherwise.

A small server, which is what AWS Lightsail or a comparable VPS gives you, starts at a few dollars a month for the smallest instance. You get the whole machine and, with it, the whole responsibility: the operating system, the security updates, the backups, the certificate renewal, and the 2am phone call. That is not a criticism. It is a real cost that does not appear on the invoice, and it is the number people leave out when they compare the two.

Full AWS, the thing being sold when someone says “migrate to cloud”, is this plus managed databases, load balancers and the rest. It is the right answer when you have real traffic, real uptime requirements, or real compliance obligations. At four hundred visitors a month it is a more expensive way to run the same eleven pages.

The four numbers to check before you pay

Whichever you choose, get these four out of the vendor in writing. If they cannot answer, that is the answer.

1. Where is the server, physically? For an Indian audience you want Mumbai. Every 1,000 km of distance is real milliseconds on every request. Ask for the region name, not the country.
2. What is the renewal price, not the first-term price? Almost all Indian shared hosting advertises a discounted multi-year rate and renews at two to three times that. Budget the renewal.
3. Who applies security updates, and how often? On shared hosting it is the host, for the parts they control, and you for your CMS and plugins. On a VPS it is you, unless you are paying someone. Get the boundary in writing.
4. What exactly is backed up, how often, and how do you restore it? “Daily backups” is worth nothing if nobody has ever tested a restore. Ask them to show you one.

Then check the thing nobody mentions

Hosting is not usually why a site is slow. Google measures three things about the experience of your pages, and the one hosting affects most is how long the biggest thing on screen takes to appear. The target is under two and a half seconds.

A slow server does hurt that. But oversized images and too much JavaScript hurt it more, and they hurt it for everyone, everywhere, on every visit. I have written up why your website is slow, in the order worth checking, because moving a heavy site to better hosting is how people spend money without getting faster.

So, which one

• Brochure site, no login, no payments: serve it as files. Fastest, cheapest, safest.
• Small shop or a site with a CMS you want to click around in: good shared hosting in an Indian data centre is fine. Budget the renewal.
• Real traffic, real uptime needs, or software rather than a website: a server or proper cloud, and someone whose job it is to look after it.
• Someone quoting you cloud for a brochure site: ask them which of elasticity, managed services, or location you are buying. If the answer is none of them, you are buying a line item.

If you would rather not work it out yourself, that is what we do. We host most of what we build as files in the Mumbai region, we tell you when a project genuinely needs a machine instead, and the account is in your name at the end. Details on our cloud, hosting and DevOps page.