What cloud hosting actually costs an Indian business
How to budget cloud hosting in India properly: the line items beyond the instance price, which of them are actually charged, and where teams underestimate cost.
The instance price is the part of a hosting bill that people compare. It is rarely the part that surprises them. Budgets go wrong on the lines nobody costed: the database, the traffic, the second environment, and the tax treatment.
This page lays out what a realistic hosting budget contains so you can plan against it rather than discover it. The tax treatment described is general information, not tax advice.
What you are actually paying for
Compute. The instance running your application, priced by the memory and processor it gets. Predictable, and the easiest line to reason about. It is charged whether or not anyone visits.
The database. Usually the second-largest line and frequently forgotten at planning time. A managed database is priced separately from the application that talks to it, and it also needs storage, which grows.
Storage. Database storage is included in the database plan rather than charged separately, so the thing to watch is the plan CEILING, not a per-GB line. Storage grows with your data and does not shrink when you delete rows unless you reclaim it, and hitting the ceiling is disruptive. See managed database storage limits.
Tax. 18% GST, added at payment. For a registered business this is recoverable as input tax credit and should be budgeted at the net figure; for an unregistered one it is a real 18% on top. See Input tax credit on cloud hosting.
For current rates, see pricing. Prices are listed excluding GST.
Metered but not billed
Two things are measured and shown on your usage page, and neither is charged today: outbound bandwidth, and build minutes. Budget them at zero, and watch the usage page rather than the bill. They are visible so that you are not surprised if that ever changes, and so you can see what your deploys and traffic actually cost to run. See usage and billing.
Where budgets actually go wrong
Counting one environment. Most teams end up running production plus at least a staging environment, and often a background worker or a scheduled job alongside them. The count of running services is usually higher than the plan assumed.
Forgetting the database sits on its own line. An application instance without its database is about half a budget.
Assuming idle is free. An always-on service is charged for being available, not for being busy. A staging environment nobody visits costs the same as one under load.
Ignoring growth in storage. Compute is flat; storage is a ratchet. It is the line that quietly doubles.
Comparing a dollar price at today’s exchange rate. The rupee cost of a dollar-priced service includes your card issuer’s foreign transaction markup and moves with the exchange rate, and the tax treatment is different. See Cloud hosting priced in rupees versus dollars.
How to build the estimate
- List every service you will actually run. Production, staging, background workers, scheduled jobs. Count them, do not estimate them.
- Add a database line per environment that needs its own data, sized so its storage ceiling has room to grow into.
- Size compute from memory, not optimism. An application that needs 512 MB does not run on 256 MB more cheaply; it restarts.
- Add 18% GST, then subtract it again if you are registered and claiming credit.
The output of that exercise is usually well above the instance price alone — the database and the second environment are what move it — and it is the number worth planning against.
Reducing it honestly
- Turn off environments you are not using. The largest saving available to most teams, and it costs nothing.
- Right-size after measuring, not before. Check actual memory and processor use rather than guessing in either direction. See service resource usage.
- Reclaim database storage rather than moving up to a plan you do not otherwise need.
- Use the free tier for what it is for — experiments and things that do not need to be always-on. See free instances.
What does not work is under-sizing production to save a few hundred rupees. The saving is small and the failure mode is your application restarting under load.