Amazon EC2

##1.Amazon Elastic Compute Cloud (EC2)とは？##
数分で利用可能なAWSクラウドの仮想サーバサービスです。

メインのサービスなので、詳細は↓のページを見て学習しましょう。
[20180411 AWS Black Belt Online Seminar Amazon EC2](https://www.slideshare.net/AmazonWebServicesJapan/20180411-aws-black-belt-online-seminar-amazon-ec2)

[AWS EC2 ハンズオン](https://qiita.com/leomaro7/items/8560bfbeb0672d0d83ec)もお試しを。



##2.EC2インスタンスファミリー##
ここでは、サーバーではなくインスタンスとよびます。
大きく分けて5つに分けられます。

- 汎用
- コンピューティング最適化
- ストレージ最適化
- メモリ最適化
- GPU・FPGAアクセラレーテッド

[「Amazon EC2 インスタンスタイプ」](https://aws.amazon.com/jp/ec2/instance-types)

表記　
例：T2.micro
T が汎用、M はもう少し性能の高い汎用、C はCPU重視、R はメモリ重視、のように特徴ごとに分かれています。
文字の後ろの2 や4 といった数字は世代を表しているので、T2 なら汎用向けのグループで2 世代目ということです。
nano、micro、small、medium、large、xlargeなどはCPU やメモリといったスペックの大きさを表します。

選び方
例えば、CPUの性能に重点をおきたい場合は、コンピューティング最適化にC５を選ぶ。
データベースのようにメモリを大きく消費する場合はメモリ最適化にR５を選ぶ。
といったように要件にあったシステムを構築する必要があります。

条件はありますが、変更することはもちろん可能です。
変更にはEC2インスタンスを一度停止した上で行う必要があります。

どのインスタンスファミリーが適しているかはドキュメントを確認したほうがよい。
[インスタンスタイプ](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instance-types.html)

**※T2インスタンスのCPUクレジット**
インスタンスタイプのサイズに応じてCPUクレジットを持ち、アイドル状態のときにCPUクレジットを貯めます。
定められたベースラインを超えてCPU性能を発揮させたい時はCPUクレジットを消費します。これをバーストと言う。

通常一定のセッションが張っているサービスなど、ベースラインを超え、すべてCPUクレジットを消費してしまうという落ちがあります。（この場合、CPU使用率は上がっている状態にはならないので、気づかない場合がある。）

[バースト可能パフォーマンスインスタンスの CPU クレジットおよびベースラインパフォーマンス](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html)

改善策は
1.パフォーマンスの高いインスタンスタイプに変更する。
2.T2/T3 無制限の有効化にする。

[バーストパフォーマンスインスタンスの無制限モード](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html?icmpid=docs_ec2_console)



##3.セキュリティグループ##
重要なので別の記事で書きました。
[Amazon EC2 セキュリティグループ](https://qiita.com/leomaro7/items/42967c080814dfc82139)



##4.料金##

- 利用している時間に対して課金される従量課金制です。
- 秒/時間のどの単位で課金されるかは使うOSにより異なります。
- 物理的キャパシティ（リージョン、OS、コア数、メモリ）などによって変わってきます。


では、料金をどう支払っていくか？というところで↓の項目

- オンデマンドインスタンス：基本の従量課金制です
 - 前払いや長期間の契約なしで、Amazon EC2 の低コストや柔軟性を利用したいと考えているユーザー
 - 短期間、スパイクを伴う、または予測不能な作業負荷があっても中断できないアプリケーション
 - 初めて Amazon EC2 で開発またはテストするアプリケーション

- リザーブドインスタンス：前払い制で割引になります。
 - 定常的に使用するアプリケーション
 - キャパシティーを予約する必要があるアプリケーション
 - コンピューティングの合計コストを削減するために、EC2 の 1～3 年間の使用を確約できるお客様

・RIタイプ
　・スタンダードされたRI
　・コンバーティブルされたRI
　・スケージュールされたRI　（特定のリージョンのみ）

スタンダードとコンバーティブルの違いは、事前の購入条件の後から変更可能な柔軟性の違いにあります。
スタンダードでは後からインスタンスファミリー、オペレーティングシステム、テナンシー、支払いオプションの変更ができないが、コンバーティブルでは可能。
スケージュールされたRIは特定の時間帯に対して利用するキャパシティを予め用意しておく方式です。

・スコープ
　リージョンリザーブドインスタンス とゾーン リザーブドインスタンスがあり、それぞれ利点がことなるので、↓を確認しましょう。
　[リージョンおよびゾーン リザーブドインスタンス (スコープ)](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/apply_ri.html)


- スポットインスタンス：使用されていないEC2のキャパシティに対して、あらかじめAWS側で定めたスポット価格に対して、入札をする形でご利用いただくスタイルです。
 - 開始および終了時間が柔軟なアプリケーション
 - 非常に低額のコンピュート価格でのみ実行可能なアプリケーション
 - 大容量の追加キャパシティーのために、緊急のコンピューティングニーズを有するユーザー

中断される場合は休止、停止、終了のいずれかを選択することができます。
特に休止をするとメモリ内のデータはEBSに保存され、中断前に戻すことができます。

・スポットブロック
　あらかじめ時間を指定しておき、その間はスポットインスタンスの継続稼働を保証するオプションです。利用中にスポット価格が高騰しても、指定した時間内であれば稼働が保証されます。

・スポットフリート
　インスタンスが停止しても指定台数の稼働を維持してくれる。

- Dedicated Hosts:お客様専用の物理 EC2 サーバーです。
 - オンデマンド (時間単位) で購入できます。
 - オンデマンド価格から最大 70% 割引となる予約を購入できます。

- ハードウェア専有インスタンス：専有のインスタンス

Dedicated Hosts とハードウェア専有インスタンスの違いは？
どちらのサービスでも専有のインスタンスが提供されます。
ただし、Dedicated Hosts ではインスタンスの詳細コントロール、Host レベルのリソース可視性、コアごとまたはソケットごとにライセンスが消費されるソフトウェア (Windows Server、SQL Server など) の管理ツールが利用可能です。
加えて、AWS Config ではインスタンスの Dedicated Hosts リソース使用状況が記録されるため、独自のライセンス使用レポートを作成できます。
[Dedicated Hosts と ハードウェア専有インスタンス の違い](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/dedicated-hosts-overview.html#dedicated-hosts-dedicated-instances)
2019年5月にEC2 Dedicated Host で予期しないハードウェアの障害が発生した場合に、新しいホスト上でインスタンスを自動的に再起動する、[Host Recovery](https://aws.amazon.com/jp/about-aws/whats-new/2019/06/amazon-ec2-announces-host-recovery/)が発表されました。


例としてして個別の料金については↓のようの計算されていきます。

- EC2：インスタンス数、それぞれに対して料金が発生します。例えば、負荷分散のために複数のインスタンスを実行すると、それぞれのインスタンスに対して料金が発生します。
- ELB：負荷分散をすることが可能で、利用した場合はロードバランサーの実行時間数、処理するデータ料によって月額料金が決まっていきます。
- Amazon CloudWatch：どのぐらい負荷がかかっているかモニタリングすることができ、基本モニタリング（デフォルト）は無料ですが、詳細モニタリングは利用した時間の分だけ料金が発生します。
- Auto Scaling：追加料金発生なし
- Elastic IP アドレス：ちょっと課金されていた？みたいなことがあったので、 [Amazon EC2 - ElasticIP](https://qiita.com/leomaro7/items/8d5472a95a0415ef902b) の記事を読みましょう。


ところで、OSとソフトウェアはどうなの？

- OSについてはインスタンス料金に含まれています。
- EC2インスタンス上で商用ソフトウェアパッケージを実行できるようになっています。
- AWSが提供していないソフトウェアパッケージはユーザーで各ベンダーからライセンスを取得する必要があります。



##5.AMIとスナップショット##

AMIとスナップショットってどう違うの？

- AMI：EC2のある断面/EC2インスタンスを作る元になる。新規インスタンス設定に転用するもの。
- スナップショット：EBSの断面/EBSを作る元になる。ストレージの復元や複製に利用。

例えばデータ用のバックアップだけを取りたいんだよというときは、スナップショットになります。
また、スナップショットを更にAMIにしたりすることもできます。
AMIを作成するときは、静止点（書き込みの最中にしない）を取って取得しましょう。



##6.プレイスメントグループ##

インスタンス間の通信速度を高速化させる機能です。（ネットワーク遅延を減らす機能と覚えておけばOK。）
単一AZ内の複数のEC2インスタンスをグループ化し、物理的になるべく近いインスタンスとして起動します。

なお、複数のAZを跨ぐグルーピングやネットワーク帯域が小さいインスタンスタイプはできない。
[プレイスメントグループのルールと制限](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/placement-groups.html#concepts-placement-groups)


|グループ|説明|
|---|---|
|クラスタープレイスメントグループ|単一AZ内のインスタンスを論理的にグループ化したもの<br>クラスタープレイスメントグループにインスタンスを起動すると、容量不足エラーが発生する場合があります。この場合は、プレイスメントグループ内のすべてのインスタンスを停止して開始し、もう一度起動を試みてください。|
|パーティションプレイスメントグループ|論理的なパーティションに分散されているインスタンスのグループ|
|スプレッドプレイスメントグループ|それぞれ異なるハードウェアに配置されるインスタンスのグループ|

↓わかりやすい。

https://qiita.com/mzmz__02/items/8651f578601f3a567fa0


##7.インスタンスストア##
インスタンスストアは、インスタンスが稼動している間のみ存続します。

[AMI にインスタンスストアボリュームを追加する](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/add-instance-store-volumes.html#adding-instance-storage-ami)




##8.ユーザーデータ##

ユーザーデータに登録しておけば、インスタンス作成時に実行される。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/cd2ccdb9-e50b-3366-6654-13a2d860aa20.png)

下記はhttpdをインスタンス作成時に実行し、開始しておく例。

```
#!/bin/sh

yum install -y httpd
/etc/init.d/httpd start
```

Windows インスタンスにおいて、デフォルトでは、ユーザー・データスクリプトはインスタンスを起動すると一度だけ実行されます。
インスタンスを再起動または起動するたびにユーザーデータスクリプトを実行するには、`<persist>true</persist>` をユーザーデータに追加します。

```
<script>
echo Current date and time >> %SystemRoot%\Temp\test.log
echo %DATE% %TIME% >> %SystemRoot%\Temp\test.log
</script>
<persist>true</persist>
```


##9.削除保護の有効化#
インスタンスを誤って削除しないように保護することができます。有効になると、削除保護を無効にしない限り、API や AWS Management Console を使用してこのインスタンスを削除できなくなります。

参考：[AWS EC2のインスタンスを間違って削除しないために
](https://qiita.com/n_kimura/items/04ab25fa94f83ddd8a22)


##10.Auto Recovery##
インスタンスのシステムステータスのチェック結果が失敗になった場合、CloudWatch アラームアクションを使用してインスタンスを自動的に復旧させることができます。

参考:
[インスタンスの復旧](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
[EC2 インスタンスを自動で復旧させるように CloudWatch アラームを設定する方法を教えてください。
](https://aws.amazon.com/jp/premiumsupport/knowledge-center/automatic-recovery-ec2-cloudwatch/)

「ステータスチェック」ー「ステータスチェックアラームの作成」
![スクリーンショット 2019-07-13 18.20.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/93268e41-9bb8-ea3c-1ca9-54e7c89d0c7b.png)

アクションは「このインスタンスの復元」
※「このインスタンスの復元」は、EC2インスタンスが開始されている状態でないと、グレーアウトの状態。
条件は「ステータスのチェックに失敗(システム)」
![スクリーンショット 2019-07-13 18.23.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/ff457c1b-e8ad-2858-a38c-4bb965cfc9bb.png)


##11.インスタンス起動数の制限##

- 20 を超えるオンデマンドインスタンスを実行したい場合は、AWSへ緩和申請が必要です。

※2019/09/24
[EC2がvCPUベースのオンデマンドインスタンス起動数の制限に対応した](https://qiita.com/leomaro7/items/355b6de76fd941428577)