計算機インフラの時間貸し（Infrastructure as a Service）
様々な機能から構成されている
・仮想マシンの時間貸し（EC2）
・仮想ディスクへのデータ保存（EBS：Elastic Block Store）
・アクセス不可を複数のマシンに分散（ELB：Elastic Load Balancer）
・不可に応じてマシン数を自動で増減（ASG：Auto-Scaling Group）
EC2で設定できること
・インスタンスタイプ：t2.microは無料枠
t2, m5, m6g等：汎用インスタンスクラスと世代
c5a, cr, c6g等：コンピューティング最適化クラスと世代 – 機械学習/ゲーム等
r5, r6g, x1等：メモリ最適化クラスと世代 – ビッグデータ等
i3, d2, d3等：ストレージ最適化タイプと世代 – OLTP、NoSQL/DB、分散FS等
.micro, .2xlarge：インスタンスクラス内での大きさ
※ 詳しくは インスタンスタイプ か Vantage で
・OS選択：Linux or Windows
・CPUのクロック数・コア数
・メモリ容量
・ストレージ（ディスク）の容量：
ネットワーク経由で接続（EBS＆EFS）
仮想マシン直結（EC2 Instance Store）
・ネットワークインターフェース：速さ、グローバルIPの有無
・ファイアウォールのルール：セキュリティグループ
・起動時のスクリプト：EC2 User Data
セキュリティグループ
EC2インスタンスへの IN / OUT 両方のトラフィックを制御するファイアウォール
書けるのは許可ルールのみ（許可も拒否も書けるIAMポリシーとは違う）
他のセキュリティグループを参照可能（ELBを使う時によく使う）
複数のインスタンスにアタッチできる
リージョンとVPCの組合せの中に”閉じて”いる
EC2の”外”にあるので、トラフィックがブロックされるとEC2インスタンス側では通信があったことが”見えない”
SSHアクセス用のセキュリティグループは別に作っておくのがお勧め
よく使うWell-knownポート：
21=FTP, 22=SSH, 80=HTTP, 4443=HTTPS,
3389=RDP(Remote Desktop Protocol：Windowsにアクセスするため)
EC2インスタンスコネクト
ブラウザ経由ではあるが、SSH（22番ポート）を経由して繋いでいるため、
セキュリティグループ＞インバウンドルール＞SSH の ソースアドレス が Anywhere-IPv4（0.0.0.0/0）かチェック
hands on ：EC2上で aws iam list-users を実行したい場合
こんなIAMロールを作っておいて・・・
インスタンスにIAMロールをアタッチすると・・・
おお～
注意点：EC2インスタンス上には、アクセスキーを絶対置かない！
（そもそも接続元PCに AWS CLI をインストールして aws configure で設定するものだし！）
EC2インスタンスコネクトで操作を許可したい場合は、IAMロールをアタッチして解決すること！
＜EC2インスタンスの購入方法＞
EC2オンデマンド（通常） ★当日宿泊
使った分だけ支払う
・Linuxは、最初の1分以降は1秒単位で課金
・Windowsなど他のOSは、1時間単位で課金
コストは最も高いが、初期費用がかからない
長期的なコミットメントなし
アプリがどう動くか予測できないような、短期的で中断のないワークロードに適している
EC2リザーブドインスタンス ★早割り予約で宿泊
オンデマンドと比較して最大72%の割引
予約期間は1年または3年（長期ほど割引が大きい）
購入オプション：前払いなし、一部前払い、全部前払い（後者の方が割引が大きい）
特定のインスタンスタイプを予約する必要がある
定常的に使用するアプリケーション（DBなど）にお勧め
EC2コンバーティブル リザーブドインスタンス
インスタンスタイプを変更することが可能だが、最大割引率が54%と通常のリザーブドよりは低め
その他は通常のリザーブドと同じ（のようだ）
EC2スポットインスタンス ★キャンセル待ち 宿泊中に金持ちが来ると追い出される可能性あり
最大90%の割引が可能
最大指定価格が現在のスポット価格よりも低い場合、どの時点でも「インスタンスが停止」する可能性があるインスタンス
AWSで最も費用対効果が高いインスタンス
障害に強いワークロードに有効（バッチジョブ、データ分析、画像処理、開始・終了時間に制約がない処理…）
クリティカルなジョブやデータベースには向かない
専有ホスト（Dedicatedホスト） ★貸し切り
物理的なEC2サーバーを専有
用途：サーバ単位でライセンスされる商用ソフトウェアを使う場合や、コンプライアンス要求で求められている場合
3年分予約が必須 高価
複雑なライセンスモデル（BYOL – Bring Your Own License）を持つソフトウェアに有効
規制やコンプライアンスのニーズが強い企業にも適している
専有インスタンス（Dedicatedインスタンス）
専有ハードウェアで動作するインスタンス
同じアカウント内の他のインスタンスとハードウェアを共有されるかも（？）
インスタンスの配置を制御できない（停止/開始後、同じハードウェアとは限らない）（？）
EC2スポットインスタンス 詳細
・AZごとに、最低価格は違う（m4.largeが$0.0326だったり0.0440だったり）し、なんと若干変動する！
・スポット価格の最大値を設定
・現在のスポット価格が最大値未満の間、インスタンスを利用できる
・閾値を超えたとき、インスタンスを「停止する」か「終了する」か選択して起動する
↑
スポットリクエスト で定義 create request
Maximum price 最大価格
Desired number of instances 必要なインスタンスの数
Launch specification インスタンスタイプやAMIなどを指定する起動テンプレート
★Request type: one-time 確保できてインスタンスが起動すると、requestが消滅する
pesinstent スポットインスタンスが起動しても、有効期間の間はrequestは残る
Valid from, Valid until 有効期間
・キャンセルできるのは、オープン、アクティブ、または無効になっているスポットインスタンスリクエストのみ。
スポットリクエストをキャンセルしても、起動中のインスタンスは終了しない。ってか当たり前じゃん・・
もう一つのやりかた：スポットブロック
指定された時間帯（1～６時間）に中断することなくスポットインスタンスを”ブロック”できるが完璧ではない。。
スポットフリート（スポットインスタンスを安く便利に使う仕組み）
スポット＋オンデマンド（オプション）のセット
価格の制約を満たしつつ目標要領を満たそうとする
・使用可能なローンチプールを定義（複数設定可）：
インスタンスタイプ、OS、AZ
・容量・最大コストを満たすまでインスタンスを起動
スポットインスタンスを割り当てるための戦略
・lowestPrice：最も安い価格のプールから（コストの最適化、短いワークロード）
・deversified：全てのプールに分散している（可用性や長時間のワークロードに最適）
・capacityOptimized：指定インスタンスタイプに余裕のあるプールからなるべく選ぶ
最低価格のスポットインスタンスを自動的にリクエストすることができるので、
総じて、バッチジョブ、データ分析、または中断してもよいワークロードに利用すること。
クリティカルなジョブやデータベースには向かない。
プレースメントグループ
EC2インスタンスの配置戦略をコントロールしたい場合（どのAZで起動されるか等）に使う
指定できる戦略
・クラスター：１つのAZ内の低レイテンシーグループにインスタンスを集中的に配置
同じAZの同じラック内に全EC2を配置するので、遅延が少ない
・スプレッド：AZ跨ぎで（別々のハードウェアに）EC2を分散
メリット：物理的にロケが違うので災害や障害に強い
デメリット：1AZ・1配置グループあたり最大7インスタンスまで
・パーティション：AZ内の多数のパーティション（物理サーバラック）に分散して配置
1AZあたり最大7パーティションまで
物理的にサーバラックが違うので障害に強い
1グループあたり数百台のインスタンスを配置可能
メタデータとしてパーティション情報にアクセスできるので、
同じパーティションGに属するインスタンスを探し出して通信することもできる
分散型データ処理を利用するときに有効
例）Apache Hadoop（HDFS, HBase）, Meta Cassandra, Apache Kafka
設定場所：インスタンス作成＞高度な詳細
ENI（Elastic Network Interfaces）
同じAZ内で自由にアタッチ・デタッチできる仮想NIC！すげー！
NICが持てる属性は下記の通り
MACアドレス（1つ）
プライマリプライベートIPv4（1つ）←ElasticIPを付与できる
セカンダリプライベートIPv4アドレス（複数可！）←それぞれにElasticIPを付与できる！
パブリックIPv4アドレス（1つ）
セキュリティグループを付与できる（複数可！）
ENIは独立しているので、別のEC2に付け替えもできるし、EC2以外にも付け替えできる。
同じAZ内ということを忘れずに！
EC2 Hibernate（冬眠させる）
通常のEC2の動き
停止（ストップ）：ディスク（EBS）上のデータは次の起動時にもそのまま維持
終了（ターミネーション）：削除設定されているEBSボリュームは失われる
EC2起動時に起こること
初回起動：OSが起動し、EC2 User Dataスクリプトが実行される
2回目以降：OSが再起動する
Hibernateを使うと・・
インメモリー（RAM）の状態を保持して、インスタンスを一時停止
インスタンスの起動が格段に速くなる（OSの停止や再起動がないため）
内部の振る舞い：RAMの状態は、ルートEBSボリュームのファイルに保存
ルートEBSボリュームを暗号化する必要がある
ユースケース：ロングラン処理 / RAMの状態を保存したい / 初期化に時間がかかるサービス
対応するインスタンス・ファミリー：c3, c4, c5, m3, m4, m5, r3, r4, r5
インスタンスのRAMサイズ：150MB以下であること
インスタンスサイズ：ベアメタルインスタンスには非対応
AMI：Amazon Linux 2, Linux AMI, Ubuntu, Windows..
ルートボリューム：EBSであること、EBSが暗号化されていること、インスタンスストアではないこと、大容量であること
オンデマンドとリザーブドで利用可能
インスタンスのハイバーネーションは60日まで
設定場所①：インスタンス作成＞ストレージ(ボリューム) ボリュームを作るときにEBSを暗号化しちゃおう
設定場所②：インスタンス作成＞高度な詳細
一旦停止するときには、インスタンスの状態を「休止」にする
※uptimeコマンドでEBSが失われていなかったことがわかるよ
アタッチ済みの暗号化なしEBSを、暗号化してアタッチしなおす方法（xvdaルートボリュームではできないんだろうな・・？）
①EBSボリュームのスナップショットを作成（この時点では暗号化なし）
②EBSスナップショットを暗号化（コピーを使って）
③スナップショットから新しいEBSボリュームを作成（ボリュームも暗号化される）
これを元のインスタンスにアタッチすれば完了
EC2 Nitro
次世代のEC2インスタンスの基盤となるプラットフォーム（新しい仮想化技術）
パフォーマンスを向上させることができる
より優れたNWオプション（拡張NW、HPC、IPv6）
より高速なEBS（EBSのIOPSを64,000にするにはNitroが必要）
基本的なセキュリティの向上
インスタンスタイプの例
仮想マシン：a1, c5, c5a, c5ad, c5d, c5n, c6g, c6gd, c6gn d3, d3en, g4, i3en, inf1, m5, m5a, m5ad, m5d, m5dn, m5n…
ベアメタル：a1.metal, c5.metal, c5d.metal, c5n.metal, c6g.metal, c6gd.metal…
vCPU
1つのCPUで複数のスレッドを走らせることができるマルチスレッド
1つのスレッドを実行するのが、仮想CPU（vCPU）
例）m5.2xlarge
4CPU（4コア）
1CPUあたり2スレッド（vCPU） 4コア×2スレッド＝合計 8 vCPU
CPU最適化オプション
EC2インスタンスには必ずRAMとCPUがある
必要であれば、vCPUのオプションを変更することができる
CPUコア数：減らすことができる（大容量RAM・少数CPUが必要な時に有効）※ライセンスコストの削減
コアあたりのスレッド数：マルチスレッドの無効化 ※ハイパフォーマンス・コンピューティング（HPC）ワークロード
起動時にのみ指定可能 そりゃそうでしょ
例）r4.2xlarge
Default 8vCPU 4core 2thread →
キャパシティリザベーション
必要なタイミングでEC2の容量を確保
予約の終了：手動、または終了日を事前に設定
1年や3年の縛りは不要
キャパシティはすぐにアクセスできるので、開始と同時に課金される
指定項目
キャパシティを予約するAZ（1つのみ）
インスタンス数
インスタンスタイプ、手ナンシー、プラットフォーム/OSなどのインスタンス属性
リザーブドやセービングプランと組み合わせてコスト削減を実現