AWS　コンピューティング

EC2

　サイズ変更可能な仮想マシン（EC2インスタンス）をクラウド提供するサービス

Amazonマシンイメージ（AMI）

　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だけでなく、アクセスに応じてサイトアクセスのバランスをとってくるれる機能です

ELBは3種類

　・ALB（アプリケーション・ロードバランサー）：HTTP/HTTPSに対応した不可分散
　・NLB（ネットワーク・ロードバランサー）　　：TCP/UDPに対応した不可分散
　・CLB（クラシック・ロードバランサー）　　　：元ELBと呼ばれてましたが、ALBが出来たので名称変更

EC2　AutoScailing機能

　EC2のCPU使用率を監視し閾値を超えたら、自動的にELBの下にインスタンスを自動追加できる機能

ECS（Amazon　Elastic　Container　Service）

例）1社がサービスを3つ持っている、そのサービスにつきEC2が複数あるような状態となっている
　　1個1個EC2を見て管理できますか？出来ませんよねと言う理由から生まれたECS
　　従来1つのサーバーに複数の機能を持たせていたが（メッセージ機能、コメント機能的な
Rilsでいうモデルを1つのファイルにまとめている状態）、があまりにも膨大になったことで、
クラウド技術で機能を分割（コンテナ化）して、ダメだったら捨てて、次にいきましょう（アジャイル化）
ということで使用されている。
そう言う観点から見ると、私のPFは旧来のサーバーを、AWSのEC2に置き換えてアプリが置いている状態
（このアプリの中に継ぎ足しをしている）と言える。
　　より実戦として考えたら、EC2インスタンスを機能ごとに増やさなければいけない。

ECS

　ECSクラスターをベースに、その上にECSインスタンス、その上にDockerコンテナを実行・停止が出来るサービスとなっている
　ECSインスタンスは、{EC2を含む + Dockerコンテナ（アプリの概要）=タスク}を生み出せる
　もう1個1個設定しなくてもECS様がやってくれる
ただし上記の動作を一発で解消してくれるためには、タスク定義をしなければいけない（初見殺し、ここで皆散っていきます）

ECR(Elastic Container Registory（レシピ）)

　AWS版のDockerhub(Dockerレジストリ＝コンテナの保管場所)
　ローカルで作ったDockerイメージをpushすると保存、pullして保存した内容を引き出してくれる（DockerコマンドでOK）

Fargate（どちらもECSを使う、EC2タイプ？Fargateタイプ？の違いだけ）

　ECSを使用してEC2を使う＝ECS(1つのECSインスタンスの中にEC2があり、設定が必要)
　ECSを使用してEC2を使わない＝Fargate（EC2部分の設定が不要で、コンテナあればOK）
　※インフラ部分はAWSで補います！ということ

EKS（同じくコンテナオーケストレーションサービスのkubernetes用）

　ECS同様にFargateタイプも選択することが出来る