Eu ia postar a solução com o HAProxy, o que eu acho que dei como uma resposta aqui antes (embora uma pesquisa não tenha aparecido).
Isso (ou algo semelhante, você também pode usar verniz ou nginx) será a única abordagem viável, dada a limitação do namespace global do aplicativo Heroku, já que nenhum serviço DNS pode fazer o que você está querendo - as reescritas do cabeçalho do host não podem ser realizado com configuração de DNS sozinho. O pedido terá que passar por um sistema de algum tipo que possa reescrever o cabeçalho em vôo.
No entanto, você só precisaria de um proxy, não dois. Aqui está o porquê:
Se o nome do host for myapp.example.com , configure a implementação US Heroku para simplesmente esperar esse nome de host.
Em seguida, não configure a implantação da UE para esperar um nome de host personalizado; você estará usando o nome de host não vaidade myapp-eu.herokuapp.com .
O Route 53 seria configurado para retornar o terminal Heroku como a resposta para as consultas dos EUA e o ponto de extremidade do proxy para solicitações da UE. O proxy iria reescrever o cabeçalho do host para myapp-eu.herokuapp.com e enviar a solicitação para o terminal Heroku EU, mas as solicitações dos EUA iriam diretamente para o terminal Heroku US, que esperaria o nome do host que o cliente já está usando.
Você também pode evitar o proxy e usar o CloudFront como proxy. Observe que esta solução só funciona com 2 destinos - EUA e UE neste caso - devido às restrições de configuração globais do CloudFront (somente 1 distribuição do CloudFront pode ser configurada para um determinado nome de host de entrada) ... mas para essa solução, 1 é tudo que precisamos. Um destino (US) usa uma conexão direta e não requer nenhuma reescrita, enquanto o outro destino (EU) faz proxy através do CloudFront e obtém uma reescrita.
Crie uma distribuição do CloudFront. Configure-o para esperar pedidos para myapp.example.com . Configure-o para usar o hostname de terminal da UE Heroku não vaidade, myapp-eu.herokuapp.com como seu servidor de origem personalizado e não configure-o para colocar na lista de permissões o cabeçalho Host da solicitação original. Coloque na lista quaisquer outros cabeçalhos que você precise. Opcionalmente, desative o cache. Em seguida, o CloudFront reescreverá o Host: do cabeçalho de myapp.example.com para o nome de host configurado do servidor Origin, que seria o ponto final da UE.
Então, como antes, configure o Route 53 para retornar o endpoint US Heroku CNAME para solicitações de locais que devem ir para o endpoint dos EUA, mas para retornar o% CNFER% CNAME para solicitações de locais que devem ir para o endpoint da UE .
De qualquer forma, você pagará pelo transporte do tráfego enviado para o terminal que passa pelo proxy ou pelo CloudFront; portanto, talvez você queira usá-lo para o terminal que espera ver a menor quantidade de tráfego. .. então você pode querer transpor a UE e os EUA nos exemplos acima, que arbitrariamente assumem que EUA veriam mais tráfego, por isso ele é encaminhado diretamente.
Nenhuma dessas soluções deve adicionar um tempo significativo de ida e volta às solicitações. Se você seguir a rota do proxy, é provável que você descubra que uma máquina muito pequena, como a t2.micro ou a t2.nano, pode manipular mais tráfego do que o esperado, já que o processamento é mínimo.