Amazon EC2のユーザコミュニティから 様々な 報告 があり、その中に、大きな内部ネットワーク・レイテンシ（遅延）により、インスタンス（仮想マシン）が、悪いパフォーマンスを被っている、という報告がある。このため、 Amazonの Cloudは、過剰な加入にちがいない、という憶測をよんでいる。
Alan Williamson氏は、Amazon EC2での経験について報告していて、彼の会社が試したすべてのクラウド提供者と同様に、Amazonも 当初は、規模的にうまく適応していたようだが、転換点がある:
Amazonは、初期は素晴らしかった。インスタンスは、数分で立ち上がり、ほとんど問題がなかった、そして SMALL INSTANCE でさえMySQLデータベースを適度に使うには、十分な能力を持っていた。まるまる２０ヶ月間は、Amazonの世界は、順調で、全く心配する必要もなく、苦情もなかった。
...
しかし、この８ヶ月ぐらいで、弱点が見え始めてきた。弱点の最初の兆候は、新規に稼働し始めたAmazon SMALLインスタンスのパフォーマンスで見え始めた。最初、我々は、これらは偶発的な異常で、"騒がしい近所（ネットワーク・トラフィックの高い環境）"にたまたま起きるだけだと思った。ランダムの法則により、即座の終了と新しい立ち上げは、通常、我々が必要なことをやることができた平和な環境に、我々を戻すのである。
...
しかし、この２ヶ月間に、我々は、"High-CPU Medium インスタンス"でもSmallインスタンスと同様な悲運に合っていることに気がついた。新稼働のインスタンスが当然あるべきぐらいのパフォーマンスを出していないようなのである。ある調査により、我々は、新しい問題がAmazonの世界に忍び込んだことを発見したのである：内部ネットワークのレイテンシである。
同じように、 Cloudkickは、大きなネットワーク・レイテンシを示す例を報告している:
数週間前に、我々は、Cloudkickのping遅延グラフが非常に妙に見えるのに気がついた。
...
...EC2を監視しているコンピュータは、Slicehostの４つの異なるサーバをpingしている。平均のping遅延は、至る所に見られる。
...
結論？ EC2の過剰な加入に関する Alan Williamson氏の投稿 は、非常に理にかなっているようだ。EC2の背後にあるネットワークは、非常に散発的な遅延問題を経験しているように見える。
AWSのディスカッション・フォーラムに、EC2の顧客から、ネットワークの問題を経験している、という投稿がこれまでもありました:
今日のCSTで9:15 AMに極めて反応が悪くなり始めたインスタンスが我々のところにあります。時々ログインできましたが、できない時もありました。事態が良くならないので、他のインスタンスを動かしたら同じ問題が起きてしまいました（このインスタンスには、ハードウェアの問題があったと思っていたのですが）。
一度や二度はログインできました。ほんの僅かの間、順調でしたが、その後また、反応しなくなりました。何か見当つきますか？
インスタンスIDが、i-c4921fad と i-a0e3d7c8です。他のEC2のゾーンにあるマシンから我々のマシンに接続しようとしたら、同じようにネットワークの問題に会っています。
Alan氏が報告するには、緊急の時に、 急いで新しいインスタンスをデプロイして、対処しようとしたが、うまくいかなかった:
一つの特別な"消火モード"では、我々は新しいインスタンスを立ち上げて、実際に自分たちのネットワーク・トラフィックに反応するノードを確認して、終了するまでに、文字どおり1時間かかりました。
仮想化された環境、そして特に “騒がしい近所”の場合、すなわち近くのインスタンスがコンピュータ的に重いような環境にあるノードを使っている場合に、この新しいインスタンスを立ち上げる、というのはいいやり方では、ないようである。というのは、 "EC2は、同じ小さな一連のマシンには、新しいインスタンスを割り当てる傾向にあるからである" [PDF]。
クラウド・コンピューティング と Amazon EC2についてもっと知りたければ、まさにこの InfoQを見て欲しい。