mrvitej.in
Happy Dussehra! May good always win. Happy Diwali! Wishing you a bright year ahead. Merry Christmas! Warm wishes from Vizag. Happy New Year! Here’s to a great year ahead.

Archive · AWS

New AWS Region: Hyderabad (ap-south-2)

AWS opened a second India region on 22 November 2022: how to enable the opt-in region, plan DR between Mumbai and Hyderabad, and what to verify before moving workloads.

4 min read

  • AWS Region ap-south-2
  • AWS Region ap-south-1
  • AWS CLI 2.9
  • S3 CRR

On 22 November 2022 AWS launched the Asia Pacific (Hyderabad) region, ap-south-2, with three Availability Zones. India now has two AWS regions: Mumbai (ap-south-1, since 2016) and Hyderabad. For teams in India this is the first time that disaster recovery, data residency and latency choices exist without leaving the country.

Two regions, one country

flowchart TB
  U[Users in India] --> R53[Route 53 health checks and failover or latency routing]
  R53 --> M
  R53 -.->|failover| H
  subgraph M[Mumbai ap-south-1 primary]
    MA[App tier ECS EKS EC2] --> MD[(RDS or Aurora primary)]
    MA --> MS[(S3 bucket)]
    MA --> ME[(ECR repository)]
  end
  subgraph H[Hyderabad ap-south-2 DR or secondary]
    HA[App tier scaled down warm standby] --> HD[(RDS read replica or restored snapshot)]
    HS[(S3 replica bucket)]
    HE[(ECR replica)]
  end
  MD -->|cross-region replica or snapshot copy| HD
  MS -->|cross-region replication| HS
  ME -->|ECR replication| HE
  IAM[IAM, Organizations and Route 53 are global] --- M
  IAM --- H

Why it matters

  • Data residency and compliance: a second location in India for regulated workloads and auditors who want primary and backup in-country.
  • Disaster recovery: a recovery site in a different geography and power grid from Mumbai, rather than Singapore or elsewhere abroad.
  • Latency: Hyderabad is closer to users in the south and centre of India than Mumbai is, which can help latency-sensitive applications.
  • Capacity: spreading across two regions reduces the effect of a regional capacity or service issue.

It is an opt-in region

Regions launched after March 2019 are disabled by default and must be enabled per account. Enabling takes a few minutes and cannot be done by IAM users without permission; use the account API.

aws account get-region-opt-status --region-name ap-south-2
aws account enable-region --region-name ap-south-2
aws account list-regions --region-opt-status-contains ENABLED ENABLED_BY_DEFAULT ENABLING
aws ec2 describe-availability-zones --region ap-south-2 --query 'AvailabilityZones[].ZoneName'
aws sts get-caller-identity --region ap-south-2

Requirements and side effects:

  • The calling identity needs account:EnableRegion, which is not part of broad “power user” policies; run it from an administrator role in each account (in AWS Organizations, from the management account for member accounts).
  • With Organizations, you can control which regions are usable with a service control policy that denies actions outside an approved list, so teams cannot create resources in forgotten regions.
  • Opt-in regions use regional STS endpoints only; use the regional endpoint or a recent SDK/CLI so credentials work (older tooling that expects the global STS endpoint may fail).
  • Add the region to your tooling: Terraform provider aliases, CI pipelines, CloudTrail (a multi-region trail covers it once enabled), GuardDuty and Config in the new region.

Before you plan on it

  1. Check service availability. A new region starts with core services; some (specific instance families, Aurora features, managed add-ons) arrive later. Check the regional services list for every service you depend on, including the exact instance types.
  2. Quota: service quotas are per region and start at defaults; request increases before a failover day.
  3. Prices differ slightly between regions; compare in the pricing pages before moving workloads for cost reasons.
  4. Data transfer: replication between regions is billed as inter-region transfer.
  5. Latency between regions exists; synchronous cross-region designs are rarely a good idea.

A pragmatic DR plan

Tier What you keep in Hyderabad Recovery time Cost
Backup and restore Copies of snapshots and S3 data Hours Lowest
Pilot light Replicated database, minimal core services, infrastructure code ready Tens of minutes Low
Warm standby Scaled-down copy of the full stack Minutes Medium
Active-active Full stack serving traffic Seconds Highest, plus data conflict design

Typical building blocks:

  • S3 cross-region replication with versioning on both buckets and a replication role; existing objects need a one-time batch job.
  • RDS: cross-region read replicas for MySQL and PostgreSQL (promote on failover), or automated cross-region snapshot copy; Aurora offers Global Database where supported.
  • ECR replication rules so images exist in both regions and a failover does not depend on a Mumbai registry.
  • DynamoDB global tables if the service supports the region at that time.
  • Secrets and KMS keys are regional: replicate secrets (Secrets Manager multi-region) and use multi-Region KMS keys or per-region keys.
  • DNS: Route 53 health checks with failover records, with a low TTL (60 seconds).
  • Infrastructure as code: parameterise the region so the stack deploys to Hyderabad from the same repository.

Test the failover

A DR plan that has never been exercised is a guess. Schedule a game day each half year: promote the replica, deploy the application, point a test hostname at it, measure how long it took, and write down what broke. Record your targets (RTO and RPO) and verify the numbers against reality.