ap-south-1
The AWS Mumbai region code. A data residency claim should say what is stored there and which sub-processors receive data outside India.
ap-south-1 is the AWS Mumbai region. Data residency claims should state exactly what is stored there and which sub-processors receive data outside India.
ap-south-1 is the AWS Mumbai region. Data residency claims should state exactly what is stored there and which sub-processors receive data outside India.
Related
The short version
- ap-south-1 is the AWS Asia Pacific (Mumbai) region: a set of physically separate data centres in and around Mumbai, addressed by regional endpoints and billed as an Indian region.
- Choosing it places the resources you launch there in India. It does not, by itself, keep every byte in India, because global services, support access, control-plane metadata and sub-processors sit outside the region boundary.
- Under the DPDP Act, cross-border transfer is permitted except to countries the government restricts by notification, so residency is a contractual and architectural choice more often than a legal absolute.
- Sector rules are stricter than the Act. Payment data has an RBI storage directive, and financial and insurance regulators impose their own cloud conditions that a general residency claim will not satisfy.
- A residency claim should name the data categories stored in region, the services in scope, the sub-processors that receive data, and the exact contractual clause that binds them.
- Verify with configuration evidence and a signed DPA schedule, not with a badge on a marketing page.
What ap-south-1 actually is
ap-south-1 is the region code for AWS Asia Pacific (Mumbai). AWS launched it in 2016, and it is one of two Indian regions today, alongside ap-south-2 in Hyderabad. A region is a geographic cluster of availability zones: separate physical facilities with independent power, cooling and networking, close enough to replicate synchronously and far enough apart that a single incident is unlikely to take all of them down. Mumbai has three zones, labelled a, b and c.
Every regional service has an endpoint that includes the region name, which is how a client chooses where its request is handled. That endpoint is the practical meaning of residency for most workloads: an S3 bucket created with the Mumbai endpoint stores its objects in Mumbai, an RDS instance launched there runs on hardware in the region, and a Lambda function invoked there executes in the region unless it is configured to call something else.
What ap-south-1 is not: it is not a compliance certificate, it is not a promise that no AWS employee anywhere can see a packet, and it is not a synonym for data localisation. It is a placement decision. The rest of the residency story is made of service choices, contracts and architecture, and it is the part that vendors tend to leave out of the slide. Nor is it a feature of an agent. An Agent OS, an agentic workflow and an AI SDR can all run on Mumbai infrastructure and still call a model endpoint in another country, which is why the inference path belongs in the same review as the database.
What residency covers, layer by layer
Residency has layers, and a claim is only as strong as its weakest layer. The first is data at rest: object storage, block storage, databases, backups, snapshots and archives. The second is data in transit within the region, which is encrypted between zones but still traverses AWS networking. The third is the control plane: the API calls that create and configure resources, and the metadata those calls generate. The fourth is operational access: support, incident response and any human who can read a log.
Most teams get the first layer right and assume the rest follows. It does not. A bucket in Mumbai whose access logs are shipped to a monitoring service in Virginia is not an India-only system. A database in Mumbai whose read replica sits in Singapore is not either, and neither is a queue whose dead-letter messages are forwarded to a third-party error tracker abroad. Each of those is a deliberate design decision, and each needs to be listed if a customer asks.
The useful discipline is to draw the data flow, not the architecture diagram. Follow a single record from collection to deletion: which service writes it, which service reads it, which service copies it, and which service exports it. The diagram that results is usually messier than the one on the website, and it is the one a data protection officer will ask for.
The parts of AWS that are not regional
Several AWS services are global by design. IAM is the clearest example: users, roles and policies live in a global namespace, and while the data is stored in a specific location, the service is not something you place in a region. Route 53 is a global DNS service. CloudFront is a global content delivery network with edge locations in India and elsewhere. Organizations, billing and the account itself sit outside the regional boundary. None of these necessarily holds personal data, but each holds metadata about your infrastructure, and some hold identifiers.
CloudFront is worth special attention because it is often presented as a residency feature. It caches content close to users, which is good for latency in India, and it terminates TLS at the edge, which means request metadata exists outside the region. Access logs can be delivered to an S3 bucket in Mumbai, but the network itself is global. If you need strict placement, serve from the region behind a load balancer and accept the latency, or use the edge only for static assets that contain no personal data.
Support is the layer teams forget entirely. A support case may be handled by an engineer outside India, and access to customer data is possible under defined conditions. That is a legitimate operational model, but it belongs in the sub-processor list and the DPA conversation, not in a footnote that says support is available 24 by 7.
DPDP, cross-border transfer and what the Act really says
The Digital Personal Data Protection Act 2023 does not require data to stay in India. It permits transfer to other countries except those the central government restricts by notification, which is a blacklist model rather than a whitelist. The obligations that travel with the data are notice, consent or another lawful basis, purpose limitation, security safeguards, breach reporting and the rights of the data principal. Residency can help you satisfy those duties, but it is not one of them.
This surprises teams who expect a localisation mandate. The operative question is not where the data sits but whether you can meet the duties wherever it sits, including when a data principal asks for a copy or for erasure. A system split across three countries can comply if it has an inventory and a deletion path. A system entirely in Mumbai can fail if nobody knows which bucket holds the backups.
Two exceptions matter. Significant Data Fiduciaries may face additional obligations, including restrictions determined by the government. And sector regulators impose their own conditions that go beyond the Act. A payment system, an insurer and a broker are not governed only by DPDP, and a vendor whose security page addresses only DPDP has answered a different question from the one their regulated customer asked.
Sector rules that are stricter than the Act
The Reserve Bank of India’s 2018 directive on storage of payment system data requires payment system operators to store payment data only in India. It allows processing abroad in limited circumstances provided the data is brought back and stored in India, and it prohibits storing a copy elsewhere. For a fintech, that is a materially stronger requirement than DPDP, and it covers card data, transaction records and the identifiers attached to them.
SEBI’s cybersecurity and cloud framework for regulated entities adds conditions on cloud adoption, including notification, data classification and exit provisions. IRDAI’s information and cyber security guidelines do the same for insurers. Neither regulator is satisfied by a region code. Both expect a documented assessment, a contract that supports audit, and an exit plan that does not leave the data stranded.
The practical implication for a vendor is that a single answer cannot serve all customers. A D2C brand may accept a Mumbai region with a US-based model provider if the contract and the notice cover it. A lender may not. Product teams should offer a residency profile per plan or per contract, and sales should know which profile is being sold, because a promise made in a proposal becomes a contractual obligation.
Latency, edge and the reason teams pick the wrong region
For users in India, ap-south-1 usually gives the lowest round-trip time for application traffic, because the request does not leave the country. Users in Singapore or the Gulf may be better served from another region, and a global product often ends up with a primary region per market rather than one region for everyone. That is a normal architecture, and it does not undermine a residency claim as long as the claim is scoped to the users it covers.
Edge caching improves the first byte for static assets without moving the origin. The mistake is to treat a CDN as a residency solution: the cache is everywhere, the logs may be delivered centrally, and the origin still has to be somewhere. If the content is a product image, none of this matters. If the response is personalised, the edge is now handling personal data and the analysis changes.
A related trap is cross-region replication for disaster recovery. A standby copy in Singapore gives resilience against a regional failure and creates a second jurisdiction for the same records. That may be acceptable, and it must be disclosed. The alternative, a second Indian region in Hyderabad, keeps the data in the country and still protects against a Mumbai-level event, at the cost of cross-region latency during failover.
Sub-processors: where the data actually goes
A modern stack has more sub-processors than the architecture diagram admits. The model provider may run inference in the United States or Singapore. The messaging provider is a Meta business partner with its own infrastructure. The email provider has data centres in multiple regions. The observability tool stores traces abroad. The support desk stores tickets abroad. Each of these receives some personal data, and each belongs on the list.
The contractual instruments are a data processing agreement with flow-down terms, a published sub-processor list with change notice, and a mechanism to object. In practice the list is where most claims fail: a vendor says data stays in India, then the sub-processor page names a US analytics provider. That is not necessarily a breach, but it is a contradiction that a customer’s legal team will find, and it is better found by you first.
For AI workloads the question is sharper because inference sends content to a model endpoint. If the endpoint is outside India, the prompt and the retrieved context leave the country on every call. LoopNow runs its chat and agent models through a configurable endpoint and documents the path, because a residency claim that ignores inference is a claim about storage only.
How to verify a residency claim
Ask for four artefacts and read them against each other. The DPA schedule, which should name categories, purposes, locations and sub-processors. The sub-processor page, which should match the schedule and carry a last-updated date. The configuration evidence, which might be a screenshot of the region selector, a bucket policy or an architecture description signed by engineering. And the audit or certification report, with its scope statement, because a certificate that covers the corporate entity but not the specific service proves less than it appears to.
Then test the claim with a scenario. A customer in Pune asks for deletion. Walk the request through the system: which databases, which backups, which vector index, which logs, which sub-processor holds a copy. If the answer requires three teams and a spreadsheet, the claim is aspirational. If it is a documented runbook with a measured completion time, it is real.
Finally, check the exit. A residency commitment that cannot be exited is a lock-in with a compliance label. The contract should say what happens to the data at termination, in what format it is returned, how long it is retained and how deletion is certified.
Cost and billing in an Indian region
AWS prices differ by region, and Mumbai is not the cheapest. Compute, storage and especially data transfer carry a premium relative to some other regions, which is the price of locality. For a workload that is mostly database and application servers, the difference is manageable. For a data-heavy workload with large egress, it can be material, and it should be modelled before the architecture is frozen.
Indian customers are billed by AWS India in rupees, with GST applied to the invoice, which simplifies input credit compared with a dollar charge on a corporate card. Cross-region transfer, support plans and marketplace purchases can complicate the picture, so finance should see a sample invoice rather than a price list. A rupee budget also removes the currency surprise that dollar billing creates when the exchange rate moves.
The comparison to run is total cost of locality, not instance price. Add the cross-region replication, the duplicated storage, the egress for analytics and the engineering time to maintain a second environment. Then compare it with the commercial value of being able to answer the residency question in a procurement review. For some deals that value is decisive, and for others it is not.
Worked example: an honest India-only claim
A lending platform wants to tell customers that their data never leaves India. Engineering maps the flow and finds four exceptions: inference calls to a model endpoint in Singapore, product analytics to a US service, support tickets in a global helpdesk and backups replicated to Singapore for disaster recovery. Storage and the primary database are already in ap-south-1.
The team fixes what it can. Inference moves to an India-hosted endpoint for the customer-facing agent, with the overseas model reserved for internal summarisation on de-identified text. Analytics moves to a self-hosted collector in the VPC. Backups replicate to ap-south-2 instead of Singapore. The helpdesk remains global, and is disclosed as a sub-processor with the categories it receives and the retention period.
The resulting claim is narrower and defensible: customer records, call recordings and transaction data are stored and processed in India, with one named exception for support tickets. That sentence survives a procurement review because it is specific. The original claim would not have survived the first question.
Frequently asked questions
Does ap-south-1 keep all my data in India?
Only the resources you place there. Global services such as IAM, Route 53 and CloudFront, support access, and any third-party sub-processor you connect can move data or metadata outside the region. A truthful answer lists the exceptions rather than asserting that nothing leaves.
Is data localisation mandatory under DPDP?
No. The Act permits transfer except to countries the government restricts by notification. It requires notice, a lawful basis, security safeguards and rights fulfilment regardless of location. Sector regulators such as RBI, SEBI and IRDAI impose stricter conditions for the entities they regulate.
What is the difference between ap-south-1 and ap-south-2?
They are separate regions, not availability zones. ap-south-1 is Mumbai and ap-south-2 is Hyderabad, each with its own zones and endpoints. Replicating between them is a cross-region design that keeps data in India while protecting against a Mumbai-level failure, at the cost of replication and failover complexity.
Does CloudFront break residency?
It can complicate it. CloudFront is a global network that terminates TLS at edge locations and handles request metadata outside the region. If you serve only static, non-personal assets through it, the risk is low. If responses are personalised, the edge is processing personal data and belongs in the assessment.
Can AWS support see my data?
Support access is possible under defined conditions and may involve engineers outside India. That is a legitimate model, but it belongs in the sub-processor list and the DPA conversation. Customers who need stricter terms should discuss account-level support restrictions and the contractual entity that provides support.
What does RBI require for payment data?
The 2018 directive requires payment system data to be stored only in India, with limited provision for processing abroad if the data is brought back and stored in India, and no storage of a copy elsewhere. It is stricter than DPDP and applies to payment system operators, so a fintech needs a separate assessment.
Is Mumbai more expensive than other regions?
Generally yes for compute and data transfer, and the gap varies by service. Model the total cost of locality, including replication, duplicated storage and engineering time, rather than comparing instance prices. Indian billing in rupees with GST also simplifies input credit compared with a dollar charge.
How do I prove a vendor’s residency claim?
Ask for the DPA schedule, the sub-processor register, configuration evidence signed by engineering, and the scope statement of any audit report. Then walk a deletion request through the system. If nobody can name every store that holds the record, the claim is not yet operational.
Can we run inference in India?
Yes, with India-hosted model endpoints, and that is often the most consequential fix for an AI product because inference sends prompt content out on every call. Where a specific model is only available abroad, restrict it to de-identified or non-personal text and disclose the path.