用途は、S3 上のデータから動的コンテンツを提供することです。あなたが正常だと思う「正常」の定義を作ることができます。
小規模、中規模、大規模のインスタンスはどうですか?
Ok。人々はいくつかのデータを操作したいので、ここに：
Web サービスは開始時に約 100kb で、AJAX を使用するため、ページ全体をリロードする必要はありません。ページが読み込まれると、データベース (S3) に 20 ～ 30 のリクエストが送信され、テキストの小さなチャンク (コメントなど) が取得されます。平均的なユーザーは 10 分間ページにとどまり、オフセットで約 100kb、リクエストによってさらに約 400kb に変換されます。ヒット量は昼と夜で同じとします。
ユーザーがコンテンツにアクセスする頻度、コンテンツのサイズとタイプなどは言うまでもなく、何をどのようにコンテンツを提供しているかによって異なります。意味のある方法で質問に答えてください。
他の人が言ったように、これには正確な条件下でのテストが必要になる場合があります。幸いなことに、サーバー セットアップのテスト バージョンを設定するところまで進んでいる場合は、ユーザーをシミュレートするインスタンスを生成できます。これらのテスト インスタンスの束を作成し、それらに対して Apache の ab ベンチマーク ツールを実行して、テスト サイトに誘導します。インスタンスがテスト サイトと同じアベイラビリティ ゾーン内にある場合、帯域幅に対して課金されることはなく、実行中のインスタンスの時間単位でのみ課金されます。1 時間以内にテストを実行し、後でテスト インスタンスをシャットダウンすると、このストレス テストを構成するための費用はほとんどかかりません。
1 つのデータ ポイントとして、データベースが重い Drupal サイトを提供している私の小さなインスタンスでローカルに Apache ab ツールを実行すると、サーバーが 1 秒あたり 45 ～ 60 のリクエストを処理できることが報告されました。私は ab がベンチマークのための合理的なツールであると想定しています。間違っているかもしれませんが、これが私が見ているものです。
提案として、あなたの特定のケースについてあまり知らないので、あなたのデータベースをエラスティック ブロック ストア (EBS) ボリュームに移動することをお勧めします。S3 は実際にはデータベースをホストすることを意図しておらず、レイテンシーによってパフォーマンスが低下する可能性があります。EBS ボリュームは、バックアップのために S3 に簡単にスナップショットできます。
適切に設計されていれば、インスタンスがサポートできるユーザーの数は関係ありません。理想的には、インスタンスが飽和状態になったら、トラフィックを管理するために新しいインスタンスを起動します。
明らかに、これは展開と設計を非常に複雑にします。
しかし、それを超えて、EC2インスタンスは効果的にローエンドのLinuxボックスになります（選択したモデルによって異なります）。
質問を言い換えてみましょう。何人のユーザーをサポートしますか？