Cloud selection generates more debate than almost any other architecture decision and deserves less of it. All three platforms will run your web application reliably. The differences that matter are rarely technical capability and almost always organisational: what your team knows, what you already pay for, and where your data must live.
This is how we actually advise clients, including the cases where the answer is none of the three.
The honest headline
For a standard web application — a front end, an API, a relational database, object storage, a CDN and a queue — all three clouds offer mature managed services that will serve you well. The architecture you build on top will determine your cost and reliability far more than the logo on the invoice.
We have seen well-architected systems on all three running at 99.98% uptime for a fraction of what a badly architected system on the same platform costs. The variance within a platform vastly exceeds the variance between platforms.
So treat the decision as a hiring and procurement question first, and a technical one second.
Where each genuinely wins
AWS has the broadest service catalogue and the deepest talent pool in India. If you expect to bring operations in-house eventually, or to change vendors, AWS skills are the easiest to hire for in Kolkata by a clear margin. Its data services — S3 with Iceberg, Glue, EMR, Athena — form a complete lakehouse without proprietary storage formats.
Azure wins decisively when the organisation already runs Microsoft 365 and Active Directory. Entra ID single sign-on and conditional access apply to new applications without a separate identity project, access reviews happen where IT already runs them, and enterprise agreement pricing is frequently better than list. Data Factory's self-hosted integration runtime is also genuinely the best tool for reaching on-premise SQL Server and SAP behind a firewall.
Google Cloud is strongest where analytics is the centre of gravity. BigQuery is the most operationally simple serverless warehouse available — no clusters to size, no warehouses to suspend, concurrency handled by the platform. Its networking is excellent, and Cloud Run is the least ceremonious way to run a container we have used.
| Situation | Recommendation | Reason |
|---|---|---|
| No strong existing commitment | AWS | Broadest catalogue, deepest Indian hiring pool |
| Microsoft 365 and AD already central | Azure | Identity integration and EA pricing |
| Analytics-led, spiky query workload | Google Cloud | BigQuery serverless with no capacity planning |
| Significant on-premise SQL Server / SAP | Azure | Self-hosted integration runtime is the best tool for this |
| Small app, tiny team, cost-sensitive | Managed platform or DigitalOcean | Hyperscaler complexity is not free |
| Data cannot leave the premises | On-premise | None of the three; build the equivalent locally |
Cost: the shape matters more than the rate
Headline compute rates are close enough between the three that they rarely decide anything. What differs is the shape of the bill and where the surprises hide.
On AWS, the recurring surprises are NAT gateway data processing charges, cross-availability-zone transfer, and unattached volumes and snapshots accumulating. On Azure, it is over-provisioned App Service plans and Cosmos DB provisioned throughput left at a launch-day setting. On Google Cloud, it is BigQuery on-demand pricing meeting an unpartitioned table and a dashboard refreshing every fifteen minutes.
Across estates we review, the median reduction available is around 38% without any loss of capability — and the levers are the same everywhere: tag and attribute spend, right-size from actual utilisation, shut down non-production outside working hours, apply commitments only to the stable baseline, and lifecycle storage.
In practice
Data residency and Indian regions
All three operate Indian regions — AWS in Mumbai and Hyderabad, Azure in Central and South India, Google Cloud in Mumbai and Delhi. For most workloads that satisfies residency requirements comfortably.
Where it gets specific: certain regulated sectors and government contracts require data to remain in India with contractual and audit guarantees, not merely regional placement. Implement policy constraints that prevent resource creation outside approved regions rather than relying on convention, and configure logging and backup to stay in-region too — backups leaving the country is the most commonly overlooked path.
And for clients whose data genuinely cannot go to public cloud at all — some defence-adjacent work, some plant data — the answer is none of the three. We build the equivalent architecture on-premise with MinIO, Spark on Kubernetes and Iceberg, and are honest that it costs more in operational effort.
Talent availability in Kolkata
This is the factor most technical comparisons ignore and most clients feel within two years. When you need to hire a cloud engineer, or when your vendor relationship ends and you need another, the size of the local pool determines how quickly and how expensively that happens.
In Kolkata specifically, AWS depth is greatest, Azure is strong and growing — helped by the enterprise Microsoft presence — and Google Cloud is thinnest, concentrated in data-focused roles.
That does not mean avoid GCP. It means that if you choose it, plan for a smaller hiring pool and weight your documentation and handover accordingly.
Our decision rule
If you are already committed to Microsoft 365 and Active Directory: Azure. If analytics is the centre of gravity and the workload is spiky: Google Cloud. Otherwise: AWS, for catalogue breadth and hiring depth.
And regardless of choice, the things that actually determine your outcome are the same everywhere: infrastructure as code so environments are reproducible, a deployment pipeline that makes releases boring, monitoring that tells you before your customer does, backups you have actually restored, and cost attribution specific enough to act on.
We have never seen a project fail because of the cloud it chose. We have seen many fail because none of those five things existed.
Key takeaways
- Variance within a platform vastly exceeds variance between platforms — architecture decides your outcome.
- Azure if Microsoft 365 and AD are already central; GCP if analytics-led and spiky; AWS otherwise.
- Cost surprises differ by platform but the reduction levers are identical, and median available saving is ~38%.
- Enforce residency with policy constraints, and remember backups are the commonly overlooked path out.
- Weight your choice by local hiring depth — you will feel it in year two.
Frequently asked
Probably not, unless you have many services, need sophisticated scaling behaviour, or already have people who operate it. A single application with predictable traffic runs perfectly well on ECS, Cloud Run or App Service with far less operational overhead. We have simplified more over-engineered Kubernetes setups than we have built new ones.
Yes, and it is most of our infrastructure work. We start with a review covering security posture, cost, backup verification and deployment process, then bring the estate under Terraform progressively rather than rebuilding. An undocumented estate is typically fully codified and instrumented within four to eight weeks with no service disruption.
For most mid-market organisations, no. It doubles the operational surface, the skills required and the tooling, in exchange for a portability benefit rarely exercised. Where it makes sense is using one cloud for applications and another for a specific data capability that is genuinely better there — a deliberate, bounded split rather than a general policy.
Then none of the three is the answer, and we build the equivalent on-premise: object storage with MinIO, Spark on Kubernetes, Iceberg tables, Trino for query, self-hosted Airflow. It requires more operational effort than managed cloud and we quantify that honestly rather than pretending otherwise.