AWS Regions and Edge Locations - The Physical Advantage of 33 Regions and 600+ PoPs
We lay out how AWS regions, Availability Zones, and edge locations are structured, and walk through DR design using the Tokyo and Osaka regions, meeting data sovereignty requirements, and running processing at the edge from a practical standpoint.
Cloud Competitiveness Is Determined by Physical Infrastructure
When comparing cloud services, attention tends to focus on feature richness and pricing structures. However, what underpins the cloud at its core is physical infrastructure. Where and how many data centers exist. How widely distributed the network connection points are. This physical placement directly impacts latency, availability, data sovereignty, and disaster recovery. AWS has consistently invested in global infrastructure since its 2006 launch. As of August 2026, it operates 123 Availability Zones (AZs) across 39 geographic regions, and its CloudFront delivery network comprises more than 750 Points of Presence (PoPs) and 15 regional edge caches. That said, the assumptions behind counting such locations differ from provider to provider, so the size of the numbers cannot be read directly as a ranking of superiority. What matters in practice is the substance of the setup: how regions are structured, whether the services you need are available in the region you choose, and how close you can get to your end users.
How Regions and AZs Are Structured - What to Check Before Counting Locations
An AWS region is a unit that groups together multiple AZs. Each AZ is a cluster of data centers with independent power, cooling, and physical security, physically separated by a meaningful distance. AWS documentation explains that all AZs within a region are located within 100 km (60 miles) of one another, and the distinctive point is that they are connected by a dedicated low-latency network despite being apart. This structure makes synchronous replication across AZs workable at practical latencies and lets you absorb the failure of a single data center through design. The same architectural standards apply when new regions open, so an availability design built on AZ distribution can be reused across regions. There are, however, differences to watch for. Even though the AZ structure and design standards are uniform, the services offered vary by region, and new services and features are typically rolled out to major regions first. When deciding on a migration destination or a DR region, always check service availability by region. The same perspective is needed when comparing location counts. How the term region is defined, whether a location always has AZ-equivalent partitions, whether general customers can use it (are government-only or partner-operated sites included?), and whether the services you want to use are offered there. Lining up totals without aligning these four points does not amount to a comparison.
The Setup in Japan - How to Use the Tokyo and Osaka Regions
For users in Japan, what matters is that there are two full regions within the country: the Tokyo Region (ap-northeast-1) and the Osaka Region (ap-northeast-3). The Tokyo Region opened in 2011 and has 4 AZs. The Osaka Region was upgraded to a full region in 2021 and has 3 AZs. Because the two are roughly 400 km apart in a straight line, you can build a DR configuration that stays entirely within Japan even against wide-area disasters that AZ distribution within a single region (within 100 km) cannot absorb. Being able to satisfy a requirement that data must not leave the country while also gaining resilience through geographic separation is possible precisely because there are two full regions in Japan. Local Zones are easy to confuse here. As of August 2026, AWS operates 45 Local Zones, but there are no Local Zones in Japan. The Local Zone whose parent region is ap-northeast-1 (Tokyo) is ap-northeast-1-tpe-1a in Taiwan (Taipei); having Tokyo as the parent region is a separate matter from the site being located in Japan. If you need infrastructure at a specific location within Japan, the options are not Local Zones but AWS Outposts and similar offerings. A practical caveat is that the services offered in the Osaka Region do not fully match those in the Tokyo Region. Before designing a DR configuration, confirm that the services you plan to use on the standby side and the cross-region data replication features (S3 Cross-Region Replication, Aurora Global Database, and so on) are available in Osaka, so you can avoid backtracking.
Edge Location Density - The Last-Mile Battle
If regions are the backend processing foundation, edge locations are the closest touchpoints to end users. As of August 2026, AWS operates more than 750 Points of Presence (PoPs) and 15 regional edge caches as CloudFront's delivery network. Regional edge caches are an intermediate caching layer between the PoPs and the origin; they hold content that does not fit in individual PoPs and reduce round trips to the origin. The denser the edge locations, the shorter the physical distance to end users and the lower the content delivery latency. For workloads where latency directly shapes user experience, such as video streaming, gaming, and e-commerce sites, this difference is pronounced. Furthermore, AWS edge locations go beyond simple CDN caching. Edge computing via Lambda@Edge and CloudFront Functions, DNS resolution via Route 53, DDoS protection via AWS Shield, and application protection via AWS WAF all execute at the edge. Because authentication, redirects, header rewriting, and blocking of attacks can be completed before requests reach the origin, the edge has expanded its role from a "delivery point" to a "point where processing runs." In design terms, how many responses you can make cacheable and how much processing you can push forward to complete at the edge determine both perceived speed and origin load.
Region Selection Freedom and Data Sovereignty
For enterprises using the cloud, which country their data is stored in is a legally and regulatorily critical issue. Regulations that restrict the geographic location of data, such as GDPR, personal information protection laws, and financial regulations, are being strengthened worldwide. AWS regions are independent of one another by default, and data placed in one region is not replicated to another region without the customer's instruction. This principle of "not crossing regions" is the foundation for managing data residency. As of August 2026 there are 39 regions, and Europe has Ireland, Frankfurt, London, Paris, Milan, Stockholm, Spain, Zurich, and others. In addition, Europe now also offers the AWS European Sovereign Cloud (Brandenburg, Germany), which is operated independently within the EU and separately from the standard regions. For even stricter requirements, there are also forms such as Dedicated Local Zones and AWS Outposts that place AWS infrastructure in a specific country or in your own facilities. While the range of options is wide, leaving every usable region open makes management complex. When you need to pin down data location with certainty, the standard approach is to restrict the usable regions themselves with the IAM policy condition key aws:RequestedRegion or with service control policies in AWS Organizations. Data sovereignty is secured not by "having many places to put data" but by "being able to fix where data goes exactly as intended."
Infrastructure Expansion - Track Record and Announced Plans
When selecting a cloud provider, the track record of expansion and the announced plans are decision inputs alongside the current scale of infrastructure. AWS has maintained the practice of announcing new region openings in advance; most recently, the Asia Pacific (Malaysia) Region began operating in 2024, followed in 2025 by the Asia Pacific (Thailand), Mexico, and New Zealand regions. The expansion plans announced as of August 2026 are two regions in Saudi Arabia and Chile, with a combined 7 AZs scheduled to be added. Opening a region involves securing land, arranging power and network connectivity, and complying with local regulations, so it takes years from announcement to launch. Announced plans should therefore be treated as a signal that "options may increase in that geography in the future," and it is safer not to build a migration plan on an assumed opening date. Conversely, the number and distribution of regions already in operation directly represent the range you can choose from today. When making a selection, evaluate announced plans and operating track record separately.
Practical Benefits of the Physical Infrastructure Layout
Here is how the layout of regions and edge locations affects real-world operations. First, latency optimization. Because you can choose regions and edges close to your users, you can physically improve application response times. Second, DR design flexibility. When multiple regions exist within the same country, a geographically distributed DR configuration is possible while maintaining data sovereignty. Third, compliance. You can select a region that meets regulatory requirements and fix data location through policy. Fourth, reuse of designs when expanding. Because region design standards are uniform, an availability design built on AZ distribution can be carried over as is to a new region. Receiving these benefits, however, requires checking the premises. Service availability and quotas differ by region, so list in advance the services you plan to use in the destination and prepare a design that absorbs functional differences from your initial region. In cloud selection and rollout design, it is important to treat the physical infrastructure layout with the same weight as feature comparisons.
Summary
As of August 2026, AWS's global infrastructure has a scale of 39 regions, 123 AZs, and more than 750 edge locations, and its structural characteristics are that region design standards are uniform and that the edge can run processing, not just delivery. Because location counts depend on how they are counted, when comparing, go as far as checking whether a location has AZ-equivalent partitions, whether general customers can use it, and whether the services you need are offered. In the Japanese market, the greatest practical value lies in having two full regions, Tokyo with 4 AZs and Osaka with 3 AZs, roughly 400 km apart, which makes it possible to keep data within the country and prepare for wide-area disasters at the same time. It is also worth remembering that there are no Local Zones in Japan and that the Local Zone with Tokyo as its parent region is in Taiwan (Taipei). In cloud selection, in addition to comparing software features, it is important to evaluate how this physical infrastructure layout fits your own requirements.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- Amazon CloudFront official page
- AWS Global Accelerator official page
- Amazon Route 53 official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.