EC2を起動する際に必要なテンプレートがインストールされている
逆に、自分で設定したEC2レシピも保存しておくことが出来る
EC2起動時に設定するもの、提供したいサービスの容量により変更可能
ホワイトリスト形式（この通信はOK,NGと記述したリストで判断する形式）で制御される
そのためELB,RDS,ElasticCacheなんかも記述すれば設定できる（なんやそれ！！後述します）
◯ELB（Elastic Load Balancing） 厳密にはELBのALB
※GW ← ELB（ALB） ← アプリ{パブリックサブネット（NATGW）←プライベートサブネット}
アクセス数に対して不可のバランスを複数のEC2に分散させる
もし1台のEC2だけでサイトを運営していた場合、サーバー障害が起きたら復旧まで何も出来ません。
ただし複数のEC2でサイトを運営していたら、1つに障害が起きても切り替えればOKということになります。
1つのEC2だけでなく、アクセスに応じてサイトアクセスのバランスをとってくるれる機能です
・CLB（クラシック・ロードバランサー） ：元ELBと呼ばれてましたが、ALBが出来たので名称変更
EC2のCPU使用率を監視し閾値を超えたら、自動的にELBの下にインスタンスを自動追加できる機能
◯ECS（Amazon Elastic Container Service）
例）1社がサービスを3つ持っている、そのサービスにつきEC2が複数あるような状態となっている
1個1個EC2を見て管理できますか？出来ませんよねと言う理由から生まれたECS
従来1つのサーバーに複数の機能を持たせていたが（メッセージ機能、コメント機能的な
Rilsでいうモデルを1つのファイルにまとめている状態）、があまりにも膨大になったことで、
クラウド技術で機能を分割（コンテナ化）して、ダメだったら捨てて、次にいきましょう（アジャイル化）
そう言う観点から見ると、私のPFは旧来のサーバーを、AWSのEC2に置き換えてアプリが置いている状態
より実戦として考えたら、EC2インスタンスを機能ごとに増やさなければいけない。
ECSクラスターをベースに、その上にECSインスタンス、その上にDockerコンテナを実行・停止が出来るサービスとなっている
ECSインスタンスは、{EC2を含む + Dockerコンテナ（アプリの概要）=タスク}を生み出せる
ただし上記の動作を一発で解消してくれるためには、タスク定義をしなければいけない（初見殺し、ここで皆散っていきます）
・ECR(Elastic Container Registory（レシピ）)
ローカルで作ったDockerイメージをpushすると保存、pullして保存した内容を引き出してくれる（DockerコマンドでOK）
・Fargate（どちらもECSを使う、EC2タイプ？Fargateタイプ？の違いだけ）
ECSを使用してEC2を使う＝ECS(1つのECSインスタンスの中にEC2があり、設定が必要)
ECSを使用してEC2を使わない＝Fargate（EC2部分の設定が不要で、コンテナあればOK）
ECS同様にFargateタイプも選択することが出来る
