比較した結果に関して載せてみます。変更した場合の結果に関しても記載します。テスト回数をそれほどこなしていないのである程度のブレはある可能性がありますが、移行を検討する場合の参考にはなるかと思います。計測した環境を以下に示します。100クライアントが同時アクセスした場合を想定したテストになります。テスト計画は以下のような感じで作成。シナリオに沿ったリクエストではなく、適当にサンプリングしたページにリクエストを投げ続けるというテストになっています。20000テストするインスタンスは、他からのリクエストの影響等を受けないように、テスト用のインスタンスを別に立ててテストを行っています。Purpose))比較表スループットの比較表は以下になります。比率(%)はt1.microを100(%)とした場合の値です。モニタした結果も示します。CPU使用率が100%になっていたのが、t2.microにおいては少なくとも現状はそうなる事がなくなったようです。CPUがバースト可能となった事が影響しているものと思われます。移行する事でパフォーマンスも向上する結果となりました。なった事の方が効いてくる気がします。結果からわかるように、JavaのGCの影響でCPU使用率が上昇しスローダウンが発生しているような環境では、t2インスタンスに変更するメリットはより大きいといえるでしょう。この辺りはバースト可能である点も活きているものと思われます。EC2インスタンスにも当たり・外れがあるご存知かとは思いますが、AWSではインスタンスにも当たり・外れがあります。除外したので、ある程度妥当な比較結果になっているのではないかと思うのですが、こういった要因に左右される事も踏まえて参考にして頂ければと思います。クラウドも所詮物理サーバの集合なので、古い世代のコンピュータに当たってしまった場合には、最新世代のコンピュータが割り当てられた場合に比べてパフォーマンスが落ちてしまうといった事があるようです。/proc/cpuinfoとしてCPU情報を確認し、サーバの世代を確認。繰り返すという手も考えられますが、最新CPUだったものが古い世代に戻ってしまう事も考えられます。適当なところでの妥協は必要でしょう。インスタンスを作り直すメリット時間が経過する事で旧世代のサーバは徐々に新世代のサーバに置き換っていきます。現状実行中のインスタンスが大分前に起動したものであれば、インスタンスを作り直す事で(今よりも)新世代の物理サーバ上で実行される可能性は高くなると考えて間違いないでしょう。今までは考えた事がなかったのですが、今回のパフォーマンス検証を行う上でこの点に関して改めて気づかされました。インスタンスを作り直す作業をスケジュール化するという事も、パフォーマンスを改善するための有効な手段となりうるかもしれません。古いCPUに割り当てられる可能性もありますが、確率としては逆になる可能性が高いですし、そうならなくとも動きの早いクラウドの世界、色々と気づく事もあるのではないかと思います。今回のような新たなインスタンスタイプの提供といったイベントは、パフォーマンスを検討するよい機会になるのではないかと思います。移行に限らず、利用している環境を見直してみてはいかがでしょうか。