Choosing a cloud platform for an Indian business

The question we are usually asked is which of the large providers is cheapest for an Indian business. It is the wrong first question, and answering it produces decisions that get reversed eighteen months later at considerable cost.

Published rates are broadly comparable across the major platforms and change often enough that any advantage you pick today is temporary. What does not change quickly is where your data is allowed to live, how far your users are from the nearest region, whether you can reach a competent engineer at four in the afternoon India time rather than four in the morning, and what it costs to leave.

Those factors decide whether the platform still fits in three years. This is the sequence we work through when advising on cloud platform selection, in the order that actually narrows the field.

Start here because it is a gate rather than a trade-off. If a category of your data must remain within India, that requirement removes options and shapes the architecture, and discovering it during a security review after the build is an expensive way to learn it.

The obligation can come from several directions at once: sectoral regulation for financial or health data, public-sector procurement conditions, Indian data protection law as it applies to personal data, or simply a clause in a large customer's contract that says their data stays in-country. Most organisations discover the contractual one last, and it is often the strictest.

Questions to settle in writing

1. Which specific datasets carry a residency obligation, and what is the source of it — statute, regulator guidance, or a contract you signed?
2. Does the obligation cover only primary storage, or also backups, disaster recovery copies, logs and analytics extracts? Backups and logs are the usual leak.
3. Can the provider pin processing to an Indian region, and is that a configuration you control or a commitment you must negotiate?
4. Which managed services in your intended architecture are actually available in the Indian regions? Regional service parity is uneven, and a design that assumes a service available only elsewhere quietly forces data out of the country.
5. Where does the support and operations team access data from, and is that access logged?

Where the answers are unsatisfactory or the obligation is absolute, private infrastructure becomes a serious option rather than a fallback — our own VPS and dedicated servers exist partly for exactly these cases. Organisations in finance, healthcare and government should treat this section as the whole first phase of the decision.

Distance is the one constraint no amount of engineering removes. If your users are in Chennai and your application server is in Singapore or Frankfurt, every round trip pays for the distance, and chatty applications pay for it many times per page.

The mistake is treating this as a single number. Latency to the user matters for interactive work; latency between your own components matters far more for anything that makes multiple database calls per request. An application server in an Indian region talking to a database in another continent will feel slower than one where both sit together, even though the user is close to the app.

A practical test before you commit

• Spin up the smallest possible instance in each candidate region and measure from the cities your users are actually in — not from your office alone.
• Test on mobile networks as well as fixed lines. A large share of Indian usage is mobile, and the variance matters more than the median.
• Measure a realistic transaction, not a ping. Twelve sequential queries at forty milliseconds each is half a second before any work is done.
• Check whether your traffic can be served from a content delivery network at the edge. A good caching layer removes much of the distance problem for read-heavy sites, and none of it for transactional applications.

If your user base is concentrated in India, the default should be an Indian region with everything co-located, and a deliberate justification required for any component that sits elsewhere.

This is the factor most consistently underweighted at selection and most consistently complained about afterwards. The relevant question is not whether support exists; every platform has it. It is what happens at three in the afternoon on a Tuesday in Mumbai when production is degraded and the first-line response is a template.

• Time zone of the engineers, not the portal. Ticketing is always available. Escalation to someone who can change something may not be, in your hours.
• The cost of usable support. Meaningful response commitments generally sit in a paid support tier. Compare platforms with that tier included, because you will buy it eventually.
• Language and context. Whether the person responding understands your regulatory environment and billing setup affects resolution time more than raw technical skill.
• Who owns the problem at 2am. On a global platform, the answer is a queue. With a local partner or a managed service, it is a named team. Decide which you need before the incident, not during it.

Test this during evaluation rather than taking it on faith. Raise a real, non-trivial ticket in your own working hours during the trial period and observe what comes back and how quickly. It is the most informative hour of the whole procurement.

Storing data is cheap and advertised. Moving it out is priced separately and rarely modelled. Egress charges are the line item that turns an apparently economical platform into an expensive one, and they compound with architecture in ways the price sheet does not show.

Three places egress bites, in rough order of how often it surprises people:

• Serving content to users. Media-heavy applications, file downloads and video pay on every request. This is the ordinary running cost and should be in your model from day one.
• Cross-region and cross-zone traffic. A resilient design that spreads components across zones can generate substantial internal transfer. Multi-cloud architectures pay this continuously, which is why “we will run across two providers for resilience” is usually more expensive than it sounds.
• Backups and disaster recovery copies. Replicating to another provider or to your own datacentre is egress every time.

Then there is the exit itself. Before signing, ask a specific question: if we decided in two years to move our data elsewhere, what would that cost and how long would it take? Providers vary considerably in how they treat exit transfers, and some now waive charges for full migration away. Get the current answer in writing and record it — an exit cost you have quantified is a manageable risk, and one you have never asked about is the reason organisations stay on platforms that stopped fitting years ago.

Compute and storage rates are the visible part of the bill and frequently not the largest part. When we rebuild a cost comparison properly, five categories tend to move the ranking — sometimes reversing it.

1. Data transfer. Egress to users, between zones and regions, and out to backups. Estimate from measured traffic, not from intuition.
2. Support tier. The plan you will actually need, priced in from the start.
3. Managed service premiums. A managed database costs more per hour than a self-run one and saves operational time. Both sides of that trade belong in the model, valued at what your engineers cost.
4. Licensing carried into the cloud. Operating system, database and application licences may be priced differently by platform. Bring-your-own-licence terms are worth checking specifically.
5. People and tooling. Monitoring, logging, security tooling and the skills to run the platform. A platform your team already knows has a genuine and quantifiable advantage.

Build the model on three years, not one month

Take your current or projected workload, model it monthly for thirty-six months with a realistic growth curve, and include a one-off migration cost and a periodic re-architecture allowance. Then run the same model with a twenty per cent workload increase and with a fifty per cent one. A platform choice that only works at today's volume is not a choice, it is a deferral. Our cloud cost optimization checklist covers the ongoing discipline once you are running.

The comparison is often posed as a choice between the global platforms. In practice many Indian businesses land on a mix, and the mix is a reasonable answer rather than an indecisive one — provided the split is deliberate.

A global hyperscaler suits

• Workloads with spiky or unpredictable demand where elasticity is the whole point.
• Teams that will genuinely use the managed services rather than running VMs on them.
• Businesses serving users across several countries.
• Anything where the breadth of the service catalogue is doing real work for you.

Private or local infrastructure suits

• Steady, predictable workloads where reserved capacity beats elastic pricing.
• Strict residency requirements, or a need to name the physical location.
• Applications that were never designed for cloud-native operation and would need rewriting to benefit.
• Organisations that value a named support relationship over a service catalogue they will not use.

The hybrid pattern that works is boundary-based: put the systems of record where residency and predictability point, put the elastic and experimental workloads where the catalogue and the scaling are, and define one clear interface between them. The hybrid pattern that fails is the accidental one, where workloads land wherever whoever built them was comfortable and nobody owns the whole picture.

Score each candidate from 1 to 5 on eight factors, weight them for your own situation, and write down the reasoning. The written reasoning is the valuable artefact — it is what makes the decision reviewable when circumstances change.

• Residency fit. Treat any score below 4 as disqualifying if you have a hard obligation.
• Measured latency from your users' actual locations.
• Support in your hours, tested rather than assumed.
• Three-year modelled cost, including transfer, support and people.
• Service fit — does it offer what your architecture needs in the Indian region specifically?
• Exit cost, quantified in money and weeks.
• Team familiarity and the availability of people who know it.
• Compliance evidence — what audit reports and certifications can be produced for your auditors on request.

Suggested starting weights

1. Regulated data: residency and compliance evidence at double weight, everything else normal.
2. Consumer-facing product with Indian users: latency and three-year cost at double weight.
3. Small team without a platform specialist: support and team familiarity at double weight — the cheapest platform you cannot operate is not cheap.
4. Long-lived core systems: exit cost and three-year cost at double weight.

Set a review date twelve months out and record the assumptions that would change the answer. Platform decisions made once and never revisited become the constraint everyone works around. If the migration itself is the next question, our migration readiness guide picks up where this leaves off.