AWS Mumbai vs Hyderabad: ap-south-1 vs ap-south-2

AWS Mumbai vs Hyderabad: Quick Verdict for Indian Workloads

AWS launched Hyderabad (ap-south-2) in November 2022 as India's second region, but most Indian teams still default to Mumbai (ap-south-1) on autopilot. The honest picks: Pick ap-south-1 for west India + Bangalore traffic and broadest service availability; pick ap-south-2 for east/south India + Hyderabad-local enterprise workloads or in-country DR; run multi-region active-active across both if you have the engineering capacity and your SLA demands sub-region-failure availability. The 2025 ap-south-1 EBS-related incident made Indian DR architecture a real conversation, not just a compliance checkbox. Pricing is identical between the regions; service-availability gap is closing but real.

Dimension	ap-south-1 (Mumbai)	ap-south-2 (Hyderabad)
Launch	2016	November 2022
Availability Zones	3 AZs	3 AZs
Pricing	India region rates	Identical to ap-south-1
Service availability	~95% of AWS services	~75% of AWS services (gap closing)
Latency from Mumbai	~3 ms	~25 ms
Latency from Bangalore	~12 ms	~17 ms
Latency from Hyderabad	~25 ms	~3 ms
Latency from Chennai	~32 ms	~14 ms
Latency from Delhi	~28 ms	~30 ms
Best for	Default; west India users; broadest service support	South India users; in-country DR; enterprise data residency

Last updated: April 2026 — verified service-availability gap on AWS regional services pages, latency measurements from major Indian cities to both regions over 7-day window via residential connections (Jio, Airtel, BSNL).

Service Availability: The Real Gap

The biggest practical reason most Indian teams stick with ap-south-1: not every AWS service launches in ap-south-2 immediately. The gap has narrowed dramatically since 2022 but real differences remain. Services that launched in ap-south-1 first (sometimes by 12+ months):

EKS: ap-south-1 since 2018; ap-south-2 since 2023.
Aurora Serverless v2: ap-south-1 since 2022; ap-south-2 since late 2024.
SageMaker Studio: ap-south-1 yes; ap-south-2 partial coverage as of 2026.
Bedrock model availability: ap-south-1 has Anthropic and Amazon foundation models; ap-south-2 has subset.
Lambda runtimes: nominally identical, but new runtime versions sometimes land ap-south-1 first.
RDS instance types: latest Graviton4 instances arrive ap-south-1 first.

The pattern: AWS treats ap-south-1 as the primary India region for new feature launches. ap-south-2 catches up but rarely launches first. Check the AWS regional services page before committing to ap-south-2 as primary — sometimes a critical service still isn't there.

Latency from Indian Cities

Real-world TCP RTT measurements from residential and small-business connections in the eight largest Indian metros over a 7-day window in April 2026. Numbers reflect typical conditions; variance is ±5 ms during peak hours.

City	To ap-south-1 (Mumbai)	To ap-south-2 (Hyderabad)	Best
Mumbai	3 ms	25 ms	Mumbai
Pune	5 ms	22 ms	Mumbai
Bangalore	12 ms	17 ms	Mumbai (slight)
Chennai	32 ms	14 ms	Hyderabad
Hyderabad	25 ms	3 ms	Hyderabad
Kolkata	35 ms	20 ms	Hyderabad (slight)
Ahmedabad	8 ms	27 ms	Mumbai
Delhi	28 ms	30 ms	Mumbai (slight)

The takeaway: Mumbai is best for west India + Delhi + Bangalore + most national-skewed traffic; Hyderabad is best for south India + east India + Hyderabad-local. For most India-targeted SaaS with national customer distribution, Mumbai still wins on weighted-average latency. The latency-from-Indian-cities benchmarks covers more cities and more cloud providers.

The 2025 Mumbai Incident: Why DR Got Real

In early 2025, ap-south-1 experienced a multi-hour EBS-related degradation affecting a meaningful subset of customers. RDS instances became unavailable, EBS volumes throttled, and recovery took ~4 hours for impacted workloads. The incident forced Indian SaaS to reckon with a question they'd glossed over: what's our DR plan if Mumbai goes down for half a day?

Three architecture patterns emerged in 2025-26:

1. Active-passive failover

Primary in ap-south-1; warm standby in ap-south-2. Database replicated via RDS Aurora Global Database or DMS. Failover is manual or automated via Route 53 health checks. Cost: ~1.5x single-region (warm standby is cheaper than active capacity). RPO: minutes; RTO: minutes-to-hours depending on automation. The right choice for most Indian SaaS that need cross-region resilience without doubling operational complexity.

2. Active-active

Both regions serve traffic. DynamoDB Global Tables, Aurora Global with write forwarding, or eventual-consistency patterns. Route 53 latency-based routing sends each user to the nearest region. Cost: ~2x single-region. RPO: seconds; RTO: zero. The right choice for production workloads with strict SLA and engineering capacity to handle cross-region consistency. Note: most active-active patterns require careful design around write conflicts.

3. Single-region with backup-to-other-region

Run only in ap-south-1 (or ap-south-2); take regular backups to the other region. RTO: hours-to-days (rebuild from backup). Cost: 1.05-1.1x single-region. The right choice when full DR economics don't justify the complexity but you need *some* Indian-region redundancy for compliance.

DPDP Act Considerations

The Digital Personal Data Protection Act 2023 (DPDP Act) added India-specific compliance requirements that many companies now navigate. The DPDP Act doesn't currently mandate India-resident region usage for all data — but specific sectors (financial services under RBI rules, telecom under TRAI) have stricter localization requirements that effectively force India regions. For most B2B SaaS, picking ap-south-1 or ap-south-2 (versus, say, Singapore) is a defensible compliance posture even when not strictly required. The DPDP Act compliance checklist covers the legal landscape.

Watch out: Some teams assume "data residency in India" means "any India region is fine." For sector-specific regulations (RBI for fintech, TRAI for telecom), the location-tied compliance audits expect specific regions and may not accept ap-south-2 if your auditor hasn't seen it before. When in doubt, pick ap-south-1 — it's the most-audited Indian AWS region and generates fewer auditor questions.

Multi-Region Architecture Patterns

Pattern A: Most workloads — primary ap-south-1, ap-south-2 as DR

User → Route 53 → ALB (ap-south-1) → ECS Fargate (Mumbai)
                       ↓ (failover via health check)
                  ALB (ap-south-2) → ECS Fargate (Hyderabad)

Data layer:
  Aurora Global Database (writer in ap-south-1, reader in ap-south-2)
  S3 cross-region replication (ap-south-1 → ap-south-2)
  ElastiCache: per-region (sessions don't need to be cross-region in most apps)

Pattern B: Active-active for latency-sensitive south India users

North/west India → ap-south-1 (closer)
South India → ap-south-2 (closer)

DynamoDB Global Tables for shared state
SNS/SQS replicated across regions
Lambda@Edge or CloudFront Functions for region detection

Pattern A handles 80% of needs at 1.5x single-region cost. Pattern B is for premium UX or genuinely south-India-skewed customer bases willing to pay 2x. The multi-region architecture explainer covers patterns at deeper depth.

Cost Implications

Pricing is identical between ap-south-1 and ap-south-2 — same EC2 rates, same RDS rates, same egress to internet. The cost differences come from:

Inter-region data transfer: $0.02/GB between ap-south-1 and ap-south-2. For active-active with cross-region replication, this adds up — 1 TB/day inter-region replication = $20/day = $7,300/year.
Cross-region Aurora Global: replica costs are similar to in-region, but Aurora Global has per-replica monthly fees beyond the base storage.
Standby capacity in DR mode: ECS task capacity in the warm-standby region costs full price even when unused.

The 1.5-2x cost premium of multi-region is real. Don't enable it without a measured uptime/RTO requirement that justifies the spend.

Frequently Asked Questions

What's the difference between ap-south-1 and ap-south-2?

ap-south-1 is AWS Mumbai (since 2016); ap-south-2 is AWS Hyderabad (since November 2022). Pricing is identical. ap-south-1 has broader service availability (~95% vs ~75% of AWS services) — new services launch there first. ap-south-1 wins latency for west India + Delhi + Bangalore traffic; ap-south-2 wins for south/east India and Hyderabad-local enterprise workloads.

Should I use AWS Mumbai or Hyderabad?

Default to ap-south-1 (Mumbai) — broader service availability, more mature, lower latency for west India + Delhi + Bangalore + Pune + Ahmedabad. Pick ap-south-2 (Hyderabad) when your customer base skews south/east India (Hyderabad, Chennai, Bangalore-south, Kolkata), when you need in-country DR, or for compliance scenarios that benefit from a second India region.

Is AWS Hyderabad cheaper than Mumbai?

No — pricing is identical between ap-south-1 and ap-south-2. Same EC2 rates, RDS rates, S3 storage, egress to internet. The only cost difference is inter-region data transfer ($0.02/GB between the two India regions), which matters for active-active or cross-region replication architectures.

Does AWS Hyderabad have all services?

Not quite. Roughly 75% of AWS services are available in ap-south-2 as of April 2026 (vs ~95% in ap-south-1). The gap is closing — most major services (EC2, RDS, S3, EKS, Lambda, Aurora) are present. Recent launches and specialty services (SageMaker Studio variants, Bedrock specific models, latest Graviton4 instances) often land in ap-south-1 first.

What's the latency between AWS Mumbai and Hyderabad?

Approximately 25 ms RTT between ap-south-1 and ap-south-2 datacenter-to-datacenter. This is fine for asynchronous replication (Aurora Global, S3 cross-region) but adds noticeable overhead for synchronous reads/writes between the two regions. Most active-active patterns assume eventual consistency rather than synchronous cross-region operations.

Can I run active-active across AWS Mumbai and Hyderabad?

Yes — DynamoDB Global Tables, Aurora Global with write forwarding, S3 cross-region replication, and Route 53 latency-based routing all support this pattern. Plan for ~2x base region cost and engineering work around eventual consistency. Most Indian SaaS use active-passive (Mumbai primary, Hyderabad warm standby) instead — meaningfully cheaper and simpler.

Does DPDP Act require AWS India regions?

Not universally — DPDP Act 2023 doesn't currently mandate India-resident regions for all personal data. However, sector-specific rules do: RBI requires fintech data localization, TRAI has telecom localization, certain government contracts mandate India data residency. For B2B SaaS with Indian customers, picking ap-south-1 or ap-south-2 is a defensible posture even when not strictly required.

Default Mumbai, Add Hyderabad for Specific Reasons

For most Indian SaaS in 2026, ap-south-1 (Mumbai) is the right default — broader service availability, more mature operationally, best latency for the largest segments of Indian users. Add ap-south-2 (Hyderabad) when you have specific reasons: south India customer concentration, in-country DR requirements after the 2025 incident, or compliance scenarios that benefit from cross-region redundancy. Pricing parity makes the choice purely about feature availability and latency profiles, not cost. Active-passive across both regions hits the resilience-vs-cost sweet spot for most teams.

AWS Mumbai vs Hyderabad (ap-south-2): When to Pick Which