私はAWSを初めて使用し、調査を行いましたが、良い答えが得られなかったため、簡単な質問をしました。
私がこれまでにしたこと
したがって、実際には、http：//example-domain-name.comを使用すると、アプリを表示して操作することができます...
私の質問は、私のアプリは正しくデプロイされていますか？AWS AMIのクラッシュなど、ホラーストーリーを聞いたことがあります。
これに関するあなたの専門知識を共有していただけませんか。
あなたの質問に対するあなたのコメントによると、考えられるすべてのケースの中で最良のものは、複製するmysql db、または余裕があればAmazon RDSのようなもののいずれかでバックアップされた、高可用性、マルチAZ、自動スケーリングWeb層です。これは、いくつかの変数を入力した後、約2回のクリックで説明したものを多かれ少なかれ構築するCloudFormationテンプレートの例です。
それはやり過ぎだと思います...しかし、Amazonの無数の障害モードについて心配しているのであれば、高可用性を低価格で手に入れることができます。そのテンプレートのデフォルトインスタンス（マルチAZ RDSを含む）は、24時間年中無休の稼働時間で月額約270ドルになります。あなたが本当にあなたのブログに専念していて、あなたが何年もの間それを書いていることを保証することができれば、あなたは予約されたインスタンスを使ってかなりのお金を節約することができます。
それはたくさんのお金です、はい。しかし、それはニューヨークでの私の毎月の自動車保険料よりも安いです。これは、Amazonの価格よりも、疑わしい保険会社や運転記録について多くを語っていますが、一部の個人用アプリケーションでは、高可用性設計はコストに見合う価値があるかもしれません。あなたにとってあなたの時間はどのくらいの価値がありますか？ブログはどうですか？
あなたはそれを買う余裕があり、それでも食べるために金でいっぱいのダンプトラックを持っていなければならないので、それを金本位制と呼んでください。出血し始めたときに何を失いますか？
AZ：マルチAZ展開を撮影すると、AZが停止するリスクがあります。これはそれほど頻繁には発生しませんが、DCメトロではデレチョも発生しません。ただし、心配しないでください。単一のAZを中心に設計する場合は、巨大でおそらく予期しない会社にいることになります。
RDS /複製されたMySQL：高可用性データソリューションを失うと、データを失うリスクがあります。これは、たまに発生するEBSスナップショットのように単純であっても、それを念頭に置いて設計するのが最善の場合から回復するのは非常に困難です。
複数のWebサーバー：MySQLデータベースと同様に、Web層を1台のマシンに配置すると、停止が発生します。代替案を買う余裕があれば、それを中心に設計することができます。それ以外の場合は、Webサーバーを構築するための簡単なプログラムによる方法が必要になります。
自動スケーリング：インスタンスの最小数と最大数が正確に1つであっても、CloudFormationまたはCLIツールを介して自動スケーリングを使用せずにAWSアプリケーションを設計する理由がわかりません。AWSの料金の無料利用枠には、インスタンスのモニタリングを容易にするためのCloudWatchメトリクスが多数含まれていますが、もちろんこれは...
構成管理：すべてのAWSデザインに共通するスレッドは、構成管理です。これは、実際に展開するマシンの数に関係なく、展開プロセスの最も重要なコンポーネントです。CloudFormation、Chef、Puppet、その他のサービス、またはそれらの組み合わせを使用しているかどうかに関係なく、マシンの構築がまだ頭に残っているときに構成管理に費やす時間は、後で報われます。
これらの各コンポーネントは、アプリケーションの安定性に貢献し、すべてに費用または時間がかかります。それはあなたが何をいつ使いたいかという問題です。
アマゾンの無料利用枠でゴールドスタンダードへの道の一部を手に入れることができます。これには、マイクロインスタンス、ELB、および小さなRDSインスタンスを単一のAZで継続的に実行するのに十分な時間が含まれます。また、この記事の執筆時点では、10個のカスタムCloudWatchメトリクスを使用できます。無料利用枠は、新規のお客様が最初の1年間使用する場合にのみ利用できます。そのオファリングをいくつかの基本的な構成管理と組み合わせると、多くのダウンタイムシナリオを回避する方法でAWSで小さなブログを合理的に実行できます。
AWSEC2サーバーはいつでも「故障する可能性がある」ことを理解することが重要です...これは「設計による」です...彼らは安価な非冗長コモディティハードウェアに安い家賃を請求しています...SLAはありません。 。
したがって、本当の質問は次のとおりです。サーバーを最初からすばやく再構築したり、EBSスナップショットから復元したりするための十分に文書化された（理想的にはスクリプト化された）プロセスがありますか？
その質問に対する答えが次の場合：はい！それなら、あなたは「正しくやった」と言うでしょう...
そうでない場合は、AWSの土地で発生する可能性のある悪いことを理解するためにもう少し時間を費やしたいと思うかもしれません...（これも「設計による」）。
良い方法はありません。少なくとも、1つのロードバランサーと2つのアプリインスタンスが必要です。さらに、アプリケーションによっては、フォールトトレラントなRDSインスタンスやS3が必要になります。
AWSは、単純なアプリやブログには不適切なソリューションです。別のプロバイダーで単一のVPSまたは専用サーバーを使用することにより、大幅に低いコストではるかに優れたパフォーマンスと耐久性を得ることができます。AWSを使用すると、アプリケーションを迅速にスケーリングする機能に割増料金を支払うことになります。あなたがそれをする必要がないならば、それは正しい選択ではありません。AWSを使用している人の90％はこれを理解していません。