AWS, Region, Availability Zone and Edge Location

• AWS (Amazon Web Services) – A cloud computing platform that provides on-demand servers, storage, databases, networking, and managed services, all billed by usage instead of upfront hardware purchase.
• Region – A separate geographic area such as Mumbai (ap-south-1) containing multiple isolated data-center clusters, chosen for latency and compliance.
• Availability Zone (AZ) – One or more physically separate data centers inside a Region with independent power, cooling, and networking, connected to other AZs by low-latency links.
• Edge Location – A small CloudFront CDN presence point placed close to end users to cache content and terminate connections with minimal latency.
• Data Sovereignty – Data stays inside a Region unless explicitly copied, which matters for regulatory requirements like RBI data-residency rules in India.

What is AWS?

AWS (Amazon Web Services) is a cloud computing platform that rents out computing resources on demand over the internet. Instead of National Bank of India buying physical servers, waiting weeks for delivery, racking them in a data center, and managing the hardware forever, it calls an AWS API and gets a virtual server in seconds, paying only for the hours it runs. AWS offers over two hundred services including compute (EC2), storage (S3), databases (RDS), networking (VPC), and managed services like Lambda and SQS.

The core value proposition is converting capital expenditure into operational expenditure. A bank does not buy and depreciate servers; it rents capacity and scales it up or down as demand changes.

import software.amazon.awssdk.services.ec2.Ec2Client;
import software.amazon.awssdk.services.ec2.model.RunInstancesRequest;
import software.amazon.awssdk.services.ec2.model.InstanceType;

public class BankServerProvisioning {
    public static void main(String[] args) {
        // Instead of buying hardware, get a server in seconds
        Ec2Client ec2 = Ec2Client.create();
        RunInstancesRequest request = RunInstancesRequest.builder()
                .imageId("ami-0abcd1234")
                .instanceType(InstanceType.M6I_LARGE)
                .minCount(1).maxCount(1)
                .build();
        ec2.runInstances(request);
        System.out.println("Server ready in under a minute");
    }
}

What is a Region?

A Region is a completely isolated geographic area where AWS operates data centers. Each Region has a code name like ap-south-1 for Mumbai or us-east-1 for Virginia. Regions are isolated from each other for two reasons: data sovereignty and fault isolation. Data does not leave a Region unless you explicitly copy it, which matters when RBI requires Indian customer data to stay inside India. A failure in one Region does not affect another.

You select a Region in the SDK like this:

import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.s3.S3Client;

public class RegionSelection {
    public static void main(String[] args) {
        // Keep customer data in India for RBI compliance
        S3Client s3 = S3Client.builder()
                .region(Region.AP_SOUTH_1)   // Mumbai Region
                .build();
        System.out.println("S3 client configured for Mumbai Region");
    }
}

What is an Availability Zone?

An Availability Zone (AZ) is one or more physically separate data centers inside a Region. Each AZ has independent power supplies, cooling systems, and network connections. Every Region has at least three AZs. They are connected to each other by high-bandwidth, low-latency private fiber, so traffic between AZs is fast but each AZ can survive independently if another goes down.

You spread your application across AZs so that if one AZ loses power, the instances in the other AZs continue serving customers. Each AZ has a code like ap-south-1a, ap-south-1b, ap-south-1c.

import software.amazon.awssdk.services.ec2.Ec2Client;
import software.amazon.awssdk.services.ec2.model.DescribeAvailabilityZonesRequest;

public class ListAvailabilityZones {
    public static void main(String[] args) {
        Ec2Client ec2 = Ec2Client.create();
        var response = ec2.describeAvailabilityZones(
                DescribeAvailabilityZonesRequest.builder().build());
        response.availabilityZones().forEach(az ->
                System.out.println(az.zoneName() + " -> " + az.zoneId()));
        // ap-south-1a -> aps1-az1
        // ap-south-1b -> aps1-az3
        // ap-south-1c -> aps1-az2
    }
}

What is an Edge Location?

An Edge Location is a small point of presence that belongs to Amazon CloudFront, the content delivery network. It is placed physically close to end users to cache static content such as statement PDFs, the bank's web assets, images, and JavaScript bundles. When Priya requests her bank statement, CloudFront serves it from the nearest Edge Location in a few milliseconds instead of routing all the way to the Mumbai Region.

There are far more Edge Locations than Regions because their purpose is to be near every customer. Edge Locations also run AWS Global Accelerator and Route 53 DNS.

import software.amazon.awssdk.services.cloudfront.CloudFrontClient;
import software.amazon.awssdk.services.cloudfront.model.ListDistributionsRequest;

public class CloudFrontEdgeSetup {
    public static void main(String[] args) {
        CloudFrontClient cf = CloudFrontClient.create();
        var distributions = cf.listDistributions(
                ListDistributionsRequest.builder().build());
        distributions.distributionList().items().forEach(d ->
                System.out.println("Distribution: " + d.domainName()));
        // Edge Locations worldwide cache statement PDFs close to customers
    }
}

How are Regions, AZs, and Edge Locations related?

These three sit at different levels of scale. A Region is the top level: a geographic area like Mumbai. Inside that Region are multiple Availability Zones: separate data-center buildings with independent infrastructure. Outside and around the Regions are hundreds of Edge Locations: tiny CDN caches placed in cities and towns worldwide.

The relationship is hierarchical for compute and storage (Region contains AZs), but Edge Locations are a separate, much wider distribution network for content delivery.

AWS Global Infrastructure
├── Region: ap-south-1 (Mumbai)
│   ├── AZ: ap-south-1a (aps1-az1) – Data center cluster A
│   ├── AZ: ap-south-1b (aps1-az3) – Data center cluster B
│   └── AZ: ap-south-1c (aps1-az2) – Data center cluster C
├── Region: us-east-1 (Virginia)
│   ├── AZ: us-east-1a
│   ├── AZ: us-east-1b
│   └── ... (6 AZs total)
└── Edge Locations (400+ worldwide)
    ├── Delhi Edge Location
    ├── Chennai Edge Location
    └── ... (near every major city)

How do you choose a Region?

Four factors determine the right Region for a banking workload:

• Latency – Pick the Region closest to your users. For Indian banking customers, Mumbai (ap-south-1) gives the lowest round-trip time.
• Compliance – RBI mandates that Indian customer data stays inside India, so the Mumbai Region is the only compliant choice for primary data.
• Service availability – Not every AWS service launches in every Region on day one. Verify that the services you need are available in your target Region.
• Pricing – Identical services can have different prices across Regions. Mumbai is typically cheaper than Singapore for serving Indian users.

public class RegionSelectionCriteria {
    public enum SelectionFactor {
        LATENCY,      // closest to users
        COMPLIANCE,   // RBI data residency
        SERVICES,     // all required services available
        PRICING       // cost per hour for compute and storage
    }

    public static String chooseBankingRegion() {
        // For National Bank of India:
        // Latency: Mumbai is closest to Indian users
        // Compliance: RBI requires data in India
        // Services: all core services available in ap-south-1
        return "ap-south-1";
    }
}

What are common mistakes with Regions and AZs?

The first common mistake is deploying everything in a single Availability Zone. If that AZ has an outage, the entire banking application goes down. The fix is to spread instances across at least two AZs and use a load balancer.

The second mistake is assuming AZ names are consistent across accounts. My ap-south-1a and your ap-south-1a may map to different physical data centers. AWS randomizes the mapping per account to distribute load. When you need a stable identifier across accounts, use the AZ ID (aps1-az1) instead of the AZ name.

The third mistake is forgetting data transfer costs between AZs. Cross-AZ traffic is not free, so architects must balance high availability against data-transfer charges.

public class AZMistakes {
    // WRONG: single-AZ deployment
    static final String WRONG_SUBNET = "subnet-az-a-only";

    // CORRECT: multi-AZ deployment
    static final String[] CORRECT_SUBNETS = {
            "subnet-az-a",
            "subnet-az-b",
            "subnet-az-c"
    };
    // Use AZ IDs for cross-account coordination, not AZ names
    // aps1-az1 is stable; ap-south-1a is randomized per account
}

What are the limitations?

Regions are not connected by default. To replicate data across Regions you must set it up explicitly, and cross-Region data transfer is expensive. Not every service supports cross-Region replication natively.

Availability Zones within a Region share the same regional control plane, so a Region-wide service disruption can affect all AZs simultaneously, though this is rare. For true disaster recovery a bank needs a multi-Region strategy.

Edge Locations cache content but do not run general compute. You cannot deploy an EC2 instance at an Edge Location. Lambda@Edge and CloudFront Functions allow lightweight compute at the edge, but with strict resource limits.

# Limitation summary
┌──────────────────────┬──────────────────────────────────────────┐
│ Component            │ Limitation                               │
├──────────────────────┼──────────────────────────────────────────┤
│ Region               │ Not connected by default; cross-Region   │
│                      │ transfer is expensive                    │
│ Availability Zone    │ Shares regional control plane; rare but  │
│                      │ possible Region-wide disruptions         │
│ Edge Location        │ Cache only; no general compute (EC2)     │
│                      │ Lambda@Edge has strict resource limits   │
└──────────────────────┴──────────────────────────────────────────┘

What should a senior engineer know?

A senior engineer knows that AZ names are randomized per account and uses AZ IDs for cross-account placement decisions. They understand that multi-AZ is not the same as multi-Region: multi-AZ protects against a single data-center failure, while multi-Region protects against an entire geographic area going down.

They also know that data-transfer costs between AZs and between Regions are a significant part of the AWS bill for a high-traffic banking application, and they design data flows to minimize unnecessary cross-zone traffic. Using a load balancer with cross-zone load balancing enabled distributes traffic evenly but adds cross-AZ charges.

For compliance-sensitive banking workloads, a senior engineer uses AWS Config rules and service control policies to prevent resources from being created outside the approved Region.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyNonMumbaiRegions",
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": "ap-south-1"
      }
    }
  }]
}

What are common interview follow-up questions?

• How do you achieve disaster recovery across Regions? Use cross-Region replication for S3 and RDS read replicas in a secondary Region, with Route 53 failover routing.
• What is the difference between high availability and fault tolerance? High availability means surviving a component failure with brief interruption; fault tolerance means surviving with zero interruption.
• Can you run a single application across multiple Regions? Yes, using Route 53 latency-based or failover routing with identical deployments in each Region.
• What is AWS Local Zone? A Local Zone extends a Region to a specific metro area for single-digit-millisecond latency, useful for real-time trading applications.

public class InterviewFollowUp {
    // DR strategy for National Bank of India
    // Primary: ap-south-1 (Mumbai)
    // Secondary: ap-southeast-1 (Singapore) for DR
    // S3 cross-region replication for statements
    // RDS read replica in Singapore for failover
    // Route 53 failover routing between both
}