特定の地域の顧客にサービスを提供するのに最適なAWSの場所をどのように判断できますか？

Question 1

AWSには、さまざまな価格で実行できるストレージとEC2インスタンスの場所がいくつかあります。特定の地域に最適な場所を特定するにはどうすればよいですか。直感的ですか（サービス提供地域に近い方が最適です）、信頼性の懸念がありますか（特定のAWSの場所が他の場所よりも多くの停止に直面しています）。そのような決定を下すために利用できるデータはありますか？

私は主にインドの顧客を対象としたアプリケーションを開発しています。そこで、シンガポールか東京を選択肢として考えています。

Question 2

カスタム使用のための最小遅延AWSロケーションの決定

TurnKey Linuxの賢く革新的な人々は、最近、問題の解決策をオープンソース化しました。GitHubの AWSリージョナルデータセンターのマッピングを参照してください。

このプロジェクトは、TurnKey Hubがユーザーに最も近いAWSデータセンターを見つけるために使用するインデックス（および参照用のビジュアルマップ）を生成するために使用されます。[私の強調]

使用されているアルゴリズムの詳細については、GeoIPとインデックスを使用した最も近いデータセンターの検索と、GeoIPとインデックスを使用した最も近いAPTパッケージアーカイブの検索のフォローアップ投稿を参照してください。

ちょっとした仕掛けですが、視覚化は非常にクールで、それぞれを確認します。Joshがすでに述べた驚くべき事実の理由を示しています。つまり、オーストラリアのユーザーは現在、アジア太平洋（シンガポール/ ap-southeast）ではなくUS West（北カリフォルニア/ us-west-1）を経由する方がレイテンシーが高くなる傾向があります。 -1）地域。（ヒント：右下隅にあるFuture Cablesを確認すると、これが変更される可能性が高いことがわかります。これについては、Gregのケーブルマップで詳しく説明されています。これは、オーストラリアが今後数年間で両方のAWSロケーション間を遅延的にジャンプする可能性があることを示しています;）

Amazon Route53を介して自動的に最小レイテンシのAWSロケーションを使用する

一方、AWSは、アベイラビリティーゾーンの数やAPIエンドポイントなどのそれぞれの詳細とともに、迅速な評価のためにグローバルインフラストラクチャを示す有用なマップを提供しています。

さらに重要なことはいえ、AWSはちょうどJahufarは、地理的なDNSのサポートを発表しました言及すでにを、入門記事を参照AWSのためのマルチリージョンレイテンシーベースルーティングは、現在利用可能な、権力同じレイテンシーベースルーティング技術を利用できるようにされたアマゾンCloudFrontののユーザーにアマゾンEC2、Elastic LoadBalancingなど。

そのため、環境がすでにAuto Scaling EC2インスタンスアーキテクチャで構成されている場合は、このレイテンシベースのルーティングを適用するだけで問題が自動的に解決されます。

ユースケースは明らかに複数のAWSリージョンを生成するオファリングを対象としていますが、レイテンシーベースのルーティングと加重ラウンドロビンレコードセットに関する高度な機能により、必要な情報を自分でも簡単に決定できる場合があります。

Question 3

試してみてください cloudping.infoをお

ブラウザから各AWSリージョンへのHTTPpingを実行します。

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

SO管理者への注意：私はこのサービスと提携していません。AWS認定の準備中に見つけました。

Question 4

速度テスト用のWebサイトもあります：https：//cloudharmony.com/speedtestどの地域が自分に最適かを簡単に確認したい場合。

Question 5

最も近いawsリージョンを表示するコンソールツールは次のとおりです。

https://github.com/ekalinin/awsping

それはgolangで書かれていて、とても使いやすいです：

➥ ./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

リージョンはレイテンシー順に並べられています。

任意のサーバーで実行して、最も近いリージョンを決定できます。

Question 6

異なるリージョンへのレイテンシーをテストすることは明らかにお勧めです！私はオーストラリアに住んでおり、ここの多くのユーザーは、シンガポールよりも米国西部への待ち時間が長くなっています。これは、ローカルISPのピアリングと国際接続に起因する部分もあります。ターゲットとする地域にユーザーがいるかどうかをテストするのは比較的簡単です。

AWS側の信頼性（つまり、ユーザーネットワークの問題ではない）は、ほとんどの場合、複数のアベイラビリティーゾーンに展開した結果です。米国の地域では、APACの地域よりも多くの選択肢があります。これは、それらの市場に長くサービスを提供しているからです。これの副作用は、機能がシンガポール/東京に比較的遅れて展開されることです-通常、新しい機能は米国東部で展開を開始します。

使用したいサービスとしてS3とEC2をすでに念頭に置いており、どちらもより近い地域で利用できるため、AWSの新しいウェブサービスがすぐに重要かどうかを評価します。そうでない場合は、近くで何か（レイテンシー）を探します。

Question 7

Amazonは現在、最小のエンドユーザーレイテンシに基づいてデータセンターにルーティングする機能を提供しています。これはRoute53の新しい「レイテンシーベースのルーティング」です！

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

Question 8

私たちの場所からレイテンシーをチェックするための良いツール/サイト

http://www.cloudwatch.in/

Question 9

編集：マークツァイの答えを見てください。それが進むべき道です（私がこれを書いたとき、Route 53は存在しませんでした）

これはおそらくServerFaultに属していますが、ここにあります。

基本的に求めているのはGeoDNSです。

現在、AWSでは直接サポートされていません-AWSフォーラムの投稿で実装されているという話をいくつか見ましたが-おそらくRoute53サービスで。

それまでは、GeoDNS機能を提供するZerigoなどのサードパーティソリューションを検討することができました。

または、ハードコアの場合は、IP2LocationでBINDを構成することで自分でロールすることができます

編集：GeoDNSプロバイダーについて説明しているServerFaultに関する投稿があります

パフォーマンスとAWSの信頼性に関する質問については、サイトを最も近いAZからユーザーに提供することを検討する必要があります。速度の観点からは完全に理にかなっており、すべてのインスタンスを1つのAZに配置する必要はありません。AWS Service Health Dashboardをチェックして、AmazonのサービスがさまざまなAZでどの程度信頼できるかについての一般的なアイデアを得ることができます。このデータはAmazonから直接のものであることに注意してください-私は他のどこにも独立した統計を見たことがありません。

Question 10

http://blog.datapath.io/aws-network-latency-mapでは、この情報を取得するための商用サービスについて説明しています。指定した場所から指定したAWSサービスまでの待ち時間が地図上に表示されます。