Cloud Regions, Availability Zones and Basic Networking Explained

A food-delivery start-up serves one city from servers in a data centre a few kilometres away, and orders feel instant. Then it launches in a second country, and the owner in that country complains that the app is slow, while the lawyer asks where customer addresses are stored. Both problems are about where the system physically runs. The cloud gives you a vocabulary for choosing that place.

Regions and availability zones

A region is a geographic area where a provider operates a cluster of data centres, for example "western Europe" or "southern India"; each provider has its own list of names. Regions are separate from each other by design: an outage in one is not supposed to spread to another, and each has its own prices and its own list of available services. An availability zone (AZ) is one or more data centres inside a region with independent power, cooling and networking, connected to the other zones in the region by fast, low-latency links. Providers use slightly different terms and guarantees, so check the specifics for the one you use.

For most business applications, running across two or more zones of one region gives the best balance. Going multi-region is a deliberate step you take for strict recovery requirements, legal needs or global latency, not the default.

Choosing a region

• Latency: light in optical fibre covers roughly 200 kilometres per millisecond at best, and real paths are longer and slower than the map distance. Put compute near your users, and remember each round trip your app makes multiplies the delay.
• Data residency and law: some data, such as health or financial records, may have to remain within a country or economic area. This is a legal question; involve whoever handles compliance before choosing.
• Service availability: newer services and some machine types arrive in some regions before others.
• Price: the same service can cost different amounts in different regions.
• Where your other pieces are: moving data between regions or out to the internet is usually billed, so keep chatty components together.

A virtual network, laid out on paper

Inside a region you create a virtual network (called a VPC or VNet depending on the provider): your own private address space, cut into subnets. A common layout uses three tiers across two zones. Public subnets hold only what must face the internet, such as the load balancer. Private subnets hold application servers that receive traffic only from the load balancer. Data subnets hold databases with no route to the internet at all. The Python standard library can do the arithmetic for you.

import ipaddress

network = ipaddress.ip_network("10.20.0.0/16")
blocks = list(network.subnets(new_prefix=24))       # 256 possible /24 blocks

plan = {
    "public-zone-a":  blocks[0],    # load balancer, NAT gateway
    "public-zone-b":  blocks[1],
    "private-zone-a": blocks[10],   # app servers
    "private-zone-b": blocks[11],
    "data-zone-a":    blocks[20],   # database, no route to the internet
    "data-zone-b":    blocks[21],
}

print("network", network, "holds", len(blocks), "subnets of /24")
for name, block in plan.items():
    print(f"{name:15} {str(block):14} {block.num_addresses} addresses")

probe = ipaddress.ip_address("10.20.10.57")
owner = [n for n, b in plan.items() if probe in b]
print()
print(probe, "belongs to", owner)
print("overlaps with 10.20.0.0/16?", network.overlaps(ipaddress.ip_network("10.20.5.0/24")))
print("overlaps with 192.168.0.0/16?", network.overlaps(ipaddress.ip_network("192.168.0.0/16")))

network 10.20.0.0/16 holds 256 subnets of /24
public-zone-a   10.20.0.0/24   256 addresses
public-zone-b   10.20.1.0/24   256 addresses
private-zone-a  10.20.10.0/24  256 addresses
private-zone-b  10.20.11.0/24  256 addresses
data-zone-a     10.20.20.0/24  256 addresses
data-zone-b     10.20.21.0/24  256 addresses

10.20.10.57 belongs to ['private-zone-a']
overlaps with 10.20.0.0/16? True
overlaps with 192.168.0.0/16? False

The addresses (like 10.20.0.0/16) are private ranges, usable only inside your network. The number after the slash says how many leading bits are fixed: a /16 leaves room for 65,536 addresses and a /24 for 256. In real clouds each subnet loses a handful of addresses to the provider, and the number varies, so do not plan to use all 256. The overlap check matters in practice: if you later connect this network to an office or to another network, overlapping ranges cannot be routed, so plan ranges before you build.

        Internet
           |
      [ DNS / CDN ]
           |
   +-------+-------------------------+
   | Virtual network 10.20.0.0/16    |
   |                                 |
   |  Zone A            Zone B       |
   |  public  .0/24     public .1/24 |
   |   [LB node] <----> [LB node]    |
   |  private .10/24    private .11  |
   |   [app] [app]      [app] [app]  |
   |  data    .20/24    data   .21   |
   |   [DB primary] ->  [DB standby] |
   +---------------------------------+

The moving parts that connect it

Common mistakes

• Putting everything in one zone and calling it highly available. Symptom: the whole product goes down in a zone event while the status page of the provider says only "one zone affected".
• Making the database publicly reachable "just for now". Symptom: a flood of login attempts in the database logs within hours. Put it in a data subnet and reach it through the application tier or a controlled admin path.
• Choosing overlapping address ranges. Symptom: a later VPN or peering connection cannot be created, or traffic goes to the wrong network, forcing a rebuild. Reserve distinct ranges per environment and per site.
• Opening the firewall to everyone on a management port. Symptom: remote-administration ports receiving attacks from the whole internet. Restrict by source or use a managed access path.
• Ignoring cross-zone and cross-region data charges. Chatty services spread across zones or regions can generate a bill nobody budgeted for.

How this shows up in real projects and interviews

Questions here are often "how would you make this service survive a data-centre failure?" and "explain a public versus a private subnet". The expected answer: two or more zones behind a load balancer, stateless application servers, a database with a standby in another zone, and a network layout where only the load balancer is internet-facing. In real projects the network is usually defined once in infrastructure-as-code and then rarely touched, so the cost of a wrong address plan arrives months later. Spend an hour on it up front, and when you want hands-on practice with one provider's version of it, move on to AWS Fundamentals.