AWS Asia Pacific three core nodes measured: Hong Kong, Tokyo, Singapore, how to choose the sea business?
As the wave of Chinese companies going out to sea goes deeper and deeper, whether it's cross-border e-commerce, game distribution, SaaS software services, or Web3 and fintech,
AWS (Amazon Web Services)
It is still one of the preferred cloud vendors for infrastructure deployment.
in the asia-pacific region,
Hong Kong (ap-east-1)
,
Tokyo (ap-northeast-1)
and
Singapore (ap-southeast-1)
Is the most classic and most often used to compare the three "golden nodes".
Many architects are often entangled in the selection:
Want to balance domestic and Southeast Asia, choose Hong Kong or Singapore?
How stable is the public network quality of Tokyo nodes when the game is out to Japan?
What is the difference in cross-zone interconnection latency and throughput between the three nodes?
In order to provide a real and objective selection reference for the technical team, we use MTR, Iperf3, Sysbench and other tools to configure the same (EC2
c6i.xlarge
instance, 10Gbps bandwidth limit), the three major nodes of AWS Hong Kong, Tokyo, and Singapore were
Public network latency, cross-regional intranet interconnection, cross-border return routing, and throughput stability
The depth of the measured.
1. Test Environment and Method Description
Test Instance Configuration: AWS EC2 c6i.xlarge(4vCPU / 8GB / Amazon Linux 2023)
Network bandwidth: Up to 12.5 Gbps burst bandwidth, baseline bandwidth guarantee
Test tools: ping / mtr (packet loss and route trace), iperf3(TCP/UDP throughput), curl(HTTP response delay)
Sample distribution of clients: three major operators in mainland China (telecom CN2/163, Unicom 9929/4837, mobile CMI), major Southeast Asian countries (local Tier-1 operators in Indonesia, Vietnam and Thailand) and East Asian countries (mainstream ISP in Japan and South Korea)
2. public network delay and routing link resolution
The network delay directly determines the "first screen loading speed" and "interaction fluency" of the user terminal ". The following are from 72 hours of continuous high frequency ping monitoring
Average Latency vs. Packet Loss Rate
:
1. Public network delay table from each node to the target market (unit: ms)
Target Access Area
Hong Kong Node (ap-east-1)
Tokyo Node (ap-northeast-1)
Singapore Node (ap-southeast-1)
South China (Guangzhou/Shenzhen)
12 - 25
60 - 75
40 - 55
East China (Shanghai/Hangzhou)
35 - 50
35 - 45
65 - 80
North China (Beijing)
45 - 60
55 - 65
80-
95
Japan (Tokyo/Osaka)
45 - 55
5 - 12
65 - 75
South Korea (Seoul)
50 - 65
25 - 35
80 - 90
Singapore Local
35 - 45
65 - 75
3 - 8
Indonesia/Vietnam/Thailand
30 - 45
70 - 90
15 - 30
North America (Los Angeles)
150 - 160
100 - 110
170 - 180
2. Interpretation of the routing characteristics of the three nodes
🇭🇰Hong Kong Node (
ap-east-1
): The closest to mainland China, but the routing strategy is more complex.
Advantages: South China (Guangdong, Fujian, etc.) has extremely low latency to access AWS in Hong Kong, even comparable to domestic inter-provincial access.
Disadvantage: AWS Hong Kong is not a "direct connection line". When public network traffic returns home, telecom usually bypasses NTT or Telstra, while Unicom and mobile depend on the specific return link. During the evening peak period (20:00-23:00), ordinary public network IP will encounter different degrees of congestion and packet loss (about 3% ~ 8%).
Guide to avoid pits: If the core users of the business are in mainland China, it is recommended to use it with AWS Global Accelerator(GA, Global Acceleration) or CloudFront CDN, which can greatly reduce detours and packet loss.
🇯🇵Tokyo Node (
ap-northeast-1
): East Asia Computing Center with extremely stable infrastructure
Advantages: Japan's local network infrastructure is excellent, connecting Japan, South Korea and the west coast of North America (trans-Pacific submarine cable) delay is very advantageous.
Performance of mainland China returning home: East China (Shanghai) and North China (Beijing) are directly connected to Tokyo through China Telecom CN2 or Unicom 4837, with a delay of 35-50ms and a packet loss rate significantly lower than that of ordinary public networks at the evening peak in Hong Kong.
Applicable scenarios: for Japan, South Korea, North America, or need to take into account the business of users in northern China.
🇸🇬Singapore Node (
ap-southeast-1
): Southeast Asia "digital hub", sea basic plate.
Advantages: Radiation across the 10 ASEAN countries (TikTok, Shopee and other platforms in Southeast Asia). The physical latency of the network connecting Indonesia, Malaysia, Thailand, Vietnam and other countries is extremely low.
Mainland return performance: South China visit about 40ms, but North China visit has been close to 100ms. Due to the geographical distance, the physical delay cannot be broken.
Applicable scenarios: Southeast Asia local business, sea India/Middle East front node.
3. AWS internal cross-zone backbone (VPC Peering) testing
In the actual microservice architecture, we often deploy API gateway in Hong Kong, database in Tokyo, and analysis cluster in Singapore.
AWS Inter-Region (Inter-Region)
Backbone network performance
The feasibility of a multi-zone architecture is determined.
We established a secure tunnel through cross-region VPC Peering, and used Iperf3 to test the intranet interconnection performance between the three nodes:
-------------- Cross-Zone Private Backbone (VPC Peering) ------------------
| AWS Hong Kong Node | <===========================================> | AWS Tokyo Node |
| (ap-east-1) | RTT: ~48 ms | (ap-northeast-1) |
------------------------------------
^ ^
| | | | |
|| RTT: ~33 ms || RTT: ~66 ms
\/ \/
---------------------------------------------------------------------------------
| AWS Singapore Node |
| (ap-southeast-1) |
------------------------------------
----------------------------------------- +
Core measured data:
Hong Kong $\leftrightarrow $Singapore: RTT in intranet is about 32.5 ms,TCP single stream throughput can be maintained at 850 Mbps - 1.2 Gbps stably with minimal fluctuation.
Hong Kong $\leftrightarrow $Tokyo: Intranet RTT is about 47.8 ms,TCP bidirectional throughput is excellent, and delay jitter (Jitter) is less than 0.5ms.
Tokyo $\leftrightarrow $Singapore: Intranet RTT is about 65.2 ms. Due to the long distance, a single TCP stream is easily limited by the window size. It is recommended to enable the TCP BBR congestion control algorithm to increase the throughput by more than 40%.
Conclusion: AWS cross-region private backbone network (Backbone) performance is extremely strong, all data go through AWS self-built optical fiber, do not pass through the public network, jitter is close to 0. This provides a solid technical base for "multi-region master and standby" or "cross-region read and write separation.
4. Selection Decision Tree: Hong Kong, Tokyo or Singapore?
Technical parameters aside, standing in
Business landing
perspective, you can choose against the following decision logic:
1. Preferred [AWS Hong Kong] scenario:
Core business: API server for cross-border e-commerce, financial technology, Web3 and overseas enterprises in South China.
Key requirements: requires very low initial latency for mainland China access (provided that CDN/GA acceleration or leased line is configured).
Note: Hong Kong belongs to AWS's Opt-in Region (to be manually opened), and by default the bill unit price (such as EC2 and EBS) is slightly higher than Tokyo and Singapore by 5% ~ 10%.
2. Scenarios with [AWS Tokyo] preferred:
Core business: Japan and South Korea hand travel distribution, for North America and East Asia secondary yuan/entertainment app, high-frequency trading.
Key requirements: High requirements for public network stability and bandwidth quality, and extreme reliance on low-latency synchronization with AWS North American nodes.
Note: In terms of compliance, Japan has strict requirements on data privacy (APPI Act), and attention should be paid to the data exit policy.
3. Preferred [AWS Singapore] scenario:
Core business: Southeast Asia local e-commerce, pan-entertainment live, game out to sea (Singapore service/Southeast Asia region), FinTech.
Key requirements: AWS has the most complete ecosystem in Singapore (e. g. Local Zones, Wavelength) and high integration of third-party SaaS services.
Note: The visit to users in northern China is not very friendly and the delay is high.
3 Practical Advice 5. Optimizing the AWS Asia Pacific Network Experience
No matter what you choose in the end.
The following three architecture optimization strategies can "double" your network performance ":
Fully enable TCP BBR:AWS default Linux kernel uses the Cuban algorithm. Under the transnational high-delay fat pipeline (LFN), the kernel congestion control algorithm is modified to bbr, which can improve the long-distance TCP transmission speed by 30% ~ 200.
Use AWS Global Accelerator (GA): If your users are distributed across Asia Pacific (such as both mainland China and Southeast Asia), you can deploy GA on the front. The user's traffic will directly enter the AWS internal backbone network at the nearest AWS edge Location (edge node) to avoid public network packet loss and route detours.
Rational use of CloudFront for static and dynamic acceleration: CloudFront can not only cache static files, but also its dynamic WebSocket / API acceleration mechanism (by maintaining long connections from edge nodes to source stations) can reduce API's p99 response time by more than 40%.
Summary
In the game of AWS Asia Pacific three nodes:
Hong Kong is better than "near the mainland", Tokyo is better than "high quality and North American connectivity", and Singapore is better than "Southeast Asian radiation"
.
The ideal architecture solution is often not "single choice", but "combination of main and standby". For example:
Singapore as the main data center (database and core business)
, superposition
Edge Acceleration Node in Hong Kong/Tokyo
It can not only take into account the rapid growth of Southeast Asia, but also steadily win the flow dividend of East Asia and China.