Choose a cloud provider for an India workload only after you know which data it handles, which rules apply, and where every part of the workload may be stored or processed. Then compare providers service by service—not by brand or region name—against those requirements. An India cloud region or a provider’s certification is useful evidence, but neither proves that your particular workload is compliant.
How do you choose a cloud provider in India?
Start with the workload and its obligations, not a shortlist of brands. The right choice for one system may be unsuitable for another because data types, processing purposes, regulated-entity duties, required services, and recovery designs differ.
- Inventory the workload. Record the data it collects, generates, stores, sends, and deletes; the system of record; the processing purposes; and the services and integrations it needs. Include personal, payment, financial, health, government, and business-confidential data where relevant.
- Identify the responsible entity and rules. Determine whether the organization is regulated, which regulator applies to this activity, and which directions or sector requirements govern this workload. Ask the legal or compliance lead to confirm applicability rather than assuming one rule covers every system.
- Write down the geographic boundary. Specify requirements separately for data at rest, replicas and backups, logs and telemetry, data in transit, processing in use, support access, and AI inference. State whether any of these must remain in India, and identify exceptions that need approval.
- Map each required service to provider commitments. Check that the exact service, feature, deployment type, and region are covered by the provider’s current documentation. Record exceptions, unsupported services, and any cross-region behavior.
- Test enforceability and operations. Confirm that organization policies and account controls prevent teams from creating resources or enabling features outside the approved boundary. Review identity, privileged access, encryption and key management, audit logging, incident response, recovery, and deletion evidence.
- Review evidence and contract terms. Evaluate current attestations and audit reports for the relevant service and region. Review audit and inspection rights, subcontractors, jurisdiction, confidentiality, breach notice, continuity, exit, data return, and deletion provisions.
- Document the decision. Record residual risks, compensating controls, owners, and a review date so that service, regulatory, and configuration changes trigger reassessment.
For a regulated financial-services workload, AWS’s India financial-services guidance identifies materials relating to RBI, IRDAI, SEBI, and IFSCA. Which requirements apply depends on the entity and activity; use the relevant regulator’s rules and qualified compliance advice to make that determination.
What does data residency need to cover?
A region selection principally answers where particular services place particular data under particular conditions. It does not, by itself, settle where every related copy or processing activity occurs. Turn the organization’s requirement into a data-flow map that follows information throughout its lifecycle, including generation through permanent deletion.
#1 Best Overall
| Boundary to examine | Questions to resolve |
|---|---|
| Primary storage | Which region stores the database, files, snapshots, and other primary content? Does the commitment apply to this exact service and configuration? |
| Replication and recovery | Where do replicas, backups, disaster-recovery copies, and failover resources go? Are cross-region replication or global recovery features enabled? |
| Logs and telemetry | Do service, security, diagnostic, or usage logs contain workload data or identifiers? Where are they stored and processed, and how long are they retained? |
| Access and support | Can provider personnel or subcontractors access data from outside India? What access controls, approval processes, and audit evidence apply? |
| Processing and transit | Where is data processed while in use, and what happens as it moves between services, regions, or external systems? |
| AI features | Where are prompts, completions, and related data processed for the specific AI service and deployment type? Do preview features have different location behavior? |
| Deletion and exit | How are primary data, copies, logs, and provider-held remnants returned or deleted at contract end or when no longer needed? What evidence can the customer obtain? |
For financial institutions, the RBI Master Direction on Outsourcing of Information Technology Services treats cloud as a governance and lifecycle concern. Its cloud considerations include multi-tenancy and multi-location risks, documented cloud-adoption governance, CSP due diligence and ongoing risk monitoring, and privacy, security, sovereignty, recoverability, and storage needs aligned with data classification. These are responsibilities of the regulated entity, not simply items to delegate to a provider.
Does the DPDP Act require data to be stored in India?
The Digital Personal Data Protection Act, 2023 is relevant when a workload processes personal data, but the Act’s relevance alone does not settle the location requirements for every dataset or regulated activity. Do not infer a storage rule from the Act’s name or treat a provider’s India region as a legal determination. Have counsel or the organization’s compliance lead assess the current law and rules, the data and processing involved, and any additional sector-specific obligations for the workload.
Financial-sector requirements can apply alongside personal-data obligations. The RBI’s IT outsourcing direction separately addresses cloud governance and storage requirements aligned with data classification; other financial activities may also bring RBI, IRDAI, SEBI, or IFSCA materials into scope.
How do AWS, Azure, and Google Cloud differ on India residency?
The following is a comparison of what each provider’s cited documentation says, not a finding that any provider makes a customer workload compliant. Provider commitments are service- and configuration-specific and can change; check the current documentation before design or procurement.
| Provider | What its documentation says | What to verify |
|---|---|---|
| AWS | AWS says customers choose the geographic region for their content. Its India data-protection material says content in the Mumbai Region will not move to another region unless legally required or the customer moves it. AWS also describes a shared-responsibility model. | Confirm the behavior of every service, cross-region feature, backup, support path, and account setting. AWS’s statement describes its service; it is not independent legal assurance or a compliance determination for the customer’s configuration. |
| Microsoft Azure | Microsoft describes residency by geography and documents exceptions: selected features can process data outside the chosen geography; Global AI deployment types may process prompts and completions globally; and preview or prerelease services may store data in the United States or globally. | Check the service-specific commitment and deployment type, especially for AI, security, support, and preview functionality. Do not assume that selecting an India geography covers every feature. |
| Google Cloud | Google’s India Data Boundary provides data-location controls supporting India-only regions, with a defined supported-product list, limitations, and organization-policy constraints. Google warns that unsupported products may affect residency or sovereignty. | Verify that every required product is supported, enforce allowed locations, and review restrictions and limitations for data in use and in transit. |
These distinctions make a brand-level winner misleading. A provider may fit one workload’s required services and controls while another provider better fits a different service portfolio, recovery plan, support model, or contract requirement.
What should a regulated organization check before signing?
- Regulatory fit: Map each workload to its regulated entity, applicable regulator, data classification, and obligations. Keep the reasoning and approvals with the workload record.
- Technical boundaries: Test resource-location policies and prohibited features in the actual account structure. Check whether teams can bypass controls through another project, subscription, account, service, or deployment type.
- Shared responsibility: Assign ownership for identity and privileged access, encryption and key management, configuration, audit logs, incident response, recovery objectives, retention, and deletion. Provider infrastructure controls do not automatically configure customer-side protections.
- Evidence: Review attestations and audit reports for the service and region being purchased, not only a general provider certificate. Confirm that the evidence addresses the control and period relevant to the workload.
- Contract and exit: Establish audit and inspection rights, subcontractor terms, confidentiality, breach notification, continuity arrangements, jurisdiction, data return, and verifiable deletion at exit.
- Operational obligations: Confirm the currently applicable CERT-In directions and FAQs with the organization’s security and legal teams. CERT-In’s official directions page lists directions dated 28 April 2022, an FAQ, and later implementation-timeline material; verify current requirements directly rather than relying on an assumed deadline or retention period.
How can you make the decision auditable?
Keep one decision record per workload rather than a single organization-wide claim that a cloud provider is “compliant in India.” A useful record links the requirement to the service configuration, evidence, responsible owner, and residual risk.
- Data categories, processing purpose, system of record, and retention or deletion needs.
- Applicable entity, regulator, legal or sector requirement, and the person who confirmed applicability.
- Required locations for storage, replication, logs, support access, transit, processing, and AI inference.
- Provider service names, regions, features, deployment types, boundary controls, and any exception or unsupported service.
- Evidence reviewed, including service- and region-relevant audit materials and contract provisions.
- Test results for policy enforcement, recovery, access, and deletion; unresolved risks and compensating controls.
- Named owners and a review date for regulatory, provider-service, and architecture changes.
Revisit the record when a workload adds a service or AI feature, changes its replication or recovery design, changes data categories or purpose, or when the provider’s commitments or applicable rules change.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
