Como posso determinar qual local da AWS é melhor para atender clientes de uma determinada região?

A AWS tem vários locais de armazenamento e instâncias EC2 para execução com preços diferentes. Como posso determinar qual local é o melhor para uma determinada região. É intuitivo (mais perto de sua região de serviço é o melhor) ou há alguma preocupação com a confiabilidade (local específico da AWS enfrentando mais interrupções do que outros). Existem dados disponíveis para a tomada dessa decisão?

Estou desenvolvendo um aplicativo voltado principalmente para clientes indianos. Portanto, estou considerando Cingapura ou Tóquio como uma opção.

Determinar a localização AWS de menor latência para uso personalizado

O pessoal inteligente e inovador da TurnKey Linux recentemente abriu o código-fonte da solução para o seu problema, consulte Mapeamento de data centers regionais da AWS no GitHub:

Este projeto é usado para gerar os índices (e mapa visual para referência) usados ​​pelo TurnKey Hub para encontrar o data center da AWS mais próximo para um usuário. [ênfase minha]

O algoritmo em uso é mais detalhado em Encontrar o data center mais próximo usando GeoIP e indexação , bem como na postagem de acompanhamento Encontrar o arquivo de pacote APT mais próximo usando GeoIP e indexação .

Embora seja um truque, a visualização é muito legal e confirma a resp. ilustra a razão para o fato surpreendente à primeira vista que Josh já mencionou , ou seja, que os usuários na Austrália atualmente tendem a obter melhor latência via oeste dos EUA (norte da Califórnia / us-west-1) em vez do Pacífico Asiático (Singapura / ap-sudeste -1) região. ( Dica : verificar os cabos do futuro no canto inferior direito revela que isso provavelmente vai mudar, o que é mais detalhado no mapa de cabos de Greg , que indica que a Austrália pode pular entre os dois locais da AWS em termos de latência nos próximos anos;)

Usando localização AWS de latência mais baixa automaticamente via Amazon Route 53

Enquanto isso, a AWS está fornecendo um mapa útil que ilustra sua infraestrutura global para uma avaliação rápida, juntamente com os respectivos detalhes, como, por exemplo, o número de zonas de disponibilidade e o endpoint da API.

Mais importante, porém, a AWS acaba de anunciar o suporte DNS geográfico que Jahufar já mencionou , consulte o post introdutório Roteamento baseado em latência multirregional agora disponível para AWS , que está disponibilizando a mesma tecnologia de roteamento baseada em latência que capacita o Amazon CloudFront para usuários do Amazon EC2 , Elastic Load Balancing e muito mais.

Portanto, caso seu ambiente já seja composto de uma arquitetura de instâncias EC2 do Auto Scaling, a simples aplicação desse roteamento baseado em latência resolverá seu problema automaticamente.

Embora o caso de uso obviamente vise ofertas que geram várias regiões da AWS, os recursos sofisticados em torno do roteamento baseado em latência e conjuntos de registros de rodízio ponderado podem permitir que você mesmo determine as informações desejadas com mais facilidade.

Experimente cloudping.info

Ele fará ping HTTP de seu navegador para cada região da AWS.

Region  Latency
US-East (Virginia)  28 ms
US-West (California)    100 ms
US-West (Oregon)    110 ms
Europe (Ireland)    100 ms
Europe (Frankfurt)  119 ms
Asia Pacific (Singapore)    269 ms
Asia Pacific (Sydney)   239 ms
Asia Pacific (Japan)    209 ms
South America (Brazil)  147 ms

NOTA para administradores de SO : não sou afiliado a este serviço. Eu descobri enquanto me preparava para a certificação da AWS.

Há também um site para teste de velocidade: https://cloudharmony.com/speedtest se você quiser verificar facilmente qual região é melhor para você.

Esta é uma ferramenta de console que mostra a região aws mais próxima:

• https://github.com/ekalinin/awsping

É escrito em golang e muito fácil de usar:

➥ ./awsping --verbose 1
      Code            Region                                      Latency
    0 eu-central-1    Europe (Frankfurt)                         36.97 ms
    1 eu-west-1       Europe (Ireland)                           63.18 ms
    2 us-east-1       US-East (Virginia)                        126.52 ms
    3 ap-south-1      Asia Pacific (Mumbai)                     156.98 ms
    4 us-west-1       US-West (California)                      192.92 ms
    5 us-west-2       US-West (Oregon)                          226.23 ms
    6 sa-east-1       South America (São Paulo)                 247.74 ms
    7 ap-northeast-1  Asia Pacific (Tokyo)                      312.22 ms
    8 ap-northeast-2  Asia Pacific (Seoul)                      329.54 ms
    9 ap-southeast-2  Asia Pacific (Sydney)                     337.84 ms
   10 ap-southeast-1  Asia Pacific (Singapore)                  395.73 ms

As regiões são ordenadas pela latência.

Você pode executá-lo em qualquer servidor e determinar a região mais próxima para você.

Testar a latência em diferentes regiões é obviamente aconselhável! Estou localizado na Austrália e muitos usuários aqui obtêm melhor latência para o oeste dos EUA do que para Cingapura - em parte, isso se resume ao peering de ISPs locais e conectividade internacional. É relativamente simples testar se você tem usuários na região de destino.

A confiabilidade do lado da AWS (ou seja, não problemas de rede do usuário) é principalmente uma consequência da implantação em várias zonas de disponibilidade. Existem mais opções nas regiões dos Estados Unidos do que nas regiões APAC, simplesmente porque atendem a esses mercados há mais tempo. Um efeito colateral disso é que os recursos são implantados relativamente tarde em Cingapura / Tóquio - normalmente, os novos recursos começam a ser implantados no Leste dos EUA.

Como você já tem o S3 e o EC2 em mente como serviços que gostaria de usar e ambos estão disponíveis em regiões mais próximas, avalie se os serviços da Web mais novos da AWS são imediatamente importantes - se não, busque algo (latência) por perto.

A Amazon agora oferece a capacidade de rotear para um datacenter com base na menor latência do usuário final. É o novo "Roteamento baseado em latência" do Route53!

http://docs.amazonwebservices.com/Route53/latest/DeveloperGuide/CreatingLatencyRRSets.html

Boa ferramenta / site para verificar a latência de nossa localização

http://www.cloudwatch.in/

EDIT: Veja a resposta de Mark Tsai. Esse é o caminho a percorrer (Route 53 não existia quando eu escrevi este)

Provavelmente pertence ao ServerFault, mas aqui vai:

O que você basicamente está pedindo é Geo DNS.

No momento, não há suporte direto na AWS - embora eu tenha visto algumas conversas sobre isso sendo implementado em algumas postagens do fórum da AWS - muito provavelmente em seu serviço Route 53 .

Até então, você poderia olhar para soluções de terceiros, como Zerigo, que forneceria a facilidade Geo DNS.

Ou se você for hardcore, você pode fazer o seu próprio configurando BIND com IP2Location

EDIT: Há um post no ServerFault que fala sobre os provedores de Geo DNS

Quanto à sua pergunta sobre desempenho e confiabilidade da AWS: Você deve considerar servir seu site do AZ mais próximo ao seu usuário - faz todo o sentido em termos de velocidade e não ter todas as suas instâncias em um único AZ. Você pode verificar o AWS Service Health Dashboard para ter uma ideia geral de como os serviços da Amazon são confiáveis ​​em diferentes AZs. Observe que esses dados são diretamente da Amazon - não vi nenhuma estatística independente em nenhum outro lugar.

http://blog.datapath.io/aws-network-latency-map discute uma oferta comercial para obter essas informações. Ele mostra o tempo de latência do local que você especifica até o serviço AWS que você especifica em um mapa.