Zen CartやMovable Type、WordPressなどCMSでサイト構築をする際に、Amazon Web Services（アマゾンウェブサービス：以降AWS）を利用するケースが増えてきました。
AWSのようなクラウド環境を利用するメリットの一つとして、コストをあまりかけずにスケールアウトできる点があげられると思います。
スケールアウトとは、有名ニュースサイトに記事が載った際など大量のアクセスがあった時に自動的に新しいEC2インスタンスを作って、負荷分散ができるようにする仕組みです。
逆に、アクセスが落ち着いてきて自動的に作ったEC2インスタンスを削除するのがスケールインです。
このように自動的にインスタンスを制御することを「Auto Scaling」といいます。
どの時点を「大量のアクセス」と判断してスケールアウトするか...というルールはAWS上のCloudWatchを利用して設定します。
また、スケールアウト中は 2つ（以上）のインスタンスにユーザーからのアクセスを割り振る必要がありますが、このロードバランサーの役割はAWS上の管理画面でELB（Elastic Load Balancing）の設定しておけば勝手にやってくれます。
スケールアウト/スケールインするためには、どの時点を「高負荷状態」なのかを判断するルールをCloudWatch上で設定します。
Elastic Load Balancer: 10種の事前選択されたメトリックス（1分間隔）。無料。
を利用するので費用は掛かりません。
ルールは規模によると思いますが、例えば下記のように設定します。
ただし、ひとつ注意が必要なのは、スケールアウトが必要になってから実際に使えるようになるまでタイムラグがあります(5分など) 。よって、多少余裕をみたルール設定が必要になります。
さて、Auto Scaling でサーバーの台数が増減するような環境では、http://www.example.jp/ へのアクセスが複数台のサーバーで処理される場合が出てきます。
すると、以下のような問題が起きることがあります。
管理者がCMSにログインし、コンテンツを news/hoge.html という静的ファイルとして保存しようとしたらエラーになった！
エラーになった原因は、管理者さんの作業中にスケールアウトして、ファイル保存前にスケールインが起きたため、というわけです。CMSのバグ？ と推測してしまった場合は原因究明でえらいことになりそうですね。
上記の解決方法としては、CMSへのアクセスは常にメインとなるEC2（Ａ）にアクセスするように設定すれば、Auto Scaling による影響は出なくなります。
具体的には、以下のようなDNS設定をします。
また、Auto Scaling の設定は下記のようにしておきます。
このように、Auto Scaling の設定をしておけば、サーバーダウンを避ける仕組みが構築できます。
では、このサーバー構成のための費用はだいたいどれくらいでしょうか。AWSではアクセスによる転送量や、サーバーに配置するコンテンツ容量など、環境によって金額が異なる従量課金制ですので、費用計算は難しいのですが、概算を出してみます。
想定：
EC2 (東京リージョンを想定）
L Web用にミディアム
L DB 用にスモール
Elastic IP （設定済みで費用なし）
CloudWatch （Auto Scalingをするのに必要だけど無料の範囲内で利用）
Auto Scaling
L スケールアウトで起動するインスタンスは
毎日2時間ほど3インスタンスがコンスタントにあがる想定
その他 （EBS, S3）
転送量などは適当に10GB/月
これで、一ヵ月$250?$300 程度でしょうか。ただし、上記の計算はバックアップ体制などは除外しているので、あくまで概算だと思ってください。