Regions, Availability Zones & Indian Regions

When Ananya builds an app for students in Jaipur, she wants it to respond quickly, keep data in India and stay online even if one data centre has a power failure. All three goals depend on where her resources run. AWS gives you control over this through Regions, Availability Zones and edge locations.

In this lesson you will learn how the AWS global infrastructure is organised, the two Indian Regions, how to list and enable Regions with the CLI, and how to pick a Region for a project.

Regions

A Region is a separate geographic area that contains several groups of data centres. Each Region is independent: resources you create in Mumbai stay in Mumbai unless you copy them elsewhere. In October 2026 AWS listed 39 launched Regions with 124 Availability Zones, with more announced. The count grows every year, so check the AWS global infrastructure page for today's number.

Every Region has a code that you use in the CLI, SDKs and ARNs. India has two Regions:

Regions launched after 20 March 2019, including Hyderabad, are opt-in Regions. They stay disabled until an administrator enables them, which keeps accounts from accidentally spreading resources into Regions nobody watches.

Availability Zones

An Availability Zone (AZ) is one or more discrete data centres inside a Region, each with its own power, cooling and networking, connected to the other AZs by fast private links. The AZs are far enough apart that a flood or power cut in one should not affect the others, yet close enough for low-latency replication.

This is the key to high availability. If Ananya runs two web servers in two different AZs, one AZ can fail and her app keeps working. Many managed services, such as RDS Multi-AZ and DynamoDB, use several AZs for you.

AZs have two kinds of identifier:

• Zone name, such as ap-south-1a. The mapping of names to physical zones can differ between accounts.
• Zone ID, such as aps1-az1. This always refers to the same physical zone in every account, so use it when you coordinate with another account.

aws ec2 describe-availability-zones --region ap-south-1 \
  --query "AvailabilityZones[].{Name: ZoneName, Id: ZoneId, State: State}"

[
    {
        "Name": "ap-south-1a",
        "Id": "aps1-az1",
        "State": "available"
    },
    {
        "Name": "ap-south-1b",
        "Id": "aps1-az3",
        "State": "available"
    },
    {
        "Name": "ap-south-1c",
        "Id": "aps1-az2",
        "State": "available"
    }
]

The --query option filters the JSON reply so you only see the fields you asked for. Your name-to-ID pairs may be different from this example, which is exactly why zone IDs exist.

Opt-in Regions with the CLI

You can check and enable Regions from the CLI with the account commands. First check Hyderabad:

aws account get-region-opt-status --region-name ap-south-2

{
    "RegionName": "ap-south-2",
    "RegionOptStatus": "DISABLED"
}

To enable it, run the command below. It prints nothing on success, and the status passes through ENABLING before it becomes ENABLED, which can take some minutes.

aws account enable-region --region-name ap-south-2
aws account list-regions --region-opt-status-contains ENABLED ENABLED_BY_DEFAULT \
  --query "Regions[?starts_with(RegionName, 'ap-south')].RegionName"

[
    "ap-south-1",
    "ap-south-2"
]

Only enable Regions you plan to use. Every enabled Region is one more place to check for forgotten resources and security settings.

Local Zones and edge locations

• Local Zones put a small set of AWS services in a city, attached to a parent Region, for very low latency. India has Local Zones in Delhi (ap-south-1-del-1a) and Kolkata (ap-south-1-ccu-1a), both attached to Mumbai. Gaming, live video and trading apps use them.
• Edge locations are sites used by Amazon CloudFront (the content delivery network) and Route 53 (DNS). There are edge locations in several Indian cities, so a visitor in Kochi can get your images from a nearby cache instead of from Mumbai. You will use them in CloudFront CDN.

Global services

Some services are not tied to one Region. IAM users and roles work in every Region. Route 53 and CloudFront are global. A few global features keep their data in US East (N. Virginia), us-east-1: billing metrics for alarms, and TLS certificates used by CloudFront. Do not be surprised when a lesson asks you to switch to us-east-1 for those tasks.

Choosing a Region

Ask four questions, roughly in this order:

1. Law and compliance: must the data stay in India? Payment companies follow RBI's data localisation rules, and the DPDP Act 2023 governs personal data. A Mumbai or Hyderabad Region keeps data in the country.
2. Latency: choose a Region close to your users. For users across India, Mumbai or Hyderabad is usually fastest.
3. Service availability: new services and features often reach a few Regions first. Check the "AWS Services by Region" list before you commit.
4. Cost: prices differ between Regions. Compare them on each service's official pricing page.

A common pattern for Indian businesses is to run production in Mumbai across three AZs and keep backups or a standby copy in Hyderabad for disaster recovery.

Common mistakes

• Creating resources in the wrong Region. The console remembers the last Region you used. Always glance at the Region selector before creating anything.
• Putting everything in one AZ. A single-AZ design fails when that AZ has a problem. Spread production servers over at least two AZs.
• Treating zone names as the same across accounts. ap-south-1a in your account may be a different building from ap-south-1a in a partner's account. Use zone IDs.
• Forgetting that Hyderabad needs opting in. Commands for ap-south-2 fail until the Region is enabled.

Key points

• A Region is an independent geographic area; an Availability Zone is a separate data centre group inside it.
• India has Mumbai (ap-south-1, enabled by default) and Hyderabad (ap-south-2, opt-in), each with three AZs.
• Spread workloads across AZs for high availability; use a second Region for disaster recovery.
• Zone IDs such as aps1-az1 identify the same physical zone in every account.
• Local Zones (Delhi, Kolkata) and edge locations bring some services closer to users.
• Choose a Region by compliance, latency, service availability and cost.

aws account get-region-opt-status --region-name ap-south-2

aws ec2 describe-availability-zones --region ap-south-2 \
  --query "AvailabilityZones[].{Name: ZoneName, Id: ZoneId}"