How AWS Is Built: Understanding Regions, AZs, and Edge Locations

Before exploring AWS services like IAM, EC2, or S3, it’s essential to grasp where the application or resources we intend to host will reside and how AWS ensures they remain resilient and accessible to users around the globe. AWS is designed to maintain your application’s operation even when parts of the system experience failures—that’s fault tolerance. As business demands grow, the application should expand seamlessly without concerns about the underlying hardware—that’s scalability. AWS enables users to enjoy quick response times—that’s low latency. Additionally, it must adhere to various countries' data protection regulations—that’s compliance. These objectives are fundamental, and AWS is constructed around them. Let’s take a closer look at how AWS's worldwide infrastructure accomplishes these aims.

🌍 Regions - Why multiple regions?

A Region refers to a geographical area, like Mumbai or Frankfurt, where AWS establishes its infrastructure. Companies choose regions based on various factors, including their specific needs and regulatory requirements (for example, data must be stored within the EU) as well as performance considerations. Since I am located in Germany, many local companies opt for eu-central-1 (the Frankfurt region) to maintain GDPR compliance. Think of AWS regions like how Amazon Prime Video offers different films and series depending on the user's country. A viewer situated in Germany might have access to a wider selection compared to a viewer in Bharat. The main reason behind this variation is that content licensing and regulations vary by region, so Amazon must control what is available in each specific area.

However, compliance isn't the only factor; latency is also essential. Users need to access the necessary resources and services with minimal delay. Picture a scenario where your users are in Mumbai, but your services are based in Frankfurt. The user request must traverse halfway across the globe and back again. Real-time applications, such as multiplayer games and video conferencing, can face considerable delays in such situations. Choosing the nearest region reduces latency and enhances the application's speed.

The cost of running instances varies by region. For example, using an EC2 instance in Frankfurt may incur higher expenses compared to Mumbai or Ohio. Therefore, if compliance and latency are not issues—such as when handling backend tasks or temporary jobs—you may want to select a less expensive region to reduce costs.

🏢 Availability Zones - Why not one but many?

In every AWS Region, there are Availability Zones, which are essentially data centres located within the same region designed to operate independently. Why not have just one per region? Because systems can fail, disks can malfunction, and power outages can occur. If your application is hosted in a single AZ, your services will be down. However, deploying your application across multiple Availability Zones enhances its fault tolerance. Therefore, it is essential to consider deploying in more than one Availability Zone before launching any app or service.

All the availability zones are connected with low-latency, high-throughput links. Although they are physically separate, they need to talk to each other very quickly. Consider a scenario where your database is located in one Availability Zone (AZ) while your application server resides in another. If the connection between these zones is slow (high latency), your application may exhibit sluggish behaviour. If the connection experiences a bottleneck (low throughput), you would face challenges in replicating or syncing data effectively.

However, with AWS, you can:

• Distribute resources across multiple AZs for added fault tolerance.

• Maintain database replication in near real-time.

• Horizontally scale applications without concerns about inter-AZ performance.

• As a result, you achieve resilience without sacrificing performance.

🌐 Edge Locations – Why We Need Content Near Users?

Edge locations are small AWS data centres positioned closer to users, serving as a caching layer. Even if your application is hosted in an ideal region, a user located far from the data centre may still experience delays; edge locations help mitigate this issue. For instance, when a user in Berlin accesses your website, content such as images or videos is fetched from a nearby edge location instead of Frankfurt. This enhances the speed and responsiveness of your application on a global scale. Services like Amazon CloudFront and Route 53 typically utilise edge locations.

Local Zones

Local Zones are essentially smaller versions of Regions situated near heavily populated urban areas. They are beneficial for use cases that demand extremely low latency, such as video editing or online gaming. Although they may not be necessary for every initiative, being aware of their existence can be advantageous when designing solutions where minimising delay is crucial.

By grasping these principles, I was able to comprehend how AWS embodies the essential cloud ideals of scalability, reliability, and performance.

In my next post, I will explore AWS's Shared Responsibility Model, detailing your responsibilities as well as what AWS takes care of. Understanding this concept is crucial for comprehending services like IAM and for effectively securing cloud environments.