Google Cloud Setup in India (2026)

Human access should come through your identity provider, with roles granted to groups rather than individuals. Workloads should use service accounts with the narrowest role that works, and ideally with short-lived credentials rather than downloaded key files.

Downloaded keys are the single most common finding in a Google Cloud review. They end up in repositories, in CI variables with no rotation, and on a laptop that leaves the company. Workload identity removes most of that need.

A VPC in Google Cloud is global, with regional subnets. That is convenient and easy to misread: a firewall rule can apply across regions, and a default network created by the console is wide open by design.

We remove the default network, define subnets per region, and allow only the ports the workloads need. Private access to Google APIs is configured so traffic does not leave the network boundary unnecessarily.

Cloud Run suits containerised HTTP services with variable traffic, because it scales to zero and bills per request. GKE suits several services, a team that wants Kubernetes, and workloads that need cluster-level control. A plain VM is still the right answer for a lift-and-shift application that assumes a server.

Managed Kubernetes is scoped separately, because a cluster needs ingress, autoscaling, logging and identity work beyond creating it.

Cloud SQL handles a conventional relational database without patching. BigQuery is for analytics over large datasets, not for transactional writes. Cloud Storage is for files and static assets, usually behind Cloud CDN.

The mistake we see most is using BigQuery as an application database because it is available. It is a warehouse; the access patterns and costs are different.

Attach billing to a company account, not a personal card. Set budgets with alerts at a low threshold, enable quotas on expensive APIs, and label every resource with an owner and an environment.

Google Cloud bills by usage and region, and those rates change, so we do not publish them. What we do publish is the structure that stops a forgotten GPU or a runaway log sink from becoming a quarterly surprise.

Moving to Google Cloud is usually a re-platform rather than a copy: machine images differ, identity differs, and managed services map loosely. We inventory dependencies, group workloads into waves, and rehearse the cutover with a rollback path.

Applications with fixed IP allowlists and licence-bound hostnames are the ones that stretch a schedule. Finding them during discovery is cheaper than finding them on cutover night.

Cloud Logging and Monitoring are included but not configured by default in any useful way. We set retention deliberately, because log storage is a recurring cost that grows quietly, and alert on the signals that precede a customer complaint.

A dashboard nobody opens is decoration. An alert that reaches a person who can act is the point.

Most findings are configuration: a service account with owner rights, a bucket with public access, a firewall rule open to the world, or audit logs switched off. Each is quick to fix once found and expensive after an incident.

Our review is a fixed piece of work and produces a written list with severity, not a PDF of generic advice.

Send the workloads and their runtime, the data residency constraints you must meet, whether you already have an organisation and billing account, and who will own the environment afterwards. That last answer decides how much automation and documentation the build needs.

Read next: cloud services for the vendor comparison, cloud migration for the move itself, or landing zone setup for the account structure.