By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post

Cloudfront with latency based domain as origin finds wrong region

0

I have a limitation whereby I must run both HTTP and WS through a single TLD, and unfortunately it appears that API gateway requires a separate domain for each protocol as they're separate APIs (correct me if I'm wrong, as that would probably solve the issue).

The way that I've currently implemented it is as follows

messages.foo.com -> cloudfront dist -> origin messages-http.foo.com
messages.foo.com/ws -> cloudfront dist -> behaviour w/ origin messages-ws.foo.com

Both messages-http.foo.com and messages-ws.foo.com are deployed in many regions. The two main ones I'll focus on are af-south-1 and eu-central-1 where I noticed the issue.

If I visit messages-http.foo.com from a machine in af-south-1, latency based routing finds the api gateway/lambda in af-south-1, as expected.

However, if I visit messages.foo.com from the same machine in af-south-1, it finds the api gateway/lambda in eu-central-1.

The api gateways in each region are regional endpoints with custom domains in front, with latency based routing in route 53.

Having read this page about the Cloudfront cache locations in EMEA, it seems to suggest that there are edge locations, but no edge caches in Africa and I wondered if this could be the cause of my issue? By the time the request hits Cloudfront, the closest origin latency wise is now Europe, not Africa?

I'm looking for either alternate solutions to 1 domain->2 api gateways (http & ws), or how to route my traffic properly from Cloudfront to latency based routed domains.

Any suggestions would be much appreciated.

Topics
ServerlessFront-End Web & MobileNetworking & Content Delivery
Tags
ServerlessAmazon API GatewayNetworking & Content DeliveryAmazon CloudFrontAmazon Route 53
Language
English
benswinburne
asked 2 years ago508 views
1 Answer
0

Hi,
I wonder whether you perhaps have a Lambda@Edge function associated with your CloudFront distribution behaviors. If so, it may affect your latency-based routing decisions (as these functions are running in Regional Edge Caches, and not in the edge location (as described in this CloudFront Function announcement: https://aws.amazon.com/blogs/aws/introducing-cloudfront-functions-run-your-code-at-the-edge-with-low-latency-at-any-scale).

Also, you could have a look at the response headers your received from CloudFront, tracing which Edge location actually received your request (you are looking for a response header called X-Amz-Cf-Pop). Perhaps it would help you troubleshooting your routing issue further.

AWS
Tzoori Tamam
answered 2 years ago
  • benswinburne
    2 years ago

    I do have a function running, but I thought I'd accounted for the above- I use a cloudfront function, not a lambda@edge function to rewrite the path of the request from /wss to / (as api gateway ws endpoints must be on the root path, and the behaviour must have a non root path). Given it's a Cloudfront function, should it not be running in Africa at the edge as opposed to the regional cache location?

  • benswinburne
    2 years ago

    The POP being hit when making a request from a machine in Africa is TLV50-C2, Tel-Aviv.

  • benswinburne
    2 years ago

    Having rejigged some configuration, I've removed the need for the cloudfront function completely, so now a request is cloudfront -> behaviour to origin -> custom domain (latency routed) -> regional api gateway. Unfortunately this hasn't changed anything. The pop which handles the cloudfront request is still tel aviv.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions

Relevant content