Regions, availability zones and edge locations

Why location matters

Data travels through cables at a large but finite speed. A request from Chennai to a server in Mumbai and back takes a few tens of milliseconds; to the United States it takes a few hundred. That delay is called latency. Laws also care about location: some data must stay in the country. So every cloud lets you choose where your resources live.

Regions

A region is a separate geographic area where a provider runs data centres. Each region is independent: you create resources in a region, and they stay there unless you copy them elsewhere. Each provider has dozens of regions worldwide; check their global infrastructure pages for the current list.

Availability zones

An Availability Zone (AZ) is one or more data centres inside a region with its own independent power, cooling and networking. AZs in a region are kilometres apart, so a flood or power failure in one is unlikely to hit another, but close enough to be joined by fast, low-latency private links. Most AWS regions have three or more AZs, named like ap-south-1a, ap-south-1b and ap-south-1c. Google calls them zones (asia-south1-a, asia-south1-b, asia-south1-c), and Azure also uses availability zones in many regions.

The key design rule: run important apps in at least two AZs. If one zone fails, the other keeps serving users. This is called high availability, and module 10 covers it in depth.

Edge locations and local zones

An edge location, or point of presence (PoP), is a small site in many more cities than regions. It is used mainly by the content delivery network (CDN), a service that keeps copies (a cache) of images, videos and web pages near users. AWS CloudFront, Azure Front Door and Google Cloud CDN use them. A video served from an edge location in Bengaluru reaches a Bengaluru user much faster than one served from Mumbai.

Some providers also offer extensions of a region placed in a big city, for apps that need very low latency there. AWS calls them Local Zones, and has some in Indian cities such as Delhi and Kolkata (check the current list). You will not need them as a beginner, but recognise the name.

How to choose a region

1. Compliance and data residency: does the law or a customer contract require the data to stay in India? If yes, only Indian regions qualify.
2. Latency to users: pick the region nearest most of your users. For an all-India audience, Mumbai or Hyderabad is usually a good start.
3. Service availability: newer services launch in some regions first. Check the provider's list of services by region.
4. Price: the same server can cost a little more or less in different regions. Compare in the pricing calculator.

Apply them in this order: compliance first, because it is a hard yes or no; then filter by the services you need; then pick the lowest latency; use price to break a close tie.