シンガポールのAWSt3.microが、バングラデシュのバージニア州北部のt2.nanoよりも応答が遅いのはなぜですか？
t2.nanoインスタンスを北バージニアのアベイラビリティーゾーン（us-east-1）でほぼ1年間実行しています。
レイテンシーを削減するために、そのインスタンスの作成されたAMIをシンガポール（t3.micro）ゾーンのap-southeast-1インスタンスにデプロイしました。インスタンスのApacheサーバーに接続されたRDS（AZ：us-east-1）があります。
しかし、t3.micro（シンガポール）は、4倍以上離れた場所（バングラデシュ、ダッカ）からの古いt2.nano（米国バージニア州）よりも応答が遅くなっています。
遅さの証拠として、 GoogleのPagespeed サイトは古いサーバーと新しいサーバーをそれぞれ100と71としてランク付けし、 Pingdom は2つのサーバーをそれぞれ100と81としてランク付けします＆ GTmetrix これらをそれぞれ100と79としてランク付けします。 2つのサイトのGTmetrix比較のスクリーンショット： 
EDIT：ランクは、不均衡なリクエストを使用して誤って生成されましたが、次のスクリーンショットは、t3.microの待機時間が本当に長いことを示しています。インスタンス： 
このサーバーは、他の多くのREST API（Webフロントエンドとモバイルアプリの両方でLaravelフレームワークを使用して開発）をホストします。これらはすべて、長い遅延を反映しています。
このシステムではこれ以上構成を使用していません。他のすべての構成（セキュリティグループ、AMI、IAM、RDS、S3など）は両方のインスタンスでまったく同じです。
RDS接続がさらに数ミリ秒の遅延（およびおそらくキャッシュによる遅延）が発生する可能性があることは理解していますが、平均で10秒を超える遅延は耐えられないと感じています。
そのような違いが発生する可能性があり、これを回避するためにさらに何をすべきですか？
これら2つのインスタンスが提供するページは同じではありません。
合計ページサイズは150倍大きい（386kB対2.8kB）であり、リクエスト数は8倍大きい（17対2）。
まず、2つのセットアップを調整して、実際のインスタンスのパフォーマンスを確認するよりも、同じ方法でページを提供するようにします。
また、DBを別のリージョンに配置しても効果はありません。通常のWebサイトでは、かなり多くのDBクエリが作成される可能性があり、各クエリで0.5秒程度のレイテンシが追加されると、すぐに追加されます。
そして最後に、T2およびT3インスタンスはいわゆるCPUクレジットを使用します-それらが使い果たされると、パフォーマンスは急速に低下します。たとえば、パフォーマンステストを直後に行った可能性があります。ソフトウェアをインストールするか、クレジットを使い切る。その場合、パフォーマンスは非常に悪くなります。さらにクレジットを蓄積して再試行するために、しばらく時間を取ってください。
お役に立てば幸いです:)