まずEC2インスタンスを立てるところから説明進めようと思いますが、
その前段としてまずはAWSの基礎的なところを説明しておこうと思います。
#■VPC
VPCとはVirtual Private Cloudの略で、AWS内に作成できる仮想的な独立したネットワークです。
VPCを構築することで、任意のプライベートIPアドレスやサブネットの作成を行うことができます。
また、VPC内にサブネットを作ることも可能です。
（つまり自分のネットワークが作れる、ということです）
なお、VPCは後述のリージョンを跨って作成することはできませんが、アヴェイラビリティゾーンはまたがって作成することが可能です。
#■Elastic IP
EC2インスタンスのIPアドレスは起動の都度DHCPで割り当てられます。
そのため、再起動したらIPアドレスが変わってしまったということがよくあります。
そうなると外部から特定のパブリックIPアドレス指定で接続している場合は困ってしまいますね。
そのため、AWSには特定のパブリックIPアドレスを確保し、インスタンスに紐付ける仕組みが用意されています。それがElastic IPです。
Elastic IPとインスタンスを紐付けることにより、インスタンスを再起動しても同じIPアドレスで接続することが出来るようになります。
#■リージョンとアヴェイラビリティゾーン
##リージョン
AWSを語る上でリージョンについて触れないわけにはいきません。
リージョンとは、簡単に言うとデータセンターのことです。
現在以下の９箇所があるようです。
・バージニア
・カリフォルニア
・オレゴン
・東京
・シンガポール
・シドニー
・サンパウロ
・アイルランド
・フランクフルト
ここで気をつけねばならないのはAWSが提供しているサービスは全リージョン同じではないということです。
新しいサービスなどは一部のリージョンで導入されて、徐々に他のリージョンへ展開されていきます。
例えばLamdaなどは現時点で利用できるのはバージニア、オレゴン、アイルランドの３箇所です。
（今回のAWS Summit Tokyoで新たに東京も対応することが発表されましたね）
また、AWSのサービスは組み合わせて使うことが多いと思いますが、中には同じリージョンでなければ動作させられないものもあります。それらを考慮して、利用する各サービスのリージョンをどこにするかを考えなければなりません。
例えばLamdaに関しては以下の記事が詳しいです。
http://dev.classmethod.jp/cloud/trigger-lambda-on-other-regions/
ちなみに、今回我々が利用したサービスとリージョンの対応は以下の通りとなります。
EC2 (東京）
VPC（東京）
Lamda (オレゴン）
DynamoDB(オレゴン）
Cognito (バージニア）
S3(オレゴン/東京）＊
＊ログのアップロード用バケットはオレゴン、Webアプリデータを配置しているバケットは東京に配置しています。
アヴェイラビリティゾーン
次はアヴェイラビリティゾーン（以下、AZ)について説明したいと思います。
AZとはリージョン内で物理的に区切られたエリアです。
個々のAZは建物や電源、ネットワーク設備等が独立しています。（見たわけではないですが）
これによって複数のAZに分散してインスタンスを配置することによって
「データセンターに火災が発生してデータがロストしました。テヘ」
などということは回避することができます。
火災が発生するなどはそうそうあることではないですが、一時的なトラブルが発生すること想定しておくべきです。
その場合、複数AZにインスタンスが配置されていることでシステムの冗長性が確保されます。
例えば、あるAZ上あるインスタンスで障害が発生した場合、別のAZ上のインスタンスに先に説明したElastic IPを再マッピングすることによってサービスを継続することができます。
また、複数のAZ上にインスタンスを配置し、リクエストをELB等ロードバランサーを使って振り分けるという方法もあります。
次回はEC2のVPCやインスンタンスの具体的的立ち上げ手順、可能ならばMQTT Brokerのインストールまで説明したいと思います。