IaaSプロバイダはどうやってマーケットを広げるのか？ PaaSレイヤを提供するのは簡単だが、そうすると顧客にはロックインされるという懸念が持ち上がる。顧客が管理の主導権を持てるというIaaSの利点でを維持したまま、どうやってPaaSの利点である、熟練を要する運用業務を顧客から不要にする、ということを提供できるだろうか

その答えは運用を容易にするツールの提供だ。それはIaaS上に用意された、優れた（ベストプラクティスな）インフラで、可用性とスケールを実現するものだ。

これがまさにAWS Elastic BeanstalkがTomcatを用いて行ったことである。

IaaSとPaaSの違いはなくなろうとしている － Publickey

個人的にはベンダロックインよりも、運用がどれだけ容易になるかが最大の関心事だったりする。
運用にもスケールするかどうかが含まれていると考えています。

昨今のWEBサービス開発は、php等のスクリプト言語で作るのがあたりまえです。
初期の開発者の単価が抑えられ、ホスティングサービス等を利用しやすいから。

で、幸運にもWEBサービスが流行ったら、フロントエンドのWEBアプリケーションも色々と性能改善をしつつ機能追加とかするのも大事ですけれど、ある程度の規模を超えるとストレージのレイヤ（データベース側）でがんばってスケールさせる必要が出てくる訳で、ミドルウェア含むインフラ層にもエンジニアを惜しみなく投入して、あの手この手で分散化する必要が出てきます。

最近は知りませんが少なくとも私の知る限り、php は Apache等のhttpデーモン のプロセスまたはスレッドにくっついて動く訳でして、永続的接続とかいう仕組みは有っても、アプリケーション全体でDBコネクションの数を制御したり、プーリングしたり、使いまわしたり、データベースアクセス専門のオブジェクト(DAO)をこさえて使いまわす、なんて事が簡単には出来ない訳でして、そこはもう Java Servlet の方が1階層タンデムな分そこのへんの作りこみが楽だから、ある程度の規模までならデータベースアクセスの観点からパフォーマンス面で有利だと思う訳でして、私がWEBアプリケーションとしてはマイナーな Java を選ぶ理由の1つです。

TCP/IPのコネクションを張るのはそこそこリソースを消費する訳だから、php でApacheのプロセス（スレッド）上減数に合せてコネクションを貼りっぱなし、なんて構成を最初はとったりする訳ですが、RDBMSサーバ側のリソースも結構ふんだんに用意する必要がありますし、規模が大きくなってくると、最近は安くなったとはいえスケールアップさせるのはソコソコ金がかかるんで、水平に垂直に分割したりレプリケートさせたりキャッシュしたりインフラ層でイロイロやらないといけないんで、安定させて性能を出すにはそれなりのコツというか、DBAなんていう職業が成立してしまう位イロイロな匠の技がある訳ですし、24時間365日運用するには、やはり訓練もドキュメンテーションもそれなりに必要になってきます。

で、最初の「運用がどれだけ容易になるか」の話ですが、こういう「インフラ系エンジニア」の下働きは、それなりに優秀な人材を集めなければいけないしコストがかかります。WEBサービスもマネタイズできないと単なるボランティアですからやはり収益性は大事な訳です。

誤解を恐れずに言うならば、インフラ系エンジニアは「システムの能力を最大限に引き出し（必要に応じて向上させて）たり、セキュリティ含むITをとりまくあらゆるリスクを軽減する為にイロイロとがんばる」訳ですが、それで収入が増えるとか言う事は無い、と考えられる事が多いわけです。特に経営層に。

これらはだんだんとコモディティ化してきているから、もし外注できるなら、どうせ金かけるなら優秀なソフトウェアエンジニアを中に雇いたい訳です。サービスをより良くするスピードこそ、競争力であり、収入を増やす為に必要だからです。

こういう事を書くと世の中のインフラ系のエンジニアの方を敵に回しそうなんで一応書いておきますが、価値を生むとか生まんとか以前に情報システムは運用してナンボ、作るだけじゃダメな訳で、運用管理も誰でも簡単に出来る訳じゃないです。Salesforceの様に、運用こそ差別化の最大要因だと言い切ってしまいたい所です。

さらにさまざまな問題を回避する事で、問題が発生した場合に損失しうる企業価値を損なわずにすむという面もありますんで、一概に要らないと言っている訳では無くて、AmazonやGoogleとかが、規模の原理を活かして、自社の優秀なエンジニアと運用のベストプラクティスを、IaaSやPaaSで提供しはじめている訳ですから、少なくともWEBサービスにおいては、ストレージ層も含めて「スケールする」インフラがセットで提供されはじめた今、「事業」として考えた場合、「外注」されやすい分野である事は間違いないでしょう。

要るとか要らないとか言う以前に、土俵というか、世の中のルールというかが変わって来たぞ、と。

そういう観点で、Google App Engine と AWS Elastic Beanstalk を比べると、App Engineの方が楽そうなんだよなぁ。
でも、既存システムの移行の難易度で言うと、格段にBeanstalkの方が楽そうだなぁ。
App Engineの方がスケールしそうだしなぁ。でもAWSの方が自由度高いしなぁ。

と、これからは、クラウドをコーディネートする力が求められそうですね。
纏まりなくてすいません。

SEOとデザインは今後より密接になる理由 : could

良い記事。
WEBサイトもSEOもコンテンツありき、ですね。
そしてソーシャルメディアの場合は、コンテンツ≒人 ですね。

サイト（コンテンツ）を作る前に考えるべきこと

• Webサイトにおけるビジネスゴールは何か？
• なぜ Web サイトが必要なのか？
• 誰に向けてコンテンツを配信したいか？
• 利用者に提供したいコンテンツは何か？
• 利用者が欲していると感じるコンテンツは何か？
• どのように利用者のもつ問題を解決するのか？

ゆっくりと確実に変化するWeb制作のルール | 住 太陽のブログ

言っちゃった。
WEBサービスがコモディティ化してるのに、それでも独自ドメインでイチからWEBサイトを製作するのは不誠実だ、と。

私が受託開発に未来は無いと思った一番の理由が、「ソフトウェアエンジニアは、車輪を再開発したがる」でした。
少し業務要件を変えてでも、パッケージとかオープンソースとか有りものを活用した方がイイと判っていても、工数ほしいからイチから作っちゃう。
今はウェブサービスを活用した方がクライアントの為だと本心では思っても、自分達が食べる為にはオーダーメードのシステムを作り続けないといけない。
その構造と一緒ですね。

今は無料or格安でブログを立ち上げられるし、Twitter と Facebook がある。
極端な話、大手のWEBサービスを使わないとしても、その3つで事足りてしまう気がする。
今年あたり、Facebookファンページ上にECサイトを作る、という案件が急増しそうな予感。

X. プロモーションする対象のサービス

A. 最大限のマーケットの大きさ。つまりは全体でターゲットになるユーザが何人いるか。
B. Xをしらないユーザ
C. Xをしっているユーザ
D. Xをしっていて興味をもたなかったユーザ

当然ながら、A=B+C+Dとなる。そして僕はプロモーションをするときにB,C,Dの比率がそれによってどう変化するかを考える。

特に長期的な戦略を考える場合には重要視するモデルだ。

このモデルのパラメータに実際にユーザになった数がはいっていないのも、僕的には重要なポイントだが、まあいい。あとで説明する。

で、この場合のプロモーションでベストな基本戦略は以下のとおりだ。

戦略１．　Bはできるだけ減らさない。

戦略２．　Bが減った分、CとDが増えるが、できるだけCを増やして、Dは増えないようにする。

↑これが効果のないプロモーションはマイナスのプロモーションになる理由だ。

マイナスのプロモーション – はてなポイント３万を使い切るまで死なない日記

すごく良い記事。
プロモーションに関して言えば、「やらないよりやった方がマシ」では無く、「やらない方がマシ」が存在すると言う話。

IANAによるIPv4アドレスの配布が事実上終了 － Publickey

Geekなぺーじ : IPv4アドレス枯渇。その意味と恐らくこれから起きること

ついにきた。

私がまだネットワークエンジニアのつもりだった頃IPv6を学んだのはもう10年以上前の様な気がする。KAME projectで踊るカメが見えたとか見えなかったとか。
その当時は数年もすれば国策としてのIPv6が普及してIPv4は消えていくんだろうと思ってたけど、IPv4はNAPTを駆使してしぶとく生き残ってきた。

JPNICで枯渇するのも時間の問題です。
いよいよ悠長な事言ってられなくなってきた訳です。
新規でWEBサービス立ち上げるハードルが上がっちゃうじゃねーかコンチクショー！な人もいるかも知れませんが、そこはクラウドがあるじゃないですか。

あのテレビCMを見てGALAPAGOS（ガラパゴス）に飛びつく程度に、ITに詳しくない人たちが、果たして自宅の無線LAN構築から、GALAPAGOS（ガラパゴス）をWiFi端末として認識させるところまで、すんなりとできるだろうか。
SHARP、GALAPAGOS（ガラパゴス）の哀れをもよおすテレビCM: 愛と苦悩の日記

GALAPAGOSに関する至極最もな疑問。
誰に売るのか？この製品は誰を喜ばすものなのか？
一見、GALAPAGOSの戦略にはグランドデザインが欠如している様にも思えるけど、GALAPAGOSメディアタブレットには明確な意思が込められている気がする。

キャリアに依存しない収益構造の模索、だ。
模索してるから、製品設計のコンセプトもプロモーションもなんか的を射てなかったり、ブレてる。
そう考えると、生暖かい目で見守る気にもなってくる。

私はiPadユーザだけど日本人だから、建設的な意見も述べてみます。
GALAPAGOS は ePub3 がスタンダードになる前に、つまり2011年中に、利用者にとってXMDFが如何に優れているか徹底的にプロモーションし、端末をディスカウントしてでもシェアを伸ばすべきだ。今はそれ以外、無い。
1万円台だったら、私も買います。

ブラウザでChromeを使ってる人はCtrl+Shift+Jを押せばHttpヘッダー情報見れます
Google App EngineではAdmin権限でリクエストするとCPU使用率と1リクエストあたりの課金額がわかる – あおうさ＠日記

知らなかった！

Ctrl + Shift + J でDevelopper Tools起動 -> [Resources]タブ選択 -> 左ペイン[RESOURCES]からHTML本体をクリック -> 右で[Headers]タブ選択

でHTTP Responseヘッダが見られます。

	X-AppEngine-Estimated-CPM-US-Dollars:
	X-AppEngine-Resource-Usage:

がソレです。便利。

Amazonクラウド、Oracle 11gのデータベースサービスを発表。パッチ適用やバックアップなど運用は全部クラウドにおまかせ － Publickey

AWS Elastic Beanstalkもそうだけど、いよいよエンタープライズ分野を攻略する気マンマンなAmazon様が、Oracleも用意して下さる。
これは良いニュースだ。
ORACLEマスター涙目。

サイトに設置した「いいね!」の押され具合をデータで解析する方法 | Web担当者Forum

自サイトに設置したFacebook「イイね！」ボタンがどれ位押されたかを見るには、Facebookインサイトを使えば出来る。Facebook用のタグが正しく記述されているかはURLリンターを使う。

昨年度の電波利用料収入は642億円。これは一般会計だが、実質的にはすべて総務省が使える隠れ特別会計になっている。来年度の総務省のICT予算が約1200億円だから、その半分以上の隠し財源を持っているのだ。
池田信夫 blog : 電波利用料という「隠れ特別会計」 – ライブドアブログ

総務省が周波数オークションを見送った理由は電波利用料が隠し財源になっているから、だそうです。
いやぁ、許せませんな。

Androidスマートフォンのシェアが全世界1位に、iPhoneもSymbian OSも抜き去る – GIGAZINE

全世界でAndroidスマホのシェアが1位になったそうです。
日本は？

キングジムのEvernote対応メモ（ショットノート）がもうすぐ出ますよ | goryugo, addicted to Evernote

これは・・・
iPhoneに取り込む為の紙。
iPhoneアプリと組み合わせると、その紙のタイトル欄と日付欄がOCRで読み込まれるみたい。
そしてEvernoteに投稿できるらしい。

Amazonクラウドから、1時間あたり約1.8円（Linux/Unixの場合＄0.02、Windowsで$0.03、1ドル90円で計算）、24時間で約43円、1カ月で約1300円という低価格のインスタンス「Micro Instance」（マイクロインスタンス）が発表されました。
…
マイクロインスタンスで提供される仮想マシンの性能は、613MBメモリ、一時的に最大2EC2 Compute Unitsとなっており、通常の性能としては「少しのCPUリソースが提供される」という表現にとどまっています（英語版のMicro Instancesの解説より）。

つまり、ふだんは大した性能を提供しないけど、負荷が高まったら少しの間だけ大目に見ましょう。という感じのインスタンスのようです。
Amazonクラウドから「1円クラウド」（自称）登場。Amazonクラウドの値下げが続く － Publickey

格安ホスティング業界にはなかなかのインパクトがある話だと思いますが、それを利用したり代理店をしたりする事が多いWEB製作業にとっては良い話じゃないですかね。

ミドルウェアを構築しなければいけないとか、何も考えずインスタンスを落としちゃうとデータが消えるとか、非技術系のWEB製作会社とかにはまだまだ敷居が高いですが、構築された仮想サーバを流用するなり、一度作ってしまうなりすればWEBサーバ環境が量産できるわけだし、静的なHTMLだけならデータが消えてもデプロイしなおせばよいだけだし。

セキュアに運用するコツさえつかめれば、小規模なWEBサーバのホスティングでもAmazon EC2が有力な選択肢になるんじゃないでしょうか。

■ストレージ容量
無償は1GBまで。
コンテンツ、画像、DBでだいたい50GB位と仮定。

$0.005 x 50GB x 30日 = $7.5 / 月

■ネットワーク帯域
無償は、上り、下り それぞれ 10GB /日まで。
下りの 1日当たりのデータ転送量は、仮に4GB/日と仮定すると・・・
要らんやん。

上りはもっと少ないから、当然無償だな。

■CPU時間
無償は 6.5時間 / 日 まで。
以降、 $0.10 / 時間

これは読めないなぁ。
色々遊んでみて、感覚を掴むしかないか。

とりあえず、20時間として、

13.5時間 * $0.1 * 30 = $40.5

■メール送受信数
2000件 / 日 までは無料。

週3回、32000通のメルマガを発行したとして、

30000 * $0.0001 * 3 * 4 = $36 / 月

これが一番高くつきそうやん。
それでも4000円以下だから、メールサーバのホスティングとか管理とか考えたら安いモノだけど、
大量のメール送信を伴うアプリケーションは、別途ホスティング等を考えた方がいいかもしれない。

■合計

・ストレージ $7.5

・ネットワーク帯域 Free

・CPU時間 $40.5

・メール送受信 $36

計 $84.0

Amazon Web Services (EC2) で、同じ条件で脳内試算したときは、$185.1 だったから、半額以下になる。
しかもGAEの場合は、サービス立ち上がり当初 ～ 一定規模までは、無償な訳だから、圧倒的にコストメリットが高い。

GAEって素敵。

EBSはAmazon EC2用の外付けHDDみたいなものです。

利用料金

仮想ディスク容量： $0.10 / 1GB

リクエスト(I/O) ： $0.10 / 100万I/Oリクエスト

ボリューム作成

ボリュームを作るのは至極簡単です。

Firefox の add-on ElasticfoxElasticFoxや、Amazon Web Services Management Consoleからも出来るけど、漢はだまって Amazon EC2 API Toolsで。

アタッチしたいインスタンスを確認して、

ec2-describe-instances

#———————————————————————

INSTANCE i-5354173a ami-2dd03644 ec2-174-129-135-179.compute-1.amazonaws.com domU-12-31-39-02-B0-23.compute-1.internal running my-keypair 0 m1.small 2009-05-28T03:49:31+0000 us-east-1b aki-9b00e5f2 monitoring-disabled

#———————————————————————

インスタンスと同一のゾーンに、ボリュームを作成します。とりあえず5GBで。

ec2-create-volume -z us-east-1b -s 5

作成したボリュームを確認する。

ec2-describe-volumes

#———————————————————————

VOLUME vol-3057ba59 5 us-east-1b creating 2009-05-28T04:14:11+0000

#———————————————————————

インスタンスにアタッチする

ec2-attach-volume -d /dev/sdc -i i-5354173a vol-3057ba59

先日作成したAMIを起動する。

ec2-run-instances ami-2dd03644 -k my-keypair

SSHで接続する

ssh -v -i my-keypair root@ec2-174-129-135-179.compute-1.amazonaws.com

アタッチしたボリュームを確認する

ls -laF /mnt/sd*

ファイルシステムを作成

アタッチしたボリュームに、ファイルシステムを作成します。ext3で。

yes | mkfs -t ext3 /dev/sdc

マウントします。

mkdir /Share

mount /dev/sdc /Share

完了です。

df -k

#———————————————————————

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/sda1 10321208 1195504 8601416 13% /

none 870472 0 870472 0% /dev/shm

/dev/sdc 5160576 141444 4756988 3% /Share

#———————————————————————

Amazon EC2を試してみたので、そのメモです。

環境構築とAMI起動、S3に保存までです。

クレジットカード片手に、Amazon EC2の申し込みをします。

全部英語ですが、そんなに難しくありません。

http://aws.amazon.com/ec2/

:JREがインストール済みである事が前提です。

http://www.java.com/ja/

:[Amazon EC2 API Tools]をダウンロード

http://developer.amazonwebservices.com/connect/entry.jspa?categoryID=88&externalID=351

:ダウンロードした[Amazon EC2 API Tools]を解凍

:解凍したフォルダをリネーム

c:\ec2-api

:CMD.exe起動

md c:\ec2

Amazon EC2よりキーファイルを、c

\ec2にダウンロード

https://aws-portal.amazon.com/gp/aws/developer/account/index.html

:環境変数をセット

set JAVA_HOME=C:\Program Files\Java\jre6

set EC2_PRIVATE_KEY=c:\ec2\pk-XXXXXXXXXX2DPN437UDKN2F2GINZRI.pem

set EC2_CERT=c:\ec2\cert-XXXXXXXXXX2DPN437UDKN2F2GINZRI.pem

set EC2_HOME=c:\ec2-api

set PATH=%PATH%;%EC2_HOME%\bin;%JAVA_HOME%\bin

:バージョン確認

ec2ver

:Amazon EC2への接続確認 ( AMIのリストが表示されれば成功 )

ec2-describe-images -o amazon

ec2-describe-images -x all

:起動させるインスタンスにSSH接続するためのKeypair作成

ec2-add-keypair my-keypair

:AMIを起動

ec2-run-instances ami-7254b01b -k my-keypair

:インスタンスのステータス確認

ec2-describe-instances

#——————————————————————–

RESERVATION r-5dac3534 027383474356 default

INSTANCE i-b589f2dc ami-7254b01b ec2-67-202-21-253.compute-1.amazonaws.com domU-12-31-38-00-25-E7.c

ompute-1.internal running my-keypair 0 m1.small 2009-05-20T11:03:38+0000 us-east-

1c aki-9b00e5f2 monitoring-disabled

#——————————————————————–

:パーミッション設定

ec2-authorize default -p 22

ec2-authorize default -p 80

ssh -v -i my-keypair root@ec2-67-202-21-253.compute-1.amazonaws.com

:全インスタンスのステータス確認

ec2-describe-instances

#——————————————————————–

RESERVATION r-9dbd24f4 027383474356 default

INSTANCE i-c3a0dbaa ami-7254b01b terminated my-keypair 0 m1.small 2009-05-20T08:37:41+0000 aki-9b00e5f2 monitoring-disabled

RESERVATION r-bbbe27d2 027383474356 default

INSTANCE i-71a4df18 ami-7254b01b pending my-keypair 0 m1.small 2009-05-20T09:00:15+0000 us-east-1c aki-9b00e5f2 monitoring-disabled

#——————————————————————–

AMI作成

:インスタンスに「X.509証明書」を転送

scp -i my-keypair *.pem root@ec2-67-202-21-253.compute-1.amazonaws.com:/mnt

:AMIを作成

ssh -v -i my-keypair root@ec2-67-202-21-253.compute-1.amazonaws.com

ec2-bundle-vol -d /mnt –privatekey pk-XXXXXXXXXX2DPN437UDKN2F2GINZRI.pem –cert cert-XXXXXXXXXX2DPN437UDKN2F2GINZRI.pem –user 0273-8347-4356 –fstab /etc/fstab

Please specify a value for arch [i386]:

で i386 [Enter]

:AMIをS3に保存

ec2-upload-bundle –bucket slowaim –manifest image.manifest.xml –access-key XXXXXXXXXXXXXX –secret-key XXXXXXXXXXXXXXXXX

:AMIの登録

ec2-register slowaim/image.manifest.xml –cert cert-XXXXXXXXXX2DPN437UDKN2F2GINZRI.pem –private-key pk-XXXXXXXXXX2DPN437UDKN2F2GINZRI.pem

IMAGE ami-2ff11746

:Ownerが自分のAMIの確認

ec2-describe-images -o self –private-key pk-XXXXXXXXXX2DPN437UDKN2F2GINZRI.pem –cert cert-XXXXXXXXXX2DPN437UDKN2F2GINZRI.pem

IMAGE ami-2ff11746 slowaim/image.manifest.xml 027383474356 available private i386 machinea ki-9b00e5f2

:既存インスタンスの停止

ec2-terminate-instances i-c3a0dbaa

:作成したAMIからインスタンスを起動

ec2-run-instances ami-2ff11746 -k my-keypair

:AMI確認

ec2-describe-instances

INSTANCE i-6b81fa02 ami-2ff11746 ec2-174-129-119-73.compute-1.amazonaws.com domU-12-31-38-00-8C-D6.c

ompute-1.internal running my-keypair 0 m1.small 2009-05-20T11:38:11+0000 us-east-

1c aki-9b00e5f2 monitoring-disabled

:SSH接続

ssh -v -i my-keypair root@ec2-174-129-119-73.compute-1.amazonaws.com

:既存インスタンスの停止

ec2-terminate-instances i-6b81fa02

:一応、登録したAMIの削除方法

ec2-deregister AMIのID

:もういっかい、インスタンスの保存をする

scp -i my-keypair *.pem root@ec2-174-129-119-73.compute-1.amazonaws.com:/mnt

cd /mnt

ec2-bundle-vol -d /mnt –privatekey pk-XXXXXXXXXX2DPN437UDKN2F2GINZRI.pem –cert cert-XXXXXXXXXX2DPN437UDKN2F2GINZRI.pem –user 0273-8347-4356 –fstab /etc/fstab

ec2-upload-bundle –bucket slowaim –manifest image.manifest.xml –access-key XXXXXXXXXXXXXXX –secret-key XXXXXXXXXXXXXXX

EC2にアカウントを作成する。

Amazon Elastic Compute Cloud (Amazon EC2)

http://aws.amazon.com/ec2/

Amazon Web Services ポータル

https://aws-portal.amazon.com/gp/aws/developer/account/index.html?ie=UTF8&action=activity-summary

Firefoxのアドオンをインストール( EC2 と S3 )

Elasticfox (Firefox Extension for Amazon EC2)

http://developer.amazonwebservices.com/connect/entry.jspa?externalID=609

S3FOX (Firefox Extension for Amazon S3)

http://www.s3fox.net/

:[Amazon EC2 API Tools]をダウンロード

http://developer.amazonwebservices.com/connect/entry.jspa?categoryID=88&externalID=351

人によっては、JREをインストールする必要があるかもしれない。 http://www.java.com/ja/

これも人によっては必要なのがSSH。Windowsの場合は、取りあえずCygwinで。

http://cygwin.com/

GUIが大好きな人は、puttyよりもPoderosaがお勧め。

http://ja.poderosa.org/

書籍でまとまった形で読みたい場合は、下記がお勧め。

技術的な部分はかなり噛み砕いて書かれています。

また、読み物としても、面白く読めるように工夫してあります。

Amazon EC2/S3クラウド入門

posted with amazlet at 09.05.20

学びing
秀和システム
売り上げランキング: 5781

おすすめ度の平均:

入門書です
Amazonを使ってクラウドビジネスを始めたいと思う人におすすめ
情報収集が面倒な方にはちょうどよいです
すぐに試したい人におすすめ
先進ユーザーによる実例本

Amazon.co.jp で詳細を見る

仮のWEBシステムを、脳内でAmazon EC2に移行してみる。

■EC2 インスタンス

次の3つから選択する。Smallで充分。

Small　1.7GB / 1CPU / 160GB HDD / 32bit　($0.1/時間）

Large　7.5GB / 2CPU / 850GB HDD / 64bit　($0.4/時間）

Extra Large　15GB / 4CPU / 1690GB / 64bit　($0.8/時間）

■EC2 データ転送料

次の通り。

$0.1/GB（受信）

$0.18/GB（送信）※ 最初の10TB/月まで

$0.16/GB（送信）※ 次の40TB/月まで

$0.13/GB（送信）※ それ以上

1日当たりのデータ転送量は、仮に4GB/日として、30日で120GB

■S3

ストレージとしてS3を利用した場合、

保存は最初の50TBまで、1GBあたり$0.15。

$0.150 per GB – first 50 TB / month of storage used

$0.140 per GB – next 50 TB / month of storage used

$0.130 per GB – next 400 TB /month of storage used

$0.120 per GB – storage used / month over 500 TB

コンテンツ、画像、DBでだいたい50GB位と仮定。

■S3のデータ転送

2009年6月30日までは1GBあたり$0.03。7月1日以降は1GBあたり$0.1。

■合計

・Webサーバ1台 $0.1(/h)×24h×30day=$72

・DBサーバ1台 $0.1(/h)×24h×30day=$72

・EC2転送料 120GB×$0.18/GB=$21.6

・S3利用料　　$0.15(GB)×50GB=$7.5

・S3転送料 120GB×$0.1/GB=$12.0

計 $185.1

サーバを5、6台追加して、8台構成になったとしても、$600～$1000位、10万円以下でいける計算になる。

これを国内のホスティングサービスで実現しようとすると、監視やら色々ついているので

単純比較は出来ないけど、どんなに安くても30万は下らないと思う。