Skip to main content

AWS Infrastructure: Regions, AZs, and Edge Locations

Aws image

Region​

  • A geographic location, like North America or Europe, where AWS has its data centers. Each region is isolated from the others, meaning your data in one region stays within that region unless you move it.
  • Example: In AWS, the Mumbai region is called Asia Pacific (Mumbai) and serves as the geographic area where AWS has its data centers located in and around Mumbai, India.

Edge locations​

Edge locations in AWS are data centers that are part of the Amazon CloudFront content delivery network (CDN). They are designed to deliver content (like web pages, videos, or other static and dynamic files) to users with low latency by caching it closer to them, which is commonly used by services like Hotstar.

  • Content Distribution: Since the new series will have the same content for all viewers, Hotstar can store that content in edge locations closer to users
  • Reduced Latency: By caching the content at these edge locations, Hotstar can deliver it more quickly to viewers, as data doesn't have to travel as far from the origin server.
  • Improved Performance: This setup minimizes buffering and loading times, leading to a better viewing experience.
Aws image

So, using edge locations to cache commonly accessed content is an effective strategy for improving performance and reducing latency in streaming services.

Availability Zone (AZ)​

  • A smaller part within a region. It's a physically separate data center with its own power, networking, and cooling. AWS usually has multiple AZs in each region, allowing you to spread out resources to avoid downtime if one AZ has an issue.

  • Within the Mumbai region, there are several Availability Zones (AZs). These AZs are separate data centers within the region, providing redundancy and higher availability. For example:

    1. Mumbai (ap-south-1a)
    2. Mumbai (ap-south-1b)
    3. Mumbai (ap-south-1c)

  • ap-south-1 is the region. In this case, it's Mumbai in AWS terminology. ap-south-1a, ap-south-1b, and ap-south-1c are the Availability Zones (AZs) within that Mumbai region.

In simple terms, regions are big, and availability zones are the parts inside them.

Aws image

Why Availability Zones Matter for Your Applications?​

Data is not automatically replicated between AWS Availability Zones (AZs). You need to set up replication yourself depending on the service you're using. Here's how it works:

For some services (like Amazon S3 or DynamoDB), replication across AZs happens automatically. These services are designed to store your data redundantly across multiple AZs within the same region to ensure high availability and durability.

For other services (like EC2 or RDS), you have to manually configure replication if you want your data to be available across multiple AZs. For example:

  • In EC2 (virtual servers), if you want to ensure high availability, you need to launch instances in multiple AZs.
  • In RDS (databases), you can enable Multi-AZ deployments, which replicate your data across AZs for disaster recovery.

Data transfer within the same AZ is free, but between AZs, there's a small charge. If your EC2 instances in different AZs are communicating with each other frequently, you'll incur additional data transfer costs.

Overall, running EC2 instances across multiple AZs gives you higher availability and fault tolerance, but it does come with increased costs due to the extra instances, possible data transfer charges, and supporting resources.

The main purpose of using multiple Availability Zones (AZs) in AWS is to improve the reliability, fault tolerance, and availability of your applications. Here are the key benefits:

  1. Fault Tolerance: Each AZ is a separate, physically isolated data center with its own power, cooling, and networking. If one AZ goes down due to a failure (e.g., hardware failure, power outage, natural disaster), the other AZs can still function. By spreading resources across multiple AZs, you ensure that your application remains available even during disruptions in one AZ.

  2. Load Balancing: With multiple AZs, you can distribute traffic between them using an Elastic Load Balancer (ELB). This improves performance and balances the load on your servers. It also adds redundancy so that if one AZ is experiencing high load or issues, traffic can be automatically redirected to another AZ.

  3. Disaster Recovery: By using multiple AZs, you create a backup plan in case of a disaster. If a disaster strikes one AZ, your data and resources in another AZ can keep your application running smoothly, helping you recover faster and minimizing data loss.

  4. High Availability: Deploying your application in multiple AZs ensures that it's highly available. If one AZ becomes unavailable, traffic can be routed to instances in other AZs, ensuring minimal downtime. This is essential for mission-critical applications where availability is crucial.

  5. Scalability: Running across AZs allows for better scaling. When your application’s traffic grows, you can add instances in multiple AZs to handle increased demand, improving both performance and capacity.