Many Google Cloud projects in India start in a US region because a tutorial, a quick-start form or a developer's habit said us-central1. That works until users complain about slow pages, a client asks where their data is stored, or you try to set up disaster recovery and discover that moving buckets and datasets means copying them.
This guide explains how to choose between Google Cloud's Indian regions in Mumbai and Delhi, which decisions are hard to reverse, and how to use the second region for backups and recovery.
Quick answer: Google Cloud runs regions in Mumbai (asia-south1) and Delhi (asia-south2). Pick one as primary based on where your users are, which services and machine types you need, and the price of your exact resources. Use the other region for backups or a standby environment, and set an organisation policy so resources cannot be created outside India by accident.
Five questions that decide your primary region
- Where are your users? If most users and offices are in north India, Delhi may be closer; for western and southern India, Mumbai may be. Do not assume. Run a small test VM in each region and measure response times from the cities that matter to you.
- Is every service you need available there? Not every product, machine type, GPU or AI model is offered in every region. List what you plan to use, such as Cloud Run, Cloud SQL, GKE, BigQuery and Vertex AI, and check each one in Google Cloud's locations documentation.
- What will it cost? Prices for the same resource can differ between regions. Compare your actual machine types, storage and database tiers in the Google Cloud pricing calculator rather than relying on a general rule.
- Where do your other systems live? If your data warehouse, partners or existing AWS workloads sit in a particular location, traffic between regions and clouds is charged and adds latency. Keep tightly coupled parts together.
- What do contracts and regulators expect? Many enterprise and government clients ask for data to stay in India. Some sector rules go further: the Reserve Bank of India, for example, requires payment system operators to store payment data in India. Check what applies to your business.
Decisions that are hard to change later
A Google Cloud project is not tied to a region, but almost everything inside it is. Changing your mind later means recreating or copying each resource, so make these choices deliberately.
| Resource | Location fixed? | What moving involves |
|---|---|---|
| Cloud Storage bucket | Yes, set at creation | Create a new bucket in the new location and copy the objects across |
| BigQuery dataset | Yes, set at creation | Copy or reload the data into a new dataset, then update queries and scheduled jobs |
| Cloud SQL instance | Region is fixed | Create a replica or new instance in the new region, then cut over |
| GKE cluster | Yes | Build a new cluster and redeploy the workloads |
| Compute Engine VM and disks | Zone is fixed | Recreate from a snapshot or machine image in the new zone |
| Cloud Run service | Deployed per region | Redeploy the same image in the new region and update the domain or load balancer |
Write the region decision into your architecture notes, with the reason, so new team members and vendors do not quietly create resources somewhere else.
Using both Indian regions for disaster recovery
Mumbai and Delhi are in different parts of the country, which makes the pair a natural fit for recovery planning while keeping data in India. Choose the pattern by how long you can afford to be down:
- Backups only: database exports and bucket copies land in the second region. This is the cheapest option, but recovery means rebuilding the environment first.
- Rebuild from code: keep the whole environment in Terraform so you can recreate networks, services and permissions in the second region quickly, then restore the data.
- Warm standby: a Cloud SQL cross-region read replica and a minimal copy of the application run in the second region, ready to be promoted and scaled up.
Within your primary region, spread production across at least two zones first. That protects you against the failure of one zone without the cost of a second region. Then test failover to the other region at least once a year, because a recovery plan that has never run is only a document. Our backup and disaster recovery service starts by agreeing how much data and downtime each system can tolerate.
Lock the decision in during foundation setup
The cheapest time to enforce a region is before the first workload goes live. These are part of any sound Google Cloud foundation setup:
- Organisation policy: the resource locations constraint (
gcp.resourceLocations) restricts where new resources can be created. Allow only the Indian regions, and note that some services, such as IAM, are global by design. - Defaults for your team: set the default region in the gcloud CLI (
gcloud config set compute/region asia-south1) and in your Terraform provider configuration, so commands do not fall back to another region. - Budgets and labels: create a budget with alerts for each project and label resources by environment and owner. Resources created in the wrong place are then easy to spot in billing exports.
- Analytics location: when creating BigQuery datasets, choose the Indian region explicitly instead of accepting a multi-region default.
Common mistakes when choosing a region
- Putting the application in one region and its database in another, which adds latency to every query and transfer charges every month.
- Choosing a region for a single service, such as one AI model, without checking whether the rest of the stack is available there.
- Calling a second region “disaster recovery” without ever testing a failover.
- Copying all data to the second region every hour when the recovery plan only needs nightly copies.
- Assuming the data protection law forbids every transfer abroad, or that it allows everything. The Digital Personal Data Protection Act, 2023 permits transfers outside India except to countries the government restricts by notification; check the current position on the MeitY website. This is general information, not legal advice; confirm the details for your case.
How EthicsComputer can help
Our Google Cloud consulting team sets up organisations, folders, projects, IAM, shared VPC networking, location policies and budget alerts as code, typically starting with an assessment of one to two weeks. If your workloads already run in a US region or on another cloud, our cloud migration service plans the move in waves with a rollback path at each stage. Your cloud bill stays in your own account, and we never mark up provider charges.
Starting a new Google Cloud project, or stuck in the wrong region?
Tell us what you run and where your users are, and we will suggest a region and recovery plan.
About the author
Vinay Grover founded EthicsComputer in Rohtak, Haryana in 2018 and leads its cybersecurity, software and AI work for clients across India and abroad. EthicsComputer is ISO 9001, ISO/IEC 27001 and ISO 20000-1 certified.
