自分用メモ、昨日の続きから
セキュリティグループ
セキュリティのルールをまとめた仮想FW。許可したいものだけ記載するホワイトリスト方式。
インバウンドは外から内へ、アウトバウンドは内から外への通信。
基本的に使うポートだけ開ける（インバウンドに記載する）。
開けすぎると攻撃受ける箇所が多すぎてセキュリティリスクであるから。
EC2のポートを開けるというよりは、ルールを作ってそこにEC2が従う的な感じ。
何が違うかって言うと、22と80のポートを開けたいサーバが2つあったとき、各それぞれに設定を作らなくて良くて、一度設定を作ったとこに所属させれば良い。お手軽。
セキュリティグループはステートフルといって、外へのトラフィックのについての、戻りのトラフィックは自動的に許可されるって仕組みらしい。
球技で例えるとわかりやすいかも。テニスとか。
フォアハンドで打ったものがバックハンド側に返ってきても受け取れる。みたいな。
しかし、相手のサーブをバックハンドで受け取るには、準備してないと受け取れないよーってな感じ。
また、アクセス元もセキュリティグループで指定できます。Aに入ってるサーバからのインバウンドはうけとるよーって感じ。IPでアクセス元の指定をしてたら、5台あれば5個の設定が必要だけど、セキュリティグループでの指定ならその5台をグループに入れちゃえばいいだけ。お手軽。
プレイスメントグループ
一緒のAZなら通信が早いよってこと。深く考えずに、近いんだから早いやろってくらいの気持ち。
監視
メトリクス（CPU使用率とかのリソース監視）はcloudWatchってサービスでできる。SNSを使ってメールで通知することもできる。
また、ログ監視したい場合はインスタンスにエージェント入れればcloudWatchにあつめてくれる。
auto recovery
ハードウェア障害とかが起きたときの対応を設定しておくことで自動的にやってくれる。
ハードウェア障害の際に、自動再起動を仕込んでおけば、落ちっぱなしじゃなくて別ホストコンピュータにて起動されて復帰が早くなる仕組み。
一応、ホストコンピュータ側だけじゃなく、インスタンス側の障害の場合でもauto recoveryは使える。
AWS marketplace
予めソフトウェアがインストールされてるAMIを購入できる。インスタンス作ってからソフトウェアインストールする手間が省けるから便利。
一旦区切り、次回EBSから。