Unexpectedly High Bandwidth and Request Volume from far edge server Instead of nearest edge server

Question

We are currently using Amazon CloudFront to serve static files stored in an S3 bucket located in the ap-northeast-2

However, we've noticed that a disproportionately high number of requests — and significant bandwidth charges — are showing up in our billing and usage reports as coming from the ap-southeast-1 (SIN) locations, even though the majority of our users are based in ap-northeast-2

In fact, the number of requests through ap-southeast-1 appears to be almost as high as those from Seoul, despite our actual traffic volume from ap-southeast-1 being minimal.

- Our CloudFront distribution is configured with "All Edge Locations" enabled.
- The origin is correctly configured in ap-northeast-2.

We would like to understand the following:

1. Why are so many requests being routed to the ap-southeast-1 (SIN) instead of ap-northeast-2 edge locations (e.g., ICN)?
2. Is there anything we can do to ensure that ap-northeast-2-based users are served by the nearest ap-northeast-2 locations, to reduce latency and bandwidth charges?

We would greatly appreciate any insights or recommendations to optimize our CloudFront configuration and reduce unnecessary international traffic.

Thank you.

re:Post Agent · Answer

The situation you're experiencing with CloudFront routing a high number of requests to ap-southeast-1 (SIN) instead of ap-northeast-2 (ICN) for your primarily ap-northeast-2 based users is unusual but can happen due to several factors:

1. Edge Location Routing:
CloudFront routes requests to the edge location that can best serve the content based on network conditions and availability, not just geographical proximity. Sometimes, network topology might make a seemingly farther edge location more efficient.

2. DNS Resolution:
The DNS resolution process might be directing users to SIN instead of ICN due to various factors like ISP configurations or temporary network issues.

3. Caching Behavior:
If the content is already cached in SIN and not in ICN, CloudFront might route requests there for better performance.

4. Corporate Networks or VPNs:
If your users are accessing through corporate networks or VPNs, their apparent location might be different from their actual physical location.

To address this issue and optimize your CloudFront configuration:

1. Analyze CloudFront Logs:
Use CloudFront's standard logs to examine the x-edge-location field. This will show which edge locations are serving your content. You can use Amazon Athena to query these logs for detailed insights.

2. Check Real User Metrics:
Use the CloudFront console's "Viewers" report to see where your requests are actually originating from. This can help identify if there's a discrepancy between perceived and actual user locations.

3. Consider Price Class:
If you want to restrict edge locations to reduce costs, you could change your CloudFront distribution's price class. However, this might impact performance for some users.

4. Origin Shield:
Consider using CloudFront Origin Shield in the ap-northeast-2 region. This can help consolidate requests to your origin and potentially improve cache hit ratios.

5. Custom Headers:
You could use custom headers or Lambda@Edge to influence routing decisions, though this should be done cautiously as it might impact performance.

6. Monitor and Adjust:
Continuously monitor your CloudFront usage and performance metrics. If the issue persists, you may need to contact AWS support for a more in-depth investigation.

Remember, CloudFront's global nature means that data transfer charges and request routing don't always align with geographical expectations. The system is designed to optimize content delivery, which can sometimes lead to unexpected, but not necessarily incorrect, routing patterns.

If the issue continues after implementing these suggestions, it would be advisable to reach out to AWS Support for a more detailed analysis of your specific use case and configuration.
      
**Sources**  
[Cloudfront EU-DataTransfer-Out-Bytes cost incurred in unexpected region | AWS re:Post](https://repost.aws/questions/QUwUnUZK3_SC6gmbxgM3IvOg/cloudfront-eu-datatransfer-out-bytes-cost-incurred-in-unexpected-region)  
[Reports & Analytics for CDN Performance | Amazon CloudFront](https://aws.amazon.com/cloudfront/reporting/)  
[How to Determine Request Region and Granular Usage Statistics for Each Client in CloudFront | AWS re:Post](https://repost.aws/questions/QUhcqgxlrHSmO85WqxHIoIrw/how-to-determine-request-region-and-granular-usage-statistics-for-each-client-in-cloudfront)

Unexpectedly High Bandwidth and Request Volume from far edge server Instead of nearest edge server

Relevant content