AWSの「EC2」と「Elastic Beanstalk」の使い方について

Question

御世話になります。
AWSでサーバーを借りて、サービスを提供しようと考えています。
その中で、amazon が提供している「EC2」と「Elastic Beanstalk」について勉強しましたが、自分の解釈が正しいのか不安になり、皆様のご意見を伺いたいと質問させて頂きます。

質問内容としては、「EC2」と「Elastic Beanstalk」の違いについてです。

「EC2」サービスは、仮想サーバーを提供するものだと理解しています。
サーバーを立てるメンテナンスを、amazon 請け負うものだと考えています。
こちらはあくまで開発の場を提供している意味合いが強いと考えています。

「Elastic Beanstalk」は、運用の意味合いが強く、自分で作ったサービスを処理スペックを気にすることなく快適に運用する手助けをしてくれるサービスだと考えています。

しかし、「EC2」にも、スポットインスタンスと呼ばれるサービスがあり、負荷処理が高い場合は、高いインスタンス（処理能力）を分けもらえる設定があり、「Elastic Beanstalk」と似た内容な気がします。

そこで私が「EC2」と「Elastic Beanstalk」の違いについて考えたのが、一からサービスを開発し利用する場合は、「EC2」。スポットインスタンスは、あくまでサービスが動く時の調整だと考えています。
その後、運用する手間を考えた場合（ユーザーがアクセスする場合）に、「Elastic Beanstalk」にお任せするという感じになります。

こちらの解釈で正しいのでしょうか？
それに加え、金額面でどのような違いあるのか、皆様はどのように運用されていいるのか教えて頂けると助かります。

追記：
いろいろな方にアドバイス頂きありがとうございます。
現在、EC2で開発を進め、ユーザアクセスによる対策をスポットインスタンスではなく、ロードバランサという手法で進めたいと考えています。
進め方にアドバイスを頂けたら幸いです。

Answer 1

EC2とEBは比べるものではありません、全く異なります。

「EC2」サービスは、仮想サーバーを提供するものだと理解しています。

これはあってます。

サーバーを立てるメンテナンスを、amazon 請け負うものだと考えています。
こちらはあくまで開発の場を提供している意味合いが強いと考えています。

これは違います。
利用者が自身でインスタンスを起動し、不要になったら破棄します。
そのインスタンスを開発に使うか商用サービスに使うかはAWSには関係ありません。

「Elastic Beanstalk」は、運用の意味合いが強く、自分で作ったサービスを処理スペックを気にすることなく快適に運用する手助けをしてくれるサービスだと考えています。

EBは、一般的なウェブアプリケーションの提供に必要なAWS機能をある程度自動で構成してくれます。
ELB, EC2, RDS, SNS, CloudWatch等。

アプリは開発できるけど、ネットワークやインフラの知識がなくてサービスが立ち上げられない、という人にはいいのではないでしょうか。

メリットはネットワークやインフラの知識がなくてもサービス提供できること、
デメリットはすべて自分でサービスを構築するよりもランニングコストが高くなることでしょうか。

しかし、「EC2」にも、スポットインスタンスと呼ばれるサービスがあり、負荷処理が高い場合は、高いインスタンス（処理能力）を分けもらえる設定があり、「Elastic Beanstalk」と似た内容な気がします。

スポットインスタンスは余剰リソースを安く使うための仕組みで、入札額より低い間はインスタンスを利用できます。
入札額を超えた場合はインスタンスが終了します。
スポットインスタンスはいつ終了するかわからないので、継続的にサービスレベルを維持する必要があるものとは相性がよくないと思います。
ビッグデータ分析をしたいとか、そういうのには向いてるんじゃないですかね。

そこで私が「EC2」と「Elastic Beanstalk」の違いについて考えたのが、一からサービスを開発し利用する場合は、「EC2」。スポットインスタンスは、あくまでサービスが動く時の調整だと考えています。
その後、運用する手間を考えた場合（ユーザーがアクセスする場合）に、「Elastic Beanstalk」にお任せするという感じになります。
こちらの解釈で正しいのでしょうか？

EC2とEBは全く異なるものなので違いとかそういうものではありません、比較できません。

それに加え、金額面でどのような違いあるのか、皆様はどのように運用されていいるのか教えて頂けると助かります。

例えばウェブアプリケーションサーバーとデータベースでスモールスタートする場合、
自身で構築するケース：
EC2インスタンス1つにアプリケーション・サーバーとデータベースを同居

EBで構築するケース：
EC2インスタンス1つ
RDSインスタンス1つ

となり、RDS分の料金が丸っとかかります。簡単に言うとインスタンス2つなので自身でやるよりもコストは倍になります。
1インスタンス2万/月とした場合、年間で24万なのか48万なのかって事です。

Answer 2

ElasticBeanstalkは、EC2などのAWSのサービスを「組み合わせて、1つのシステムとして運用する」ためのサービスです。RailsやPHPといったアプリケーションを、「あとはコードを反映するだけ」という状態になるまで自動でサーバを構築してくれます。

なお、ElasticBeanstalk自体の料金は無料ですが、ElasticBeanstalkで構築されたEC2やRDSなどの料金は通常通り発生します（まとめ買いの分を割り当てることも可能です）。

Comments

[blossan]

例えば、EC2であるサービスを構築し、今後ユーザー向けに発表する際、ユーザーのアクセスによる処理負荷が予想される場合、手動でスポットインスタンスをするよりも、その分のEC2を削除し、ElasticBeanstalkに移行するほうが、インスタンスを効率的に利用できるという解釈でよろしいでしょうか？

[maisumakun]

最初からEC2で組んでしまったのであれば、わざわざElasticBeanstalkに移行するだけの手間をかける価値はないですので、EC2でオートスケールさせる方がいいでしょう。

[pond]

横やりで失礼いたします。

EC2で負荷対策・冗長化する場合、ELB（ロードバランサー）をEC2の前段に配置して、オートスケーリングの設定で、例えば、2台～4台の間でEC2の台数を増減するというような設定をすれば、アクセス増加時に自動でEC2が最大4台までスケールアウトされ、アクセス減少時に自動EC2が最低2台までスケールインする動作をします。但し、コンテンツ・ミドルウェアの設定を変更したら、AMI（Amazon Machine Images）を必ず取得して、オートスケーリングの設定へ反映させることが必須です。（スケールアウトされたEC2はAMIで起動するため。）

ElasticBeanstalk（以降、EB）の場合も前述と同様に負荷・冗長化対策できますが、1点気を付けなければいけないことがあります。EBでEC2・RDSを生成した場合、アプリデプロイ時にこれらが再生成されるのでサービスが停止します。最大で5分ほど掛った記憶があります。Apacheの再起動にかかる時間というレベルでないです。
また、データベースが消えてしまわないようにEB画面でなくRDS画面で生成する等の工夫が必要になりますのでご注意ください。確かに5分ほどのオペレーションでアプリケーション実行環境を作れるのはメリットであると思うのですが、個人的にEBにはいい思い出がありません。

ご参考までに宜しくお願いいたします。