Sovereign Cloud Data Centres in India: What SMBs Gain and Lose

A founder in Pune told me last year that her accounts team was emailing customer invoices to a Singapore-hosted SaaS tool, and her biggest client's compliance officer had just asked, politely but firmly, where that data physically lived. She didn't know. Nobody on her eight-person team knew. Within three weeks she had a half-finished migration plan, a nervous CFO, and a question she should have asked two years earlier: what does data localisation actually require of a business my size, and does it matter where I host my data?

That question has become harder to answer over the past few years, and more urgent. Hyperscalers AWS, Microsoft Azure and Google Cloud have all opened or expanded India regions, and a domestic cloud push backed by government procurement preferences has added new options at the lower end of the market. On paper, this makes things simpler: your data can stay in India. In practice, it creates new trade-offs around latency, pricing, service availability and compliance that most small businesses are not equipped to evaluate.

This guide is written for founders, operations heads and IT leads at Indian SMBs and startups who are deciding where to host customer data, internal records and application workloads. I'll cover what "data localisation" really means for you, where the legal obligations are genuinely strict and where they are vaguer than vendors claim, how the main providers compare on cost and capability, and a practical walkthrough for making the decision. If you read only one section, read the one on the common mistake, because it has cost more than one Indian company real money.

Data localisation India cloud SMB: what the rules actually ask of you

Before comparing hosting options, get the legal baseline right. A lot of the confusion in the market comes from people treating "data localisation" as a single rule. It isn't. It is a patchwork, and which pieces apply to you depends on what data you hold and which sector you operate in.

The most relevant frameworks for most SMBs are these:

• Digital Personal Data Protection Act, 2023 (DPDP Act) and its rules: The DPDP framework sets out obligations for processing personal data of Indian data principals, including consent, purpose limitation, security safeguards and breach notification. It gives the government power to restrict transfers to specific countries, but it does not, as a general rule, mandate that all personal data must sit inside India. Compliance timelines under the rules are phased, so check the current schedule with your advisor rather than relying on older commentary.
• RBI payment data storage directive (2018): If you are a payment system operator or handle payment data within the RBI's regulated ecosystem, end-to-end transaction data must be stored only in India. This is the strictest and most clearly worded localisation requirement, and it binds payment aggregators and similar entities far more than a typical e-commerce or SaaS startup.
• Sectoral rules: Insurance (IRDAI), telecom (DoT licence conditions), and health data under various state and central frameworks each carry their own storage or access expectations. A healthtech startup and a logistics company face very different obligations.
• Contract and client requirements: This is the one that actually bites most SMBs. Banks, government departments, large enterprises and some public-sector tenders increasingly write "data must reside in India" into vendor agreements, regardless of what the statute says.
• Tax and accounting records: GST invoices, e-invoice data and income-tax records must be retrievable on request by authorities. Nothing in these rules forbids cloud hosting, but you must be able to produce records in a usable format, so vendor lock-in and export capability matter.

The practical takeaway: for most Indian SMBs, there is no blanket statutory order to keep every byte in India. But your largest clients, your sector regulator, or your tender eligibility may effectively impose one. Find out which applies to you before you spend a rupee on migration.

Key Takeaways

• Data localisation is a patchwork, not one law. Map which rules bind your sector and your data types first.
• The RBI payment data directive is the clearest mandatory localisation rule; most SMBs fall under contractual requirements instead.
• Major hyperscalers now run India regions, so "stay in India" is achievable on AWS, Azure and GCP without leaving the mainstream stack.
• Localisation raises cost, but the premium is often smaller than vendors' quotes suggest once you right-size instances and use committed-use discounts.
• Insist on data export and portability in your contract, regardless of where data lives.
• Decide by data class and client obligation, not by a general sense that "Indian hosting is safer."

Why the India region announcements don't settle the question

The arrival of AWS's Mumbai and Hyderabad regions, Azure's Central India and South India regions, and Google Cloud's Mumbai and Delhi regions meant that the physical infrastructure question has largely been answered. You can run an application, its database and its backups entirely within Indian borders on any of the three. Latency from Mumbai, Delhi and Bengaluru to these regions is generally in the low tens of milliseconds, which is fine for most business applications.

But three things remain unsettled, and they are where SMBs get hurt.

First, not every service is available in every region. A managed AI service, a specific database flavour, or a newer analytics tool may launch in the US or Singapore first and reach India months later, or with a narrower feature set. If your architecture depends on one of these, your "India-hosted" stack may quietly include a dependency that runs elsewhere, or you may be forced to rebuild around a substitute.

Second, backups, logs, monitoring and support tooling often replicate data outside the region by default or for operational reasons. A database may be perfectly localised while its telemetry, error logs containing personal data, or a global CDN cache carries copies elsewhere. Auditors will ask about these.

Third, the domestic cloud push is real but uneven. Indian providers and government-backed platforms offer strong local-residency guarantees and, for some workloads, competitive pricing. They generally have smaller service catalogues, thinner partner ecosystems and fewer engineers familiar with them in the open market. Whether that trade is worth it depends entirely on your workload, which is why blanket advice from either camp tends to be wrong.

For a broader view of how these regional shifts affect running costs, the piece on AWS and Azure's India data centre shift and what Indian SMBs should check goes through the pricing angle in more depth.

Worked example: a 15-person logistics firm in Gurgaon

Consider a realistic case. A logistics company in Gurgaon with about 15 staff ran its dispatch software, a PostgreSQL database, a document store for proof-of-delivery images, and an internal reporting tool on three physical servers in a rented rack at a colocation facility. Their monthly outlay was around ₹45,000, covering the rack, bandwidth, hardware amortisation, a part-time engineer's time on patching, and two emergency callouts in a single year when a disk failed and backups turned out to be incomplete.

Their largest client, a pharmaceutical distributor, then added a clause requiring all data relating to shipments to be hosted in India with documented backup and recovery testing. The company's existing setup technically satisfied residency, but the client wanted auditable controls, which the ad hoc colocation arrangement could not provide cleanly.

The migration went roughly like this, and the cost outcome is representative of what a well-scoped move often achieves:

1. Inventory and classification (two weeks): They listed every system, the data class it held, the client obligations attached, and the retention period. Proof-of-delivery images and shipment records were flagged as client-restricted; the reporting tool was internal and lower risk.
2. Target architecture (one week): They chose AWS Mumbai for the core workloads, using a managed PostgreSQL service, object storage for images with lifecycle rules, and a small compute footprint sized from actual usage rather than the old hardware's peak capacity. Backups were configured to a second Indian region for resilience, keeping everything in-country.
3. Right-sizing (during build): The old servers had been bought for growth that never came. Measured CPU and memory showed the real load fit in instances costing a fraction of the hardware's amortised cost, and they committed to a one-year savings plan once usage stabilised.
4. Data migration and cutover (three weekends): Database replication ran for a fortnight before cutover. The image store was copied in bulk and then synced. The final cutover happened on a Sunday night with a rollback plan documented.
5. Controls and evidence (ongoing): Encryption at rest and in transit, role-based access, logging to a retained audit trail, and a quarterly restore test that they documented. This is the part the pharma client actually cared about.

Results: monthly cloud spend settled at roughly ₹18,000 after the first two months of stabilisation, with the reporting tool costing less still. The colocation contract was terminated at its notice period. The bigger win was the audit file: the client's compliance team accepted the documented controls, and the company retained the contract.

Notice what made this work. It was not the choice of provider alone. It was the classification step, which kept the client-restricted data inside tight controls while letting lower-risk systems stay simpler, and the willingness to right-size rather than lift-and-shift the old hardware's assumptions.

How do AWS, Azure and GCP compare for Indian SMBs?

Here is a practical comparison on the criteria that matter most to a small Indian business. Prices and feature availability change frequently, so treat these as the dimensions to test rather than fixed figures, and verify current pricing on each provider's calculator before deciding.

Criterion	AWS (Mumbai, Hyderabad)	Microsoft Azure (Central India, South India)	Google Cloud (Mumbai, Delhi)	Domestic / sovereign-focused providers
Breadth of managed services	Widest catalogue; most mature	Very broad; strong if you use Microsoft tools	Strong in data, analytics and AI services	Narrower; core compute, storage and databases
Fit with existing Microsoft 365 or Google Workspace estate	Good, but integration is work	Excellent if you already run Microsoft 365 licences	Excellent if you run Google Workspace	Depends on the provider; usually needs integration
Localisation assurance	Region-based; request documentation for your contract	Region-based; strong compliance documentation	Region-based; documentation available	Often the strongest residency posture by design
Partner and talent pool in India	Very large	Very large, especially enterprise partners	Growing	Small; check references carefully
Pricing predictability	Complex billing; needs governance	Complex billing; licensing bundles can help	Generally simpler sustained-use pricing	Often simpler; verify egress and support costs
Best fit for	Broad workloads, startups wanting maximum options	Microsoft-centric SMBs and enterprise-facing firms	Data-heavy and analytics-led products	Regulated clients who mandate domestic providers

A few honest observations from doing these comparisons with clients. If your business already pays for Microsoft 365 licences, Azure often makes the integration story simplest, and the cost of identity, email and file sync can be partly offset by existing licence entitlements. If you are a product startup with a small engineering team, AWS's breadth usually wins because the documentation, tutorials and the pool of engineers who can help you are largest there. GCP tends to suit teams whose product is data-centric. Domestic providers earn their place when a client contract or a tender makes domestic hosting a hard requirement, rather than a preference.

If you are weighing Google's and Microsoft's workspace licensing alongside hosting, our Google Workspace licensing and Microsoft 365 licensing pages set out how the two interact, which often settles the decision more than raw compute pricing does.

A step-by-step framework for deciding where to host

When founders ask me "which cloud should I pick," I usually turn the question around and walk them through the same sequence. You can do this yourself or brief your vendor with it.

1. List every data store, not every application. Include databases, file shares, object storage, email archives, backups, logs, analytics warehouses and third-party SaaS that holds your data. Most people miss the SaaS tools, which are often where the regulated data actually lives.
2. Tag each store by data class. Use four buckets: personal data of customers, financial and tax records, client-restricted data (anything a contract says must stay in India), and internal operational data. A store can belong to more than one.
3. Pull the obligations. For each client-restricted class, read the actual clause. Note whether it says "stored in India," "processed in India," "accessible from India," or simply "secure." These are different requirements with different architectures.
4. Check the regulator. If you are in payments, insurance, telecom or healthcare, get your sector's current rule in writing from your compliance counsel. Do not rely on a vendor's summary.
5. Map dependencies to regions. Confirm each managed service you plan to use is available in your chosen Indian region. Note the ones that are not, and decide whether to substitute or accept the gap.
6. Price three scenarios. Model the monthly cost of a fully India-localised stack, a hybrid where only restricted data is localised, and your current state. Include backup storage, data transfer and support tier, not just compute.
7. Test portability. Confirm you can export your data in open formats within a reasonable window, and rehearse a restore. A backup you have never restored is a hope, not a plan.
8. Write the controls down. Encryption, access reviews, logging retention, and restore testing frequency. This document, more than the provider choice, is what clients and auditors read.

Common Mistake: Many SMBs localise their primary database and declare victory, while leaving backups, log aggregation and error-tracking tools in a foreign region by default. When a client's auditor asks for a full data map, the gap appears. Before you sign off on residency, search your entire stack, including monitoring and third-party SaaS, for anything that copies data outside India.

What do SMBs actually lose when they localise?

Honesty requires naming the costs, because the sales pitch rarely does.

Cost premium. Localised resources are not always the cheapest option in a provider's global price list. Rates differ by region and can move over time. The premium is usually manageable once you right-size and commit, but it is real, and it grows if you run bulky data egress or keep large cold archives in premium storage tiers.

Feature lag. A newer or specialised service may arrive in India later. Teams that build on bleeding-edge tools can find themselves waiting, or quietly running a restricted workload outside the region.

Operational complexity. Multi-region setups for resilience, data residency controls and per-region policies add engineering overhead. A three-person team can carry this, but it needs someone who owns it.

Vendor concentration. Deeply integrating with one provider's proprietary services makes switching expensive. This matters more when you are locked into a domestic provider with a small catalogue, because the exit path may be narrower.

And what you gain is not only compliance. You gain a defensible story for clients, faster incident response when data is close to your team, and, in some cases, latency improvements for Indian users that show up as better conversion. None of these are automatic. They come from the discipline the localisation exercise forces on you.

Pro Tip: negotiate the exit before you need it

Most SMBs spend an afternoon on the hosting contract and never read the exit section. Ask your provider, in writing, for the data export process, its timeline, the format of exported data, and any charges for egress during exit. Ask whether your backups can be retrieved independently of the live platform. Then run one small export of a non-critical dataset to see how it actually behaves. Discovering a three-week export process in a dispute is far more expensive than discovering it during a calm quarter.

Frequently asked questions

Is it mandatory for all Indian businesses to store data in India?

No. For most SMBs there is no general statutory requirement to keep all data in India. Mandatory localisation is clearest for payment data under the RBI directive and for certain sectoral rules, while many other obligations are contractual or tied to specific data classes. Check your own sector and your client agreements.

Which cloud is best for a startup needing data localisation in India?

There is no universal answer, but AWS, Azure and GCP all offer India regions that satisfy in-country residency. AWS suits teams wanting the widest service catalogue, Azure suits Microsoft-centric firms, and GCP suits data-heavy products. Domestic providers make sense when a client or tender requires them.

Does storing data in an Indian region make me DPDP compliant?

Residency is only one part of compliance. The DPDP Act's obligations around consent, purpose, security safeguards and breach handling apply regardless of location. Hosting in India helps with some transfer questions but does not replace a proper data protection programme.

How much more does localised cloud hosting cost for a small business?

The premium varies by provider, region and workload, so modelling your actual usage is essential. For many small workloads it is a modest increase that right-sizing and committed-use discounts can offset. Heavy data egress and large archives are the usual cost surprises.

Can I keep backups outside India if my primary data is inside?

Only if your contracts and any applicable regulation allow it. Many client agreements that require in-country data also cover backups, so check the wording. Keeping backups in a second Indian region is the safer default and is operationally simple on the major providers.

What should I ask my cloud vendor about data residency?

Ask which regions store your data at rest and in transit, which managed services are available in your chosen region, whether backups, logs and support tooling replicate elsewhere, and what documentation they provide for audits. Get the answers in writing and attach them to your contract.

How long does a localisation migration take for a small company?

A focused migration for a small company with a handful of systems often runs six to ten weeks end to end, including classification, build, replication and cutover. Complex estates with many SaaS dependencies take longer. The classification step is the most common source of delay.

Where to go from here

The decision of where your data lives is no longer a question of whether India-based infrastructure exists. It does. The real question is which data needs to stay in-country, what it costs to do that well, and whether your controls will satisfy the people who matter to your business. Start with the inventory and the client clauses, and let the provider choice follow from them.

If you would rather not run this analysis alone, eDarpan works with Indian SMBs on exactly this kind of decision, from the data map and residency design through to migration and managed operations. Our IT consulting team can run the classification and cost scenarios with you, and our cloud migration and managed services team can carry out the move and keep the controls running afterwards. For a wider view of how cloud choices affect a growing business, our overview of eDarpan's services lists everything from custom software to communication tooling. You can also read the related guide on whether sovereign cloud and data localisation are worth the cost for Indian SMBs, and the checklist on what Indian SMBs should check before picking AWS, GCP or Azure.

If you have a specific workload and a client clause in front of you, contact eDarpan and we will tell you honestly whether localisation is worth it for your case. Sometimes the answer is a narrow, cheap change. Sometimes it is a full migration. Either way, you should know before you commit.