【2022年版】Amazon EC2 まとめ

# はじめに
AWSの仮想マシン提供サービスである**Amazon EC2**について、**2022年9月時点での機能および使用法**を、初学者でも理解しやすいことを心掛けてまとめました。

<img width=480 alt="各クラウドのコンピューティングサービス" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/69bec559-d5a9-c624-ae55-2fa3e53bc58a.png">

**網羅度**にこだわってまとめたので、**EC2の全体像を把握したい**という方は、ぜひご一読頂ければと思います。

また、「[EC2の使用法](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2の使用法)」パートでは、**公式ベストプラクティスに則った活用法**について解説しておりますので、「**現在EC2を活用しているが、適切に運用できるているか不安**」という方にも、ご一読いただけるとありがたいです。

# Amazon EC2とは
「Amazon Elastic Compute Cloud」の略です。後ろの2つの単語の頭文字が`C`なので、`C2`と略しているようです。

EC2は**クラウド上にOS付きの仮想マシン（VM）を作成**できるサービスであり、砕けた言い方をすると「インターネット上に自分専用のパソコン（サーバ）を立ち上げる」ことができます。

このようにクラウド上でOS付きの仮想マシン環境を提供するサービスをIaaS (Infrastructure as a Service)と呼びますが、**EC2はIaaSの中でも最も有名かつ広く用いられているサービス**であり、AWSの主要サービスの一つと言える存在です。

<img width=640 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/80d16e9b-564f-b5e2-8fa5-b53939905f7a.png">

## EC2のメリット
**EC2**（というより**IaaS**）を**オンプレサーバと比較したメリット**として、まず物理的なハードが不要である事によるスペースや初期費用のメリットが挙げられますが、それ以外にも以下のメリットが得られます。

- 使った分だけ過不足なく料金が請求される（**コスト**の変動費化）
- 障害への耐性を簡単な設定で確保できる（**可用性**）
- 適切な設定により柔軟に性能を向上させられる（**パフォーマンス**）
- アクセス権限を簡単に設定できる（**セキュリティ**）

これらを実現する機能については[後ほど詳説](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2の仕組み)します。

また、より機能を絞った**SaaSやPaaSと比べた際の特徴**は「**何でもできるが、何かをするためには自分で逐次設定が必要**」であることが挙げられ、近年ではサーバーレス技術を用いて設定管理を簡略化できるFargateやLambda等のサービスに置き換えられることも増えています。

ともあれ、「**何でもできて**」「**コストが安い**」というEC2の特徴自体は多くのエンジニアにとって魅力ではあるので、今後も広く用いられることは間違いないでしょう。

<br>
<br>

# EC2の仕組み
EC2の仕組みについて、以下のセクションに分けて解説します

- [**EC2の構造**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2の構造)
- [**EC2とネットワーク**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2とネットワーク)
- [**EC2のセキュリティ機能**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2のセキュリティ機能)
- [**EC2とバックアップ**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2とバックアップ)
- [**その他のEC2関連機能**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#その他のec2関連機能)

## EC2の構造
EC2は大きく分けて、以下の構成要素から成り立っています。

|名称|通常のPCにおける役割|
|---|---|
|[**AMI (OS)**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ami-os)|OS (Linux, Windows等) + 一部のミドルウェア|
|[**インスタンスタイプ**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスタイプ)|CPU + メモリ (+ NVMeストレージ + GPU)|
|[**ストレージ (EBS)**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ストレージ-ebs)|ストレージ (HDD, SSD)|

### AMI (OS)
AMI (Amazon Machine Images)とは、インスタンス起動時に実行されるOSイメージを表します。
OSのみならずミドルウェアがインストールされたAMIも準備されており、[後述](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ミドルウェア)のように用途に応じて選択することができます。

また、AWSがデフォルトで提供するAMI以外にも、サードパーティ製のAMIや、ユーザが独自に作成できる**カスタムAMI**と呼ばれる仕組みが存在し、環境構築の簡略化や[バックアップ用途](https://www.mussyu1204.com/wordpress/it/?p=739)等で使用されています。

以下では、AWSがデフォルトで提供するAMIについて解説します。

#### ・選択できるOS
2022/9現在、東京リージョンでは以下のOSが選択できます

|名称|分類|概要|
|---|---|---|
|Amazon Linux|Linux|RedHat系のAmazon独自Linux OS|
|Red Hat (RHEL)|Linux|RedHat系の代表的なLinux OS|
|Ubuntu|Linux|Debian系の代表的なLinux OS|
|Debian|Linux|Debian系の代表的なLinux OS|
|SUSE Linux|Linux|Slackware系の代表的なLinux OS|
|Windows|Windows|Windows Server|
|Mac OS|Mac|Mac OS|

**初心者**はまずは**Amazon Linux**を選択すれば問題ないかと思います。

また、アーキテクチャも同時に選択できますが、ここで選択したアーキテクチャと、[インスタンスタイプ](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスタイプ)のアーキテクチャを揃える必要があります。

#### ・ミドルウェア
通常のWebサーバ等の用途であれば、OSのみがインストールされたAMIで問題ありません。
一方で**以下のような特殊用途**を想定して、**一部ミドルウェアがインストールされたAMI**も提供されています。

|AMIの名称|概要|想定用途|
|---|---|---|
|Deep Learning AMI|TensorFlowやPyTorchの実行環境(CUDA, GPUドライバ等)が|Deep LearningによるAI開発|
|with SQL Server|SQL Serverがインストールされている|DBサーバ|
|with .NET 6|.NETの開発環境やMATEによるデスクトップ環境|.NETを使用した開発 (Unityを使用したゲーム開発等)|

### インスタンスタイプ
サーバにおいて処理を実行する装置(CPU, メモリ等)を選択します。

これらを選択するために一意に付与されたIDを**インスタンスタイプ**と呼び、
`t2.micro`のような名称で表されます。

名称の解釈として、`t`の部分がインスタンスの種類(ファミリー)、`2`の部分が世代、`micro`の部分がサイズを表しており、ファミリーは用途と対応、世代とサイズは基本的に大きいほど高スペックとなります。

インスタンスタイプの名称だけでは具体的なスペックが分からないので、コンソール上で一緒に表示される以下の情報を参考にすると、選択しやすいかと思います。

|名称|概要|
|---|---|
|vCPU|仮想CPUの個数 (個数だけでは情報不足であれば、[公式ドキュメント](https://aws.amazon.com/jp/ec2/instance-types/)で具体的なCPUの種類を確認できます)|
|アーキテクチャ|x86_64, Arm64等のCPUアーキテクチャ|
|メモリ|仮想メモリの容量|
|ネットワーク帯域幅|EC2外部と通信する際の帯域幅 (通信速度)|
|ストレージ|インスタンスストア([後述](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスストア))の容量(EBSではないので注意、通常は0)|
|GPU|GPUの個数 (通常は0だがDeep Learning用途で必要)|

また、AWS公式でも以下のような用途とインスタンスタイプの関係を示すドキュメントが提供されており、選定の参考となるかと思います。(練習用であればデフォルトのt2.microで良いかと思います)

https://aws.amazon.com/jp/ec2/instance-types/


### ストレージ (EBS)
パソコンにおけるHDDやSSDと同様に、EC2にもストレージを付与する必要があります。
特に、起動用OSがインストールされたストレージ (**ルートボリューム**)は必須です。

EC2のストレージには一般的に、**EBS** (Elastic Block Store)というサービスが用いられますが、特殊な用途では**インスタンスストア**と呼ばれるサービスも使用されます。

|名称|着脱(アタッチ)可否|冗長性|データの永続性|バックアップ<br>(スナップショット)|速度(スループット)|速度(IOPS)|
|---|---|---|---|---|---|---|
|**EBS**|可能|あり|あり|可|高速|SSDは高速, HDDは低速|
|**インスタンスストア**|不可|なし|なし|不可|EBSより高速|EBSより超高速|

なお、**スループットとIOPS**の違いは以下のサイトが詳しいですが、大まかには以下のように解釈できます。

- スループット: **大きなファイルを一度に**読み書きする際の速度
- IOPS: **細切れのファイルに頻繁に**読み書きする際の速度

https://www.itbook.info/network/storage02.html

#### ・EBS
EBSはEC2に対して自由に着脱(アタッチとデタッチ)可能なストレージで、一般のHDDやSSDのように使用することができます。

EBSもインスタンスタイプと似た**ボリュームタイプ**と呼ばれる一意の名称から選択することができます。
主なボリュームタイプは以下のようになります

|ボリュームタイプ名称|種類|耐久性|スループット(MB/s)|IOPS(回/s)|容量|備考|
|---|---|---|---|---|---|---|
|**gp3**|SSD|99.8-99.9%|1000|16,000|1GB-16TB||
|**gp2**|SSD|99.8-99.9%|250|16,000|1GB-16TB||
|**io2Block Express**|SSD|99.8%|1000|16,000|4GB-64TB||
|**io2**|SSD|99.999%|4000|256,000|4GB-16TB||
|**io1**|SSD|99.999%|1000|64,000|4GB-16TB|複数インスタンス共有可|
|**st1**|HDD|99.8-99.9%|500|500|125GB-16TB|ルートボリューム不可|
|**sc1**|HDD|99.8-99.9%|250|250|125GB-16TB|ルートボリューム不可|

基本的にはHDDのsc1やst1よりもSSDのgp2やgp3の方が、また同じSSDでもgp2やgp3よりio1やio2の方が高性能ですが、その分[コストが高く](https://aws.amazon.com/jp/ebs/pricing/)なります。
またgp2が容量に応じた時間課金のみであるのに対し、gp3は読み書きに伴うIOPSやスループットにも課金されます([詳細はこちら](https://aws.amazon.com/jp/ebs/pricing/))

ボリュームタイプによる性能差はスループットよりもIOPSの方が大きいので、基本的には**IOPSに求められる要件とコストのバランス**を見て判断するのが良いでしょう (良くわからなければデフォルトのgp2で良いかと思います)

スループットやIOPSはボリュームの容量によっても変わるので、詳細は以下の公式ドキュメントを参照ください。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-volume-types.html

なお、EBSはEC2と一体化して動作するという特性上、**同じAZ内のEC2インスタンスとしか紐づけられません**。
また、[io1を除き](https://dev.classmethod.jp/articles/ebs-multi-attach-available/)、1つのEBSを複数のEC2インスタンスで共有する事はできません。

##### ※スナップショット
スナップショットとは、**EBSのデータをS3にバックアップ**する機能です (ユーザのS3ではなく、AWSが管理するS3バケットに保存されます)
障害時の復旧等に有用な機能ですが、[有料](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ボリュームのコスト)である事にご注意ください。

また、EBSのみで使用できる機能で、**インスタンスストアでは使用できない**事にご注意ください

スナップショットによる[**バックアップの詳細は後述**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2とバックアップ)します。

#### ・インスタンスストア
通常、EC2のストレージには[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ebs)EBSが用いられますが、一部のインスタンスタイプでは**インスタンスストア**と呼ばれるストレージが選択できます。

インスタンスストアはEBSと比べ**データ消失のリスクがある** (冗長性がない＆インスタンス停止時にデータが消える)が、**高速アクセス**(特に**IOPS**が速い)が可能なストレージで、**耐障害性を犠牲にしてでも高頻度アクセスにおける処理速度**を重視したい用途 (一時ストレージ等)に向いています。

選択できるインスタンスストアの種類は、以下の公式ドキュメントに記載されています。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/InstanceStorage.html#instance-store-volumes

#### ※EBSとインスタンスストアどちらを選択するか？
どちらを選択するかですが、ざっくり言うと以下のように選択するのが適切かと思います

- **EBS**: **速度はそこそこ**だが、**データの消失対策やコスト面に優れる**。**一般的**にはこちらを選択
- **インスタンスストア**: **超高速**だが、**データの消失対策やコスト面で弱い**。**速度最優先の一時ストレージ**向け

両者の差は以下の公式ドキュメントでも比較されており、**インスタンスストアが適した用途**として`頻繁に変更される情報 (バッファ、キャッシュ、スクラッチデータ、その他の一時コンテンツなど) の一時ストレージに最適`と記載されています

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ComponentsAMIs.html#storage-for-the-root-device

また、下記ページも選択において参考になります。

https://dev.classmethod.jp/articles/howto-ec2-volatile-block-storage-instance-store/

#### ※S3やEFSとの違い
AWSのストレージサービスといえば**S3**というイメージがある方も多いかと思いますが、EBSやインスタンスストアとの違いを考えてみます。

**EBSやインスタンスストア**はOSのイメージが入っていることから分かるように、**EC2インスタンスと一緒に動作する事が前提**となっており、通常のPCで言うと内蔵HDD(SSD)に相当します。

一方でS3は静的サイトのホスティングに使用される事からも分かるように、それだけで**独立したサービスとして動作する**ストレージであり、通常のPCで言うとDropBoxやGoogleドライブのような存在です

また、もう一つAWSでよく使用されるストレージに[**EFS**](https://aws.amazon.com/jp/efs/)が挙げられ、こちらはEBSのようにEC2にマウントでき、かつ複数のEC2インスタンスで共有ができるため、**NASに近い存在**と言えます (捉え方によってはS3とEBSの中間的な存在とみなせる)。またEFSはLambdaやFargate等のEC2以外のコンピューティングサービスでも使用できます。

その他、冗長化やデータの保持形式にも**以下のような差**があります
(共にKMSによる暗号化ができる等の共通点もあります)

||動作形態|デフォルトの冗長化方法|データ保持形式|
|---|---|---|---|
|**EBS**|EC2インスタンスと一緒に動作|単一AZ内で冗長化|[ブロックストレージ](https://www.redhat.com/ja/topics/data-storage/file-block-object-storage#%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%81%A8%E3%81%AF)|
|**S3**|単独のサービスとして動作|複数AZで冗長化|[オブジェクトストレージ](https://www.redhat.com/ja/topics/data-storage/file-block-object-storage#%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%81%A8%E3%81%AF)|
|**EFS**|EC2インスタンスにマウントされる事が多いが、他サービスからも利用可能|複数AZで冗長化|[ファイルストレージ](https://www.redhat.com/ja/topics/data-storage/file-block-object-storage#%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%81%A8%E3%81%AF)|

## EC2とネットワーク
EC2に外部からアクセスしようとすると、ネットワークの構築が不可欠となります。
ここではEC2と関連の深いネットワーク関係サービスについて解説します。

|名称|概要|
|---|---|
|[**VPC**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#vpc)|**AWS上で仮想ネットワークを構築**し、**セキュリティや耐障害性を向上**させる|
|[**ENI (Elastic Network Interface)**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#eni-elastic-network-interface)|インスタンスに**新たなIPアドレスを付与**する|
|[**Elastic IP**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#elastic-ip)|インスタンスに**固定のグローバルIPアドレスを付与**する|
|[**ELB (ロードバランサー)**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#elb-ロードバランサー)|**複数のインスタンスにアクセスを分散**させ、**可用性向上や負荷分散**を自動化する|
|[**Auto Scaling**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#auto-scaling)|**負荷に応じてインスタンス数を自動で変化**させ、**コストと性能のバランスを自動調整**する|
|[**プレイスメントグループ**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#プレイスメントグループ)|**複数のインスタンスをグループ化**し、**インスタンス間の通信速度や耐障害性を向上**させる|
|[**SSHによるアクセス**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#sshによるアクセス)|キーペアで公開鍵認証によるSSH通信でインスタンスに接続し、**外部からセキュアなインスタンスの操作**を実現する|

### VPC
**VPC** (Virtual Private Cloud)とは、**AWS上で仮想ネットワークを構築**できるサービス (EC2とは別のサービス)であり、**EC2も**基本的にはこの**VPC内に設置されて動作**します。

<img width=720 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/da2c781d-dd79-2c1a-e395-f9cf90a1aa6a.png">

デフォルト設定でEC2インスタンスを作成するとデフォルトのVPCが自動的に紐付けられるため、単体のEC2のみであればVPCを意識しなくとも使用自体はできてしまいますが、**ある程度複雑なシステム**を組もうとするのであれば、**VPCの知識は必ず必要となります**。

**詳細は以下の記事**にまとめたので、ぜひご参照下さい。

https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77

### ENI (Elastic Network Interface)
通常のPCにおいて、NICと呼ばれるLANポートを内蔵したカードを着脱することで、ネットワークの接続経路を増やしたり減らしたりする事ができます。

AWSでも同様に、**ENI** (Elastic Network Interface)と呼ばれるサービスを着脱 (**アタッチとデタッチ**)する事で、ネットワークへの接続経路、すなわち**インスタンスに付与されたIPアドレスの数を増やしたり減らしたりすること**ができます。
(1つのENIに複数のIPアドレスを付与することもできます)

ENIがないとネットワークにアクセスできないため、**EC2インスタンスにはデフォルトで1個ENIが付加**されていますが、さらにENIを追加することもできます (以下の記事のように複数のENIを付加するメリットは限られそうですが…)

https://j3tm0t0.hatenadiary.org/entry/20120410/1334086123

なお、後述のElastic IPやセキュリティグループは、厳密にはEC2インスタンスではなくENIに付与されているため、ENIのアタッチ・デタッチ時は再設定が必要となることにご注意ください。

#### ・EFA (Elastic Fabric Adapter)
ENIに高速化が施された、**EFA** (Elastic Fabric Adapter)と呼ばれるサービスも存在します。

大規模シミュレーションや機械学習等、高性能が求められる用途で**複数のコンピュータが連携して動作**する**HPC** (High Performance Computing)と呼ばれる処理方式に、このEFAは適しています。

以下の記事で詳細に検証されており、大変参考になります

https://tech.preferred.jp/ja/blog/aws-elastic-fabric-adapter-evaluation/

### Elastic IP
通常、EC2のインスタンスにおいてグローバルIPアドレスは動的に付与されるため、再起動するたびにIPアドレスが変わってしまいます。

これを防ぐため、**固定のグローバルIPアドレス**を割り振る機能が、Elastic IPアドレス(EIP)です。

詳細は以下の記事を参照ください

https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#elastic-ip

### ELB (ロードバランサー)
複数のサーバを並列に立ち上げ、アクセスを分散させることで負荷を軽減させる仕組みを**ロードバランサ**と呼びます。

AWSにおいては、**ELB** (Elastic Load Balancer)と呼ばれるロードバランサーがサービスとして提供されており、アクセスを複数のEC2インスタンス (あるいはFargateやRDSのようなサービス)に分散させることができます。

また、下図のようにELB (ALB)において分散先のインスタンスを**複数のAZに配置**することで、**冗長性の確保**を実現することもできます。

<img width=480 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/3038bcac-a256-70c9-709c-9e4e8f5d8d8e.png">

ELBの詳細については[別記事 (作成中)]()で解説します

### Auto Scaling
ELBで負荷分散をする場合、**インスタンスの数**が重要となります。

インスタンスの数が多いほど捌けるアクセス数が増えて性能が向上しますが、その分コストも増大するため、**コストと性能のバランスを取ってインスタンスの数を調整**する事が望ましいです。

このような需要に対応するため、**負荷に応じてインスタンスの数を動的に変化**させ、**コストと性能のバランスを自動調整**するサービスが、**EC2 Auto Scaling**です。

<img width=600 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/c9b44e8f-3702-4907-f453-37ac73330ad4.png">

Auto Scalingの詳細については[別記事 (作成中)]()で解説します

### プレイスメントグループ
物理的位置が遠いマシンと近いマシンでは、基本的に後者の方が通信速度(厳密には「行って帰ってくるまでの時間=RTT, レイテンシー」)が早くなります。

同様にAWSにおいても、複数のインスタンスをグループ化してRTTが小さくなるよう配置することで、同一AZ内の**インスタンス同士の通信速度を向上**させる**プレイスメントグループ**と呼ばれる機能が存在します。

プレイスメントグループでは、**以下の3種類のグルーピング方法**を選択する事ができ、「パーティション」と「スプレッド」は速度だけでなく耐障害性も向上させる事ができます。

|名称|配置|用途|
|---|---|---|
|クラスター|グループ内のRTTが小さくなるようインスタンスを配置|速度重視 (低レイテンシー、高スループット)|
|パーティション|インスタンスをパーティション単位で分け、パーティション同士がラックと電源を共有しないよう配置|速度と耐障害性のバランス|
|スプレッド|全てのインスタンスがラックと電源を共有しないよう配置|耐障害性重視|

<img width=720 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/c4bb32a4-2d3b-1a40-cd29-68a113c47319.png">

プレイスメントグループにより具体的にどの程度速度が向上するかは、以下の記事で詳細に検証されています。
(スプレッドは一見耐障害性のみを向上させる方式に見えますが、速度も向上するようです)

https://dev.classmethod.jp/articles/ec2-placement-group-strategy/

なお、プレイスメントグループの注意点としては以下が挙げられます。ご注意ください

- 既存のインスタンスを後からプレイスメントグループに追加する事はできない(インスタンス起動時に追加が必要)
- [一部のインスタンスタイプはプレイスメントグループを適用できない](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/placement-groups.html#concepts-placement-groups)(例えばデフォルトのT2インスタンスは適用不可)

### SSHによるアクセス
SSH (Secure SHell)とは、暗号化通信を実現するためのプロトコルの一つです。

主に**サーバーの遠隔操作目的**で使用され、EC2においても**インスタンス内部を操作する際に第1の選択肢**となる接続手法です。

SSHでPCからEC2インスタンスにアクセスするために、以下のようにデフォルトのコマンドラインツールが使用できます。

- Mac, Linux(Ubuntu)の場合 → ターミナルを使用
- Windowsの場合 → コマンドプロンプトまたはPowerShellを使用

(よく「WindowsではSSH接続に[Tera Term](https://ja.osdn.net/projects/ttssh2/)が必要」という記述を見ますが、Windows2018年以降のWindows10ではOpenSSHというSSH接続ソフトがプリインストールされたため、デフォルトのツールでアクセス可能となりました)

なお、SSH接続にはTCP22番ポートを使用するため、**セキュリティグループ等のファイアウォール機能でTCP22番ポートを開ける必要**があります

#### ・公開鍵認証とキーペア
SSHを使用することでインスタンスを遠隔操作する事ができるため、誰からでもアクセスできてはセキュリティ的に危険です。

そこで、**限られた人だけがインスタンスにアクセスできる**ようにするための**認証**と呼ばれる仕組みが必要となります。

SSHにおいては、**公開鍵認証**と呼ばれる、
「公開鍵と秘密鍵の2つの鍵を作って公開鍵をサーバーに設置し、**秘密鍵を持っているユーザーだけがサーバーにアクセスできる**」
という仕組みで、認証(クライアント認証)を実現することが一般的です。
公開鍵認証については以下の記事が参考になります。

https://knowledge.sakura.ad.jp/3543/

AWSにおいては、公開鍵認証に[後述のキーペア](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#キーペア)を使用します


## EC2のセキュリティ機能
[冒頭](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#amazon-ec2とは)で「EC2はクラウド上に立ち上げたPCのようなもの」と述べましたが、PCと同様に**セキュリティを疎かにすると様々な攻撃を受け**、**非常に危険**です。これを防ぐためにセキュリティ対策は必須と言えます。

コンソールには以下の2機能が準備されていますが、これらは最低限の機能であり対策としては不十分なため、[**IAMによるポリシー設定**](https://qiita.com/c60evaporator/items/0121399880625cc1de51)と[**VPCのセキュリティ機能の活用**](https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#vpcのセキュリティ機能)も**併せて活用**してください。

|名称|概要|
|---|---|
|[**EBSとスナップショットの暗号化**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ebsとスナップショットの暗号化)|EBSやそのバックアップであるスナップショット内のデータを**暗号化**し、**機密性を向上**させる|
|[**キーペア**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#キーペア)|キーペアで公開鍵認証によるSSH通信でインスタンスに接続し、**外部からセキュアなインスタンスの操作**を実現する|
|[**セキュリティグループ**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#セキュリティグループ)|**ネットワーク上のアクセス制御**により**セキュリティを向上**させる(ファイアウォールの役割)|
|[**EC2 Image Builder**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2-image-builder)|**ネットワーク上のアクセス制御**により**セキュリティを向上**させる(ファイアウォールの役割)|

### EBSとスナップショットの暗号化
**EBS内のデータ**はデフォルトでは暗号化されていませんが、**簡単な設定で暗号化を実現**し、セキュリティレベルを高める事ができます。

EBSの暗号化は、AWSの暗号鍵管理サービスである[**KMS**](https://aws.amazon.com/jp/kms/)の鍵を利用し、[AES-256](https://ja.wikipedia.org/wiki/Advanced_Encryption_Standard)アルゴリズムで実行されます。
(S3の暗号化方式の一つである[SSE-KMS]()と近い仕組みになっています)

また、**暗号化されたEBSから作成されたスナップショットも同様に暗号化されます**。

EBSを暗号化するには、[インスタンス起動時]()の「ストレージ」設定で下図のように暗号化を有効化するか

<img width=400 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/9b0a8dbb-0692-baeb-f814-d6c82b1d1358.png">

EBSボリュームを直接作成する場合は、以下のように「このボリュームを暗号化する」をチェックし、暗号化に使用するキーを指定します

<img width=400 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/5f21ecde-af4c-bc97-04f4-563840905658.png">

#### ※AWS管理キー (aws/ebs)
EBSの暗号化で使用できるキーとして、ユーザが独自に作成したKMSキー(カスターマーキー)以外に、デフォルトで準備された**AWS管理キー** (**aws/ebs**)が準備されています。

このAWS管理キーを使用することで**KMSキーのポリシー管理が不要**となるため、管理の手間を減らす事ができます。

カスタマーキーとAWS管理キー(AWSキー)の違いは、以下の公式ドキュメントを参照下さい

https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/concepts.html#key-mgmt

### キーペア
キーペアとは、EC2インスタンスへの接続において、[前述の**公開鍵認証**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#公開鍵認証とキーペア)に使用する**鍵**を指します。

公開鍵をサーバー側で保持し、秘密鍵(.pemという拡張子)をクライアント側で保持することで、公開鍵認証によるSSH接続を実現できます。

なお、通常のオンプレサーバーで使用される公開鍵との違いとして、**以下に注意が必要**です

- 通常のオンプレサーバーではクライアント側で鍵を生成するが、**キーペアでは**サーバー側(**AWS側**)で**鍵を生成**
- 秘密鍵のAWSからの**ダウンロードは一度しか実施できない**(鍵を無くしたらキーペアの再生成が必要)

また、通常のオンプレサーバーと同様に、公開鍵と秘密鍵の特性から以下が成り立ちます。

- **秘密鍵**(.pemファイル)を**複数クライアントで共有する事は避けるべき**
- **公開鍵**(インスタンス立ち上げ時に選ぶ鍵)を**複数インスタンスで共有するのはOK**

<br>

### セキュリティグループ
セキュリティーグループとは、**インスタンスをグルーピング**して**IPアドレスとポート番号に基づくアクセス制限**を設定することで、ファイアウォールのようなアクセス制御を実現する機能です。

セキュリティーグループは厳密にはVPC内の機能のため、詳細は以下の記事をご参照下さい

https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#セキュリティグループ

<br>

### EC2 Image builder
作成した**AMIを長期間放置**すると、内部のOSやパッケージに**パッチや更新が適用されず**、脆弱性が放置されて**セキュリティ的に危険な状態**となります。

このような事態を防ぐために、**最新バージョンのパッケージがインストールされたAMIを自動で作成・展開**できる**EC2 Image builder**と呼ばれる機能が準備されています。

詳細は以下の機能が分かりやすいです。

https://dev.classmethod.jp/articles/ec2-image-builder/


## EC2とバックアップ
EC2インスタンスをサービスに利用する場合、耐障害性等を考慮すると**定期的にバックアップを取ることが望ましい**です。

バックアップには[**AMI**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ami-os)と[**スナップショット**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#スナップショット)の**2種類の方法**があり、これら**バックアップを自動取得**するための**ライフサイクルマネージャー**や**AWS Backup**という機能を使用すると便利です。

まずはAMIとスナップショットによるバックアップの違いについて解説します。

### AMIとスナップショットの使い分け
バックアップ方法として**AMIを使用する場合とスナップショットをどう使い分けるか**について考えてみます。
(なお、スナップショットを取得できるのはEBS使用時のみなので、ここではインスタンスストアは考えない事とします)

結論から言うと、元あったインスタンスの中身を再現するためには、**AMIとスナップショット両方を取得する必要**があります
AMIとスナップショットは以下のように保持している情報が異なり、両者が揃って初めて元のインスタンスの構成情報を再現できるからです ([こちらの記事](https://aws.taf-jp.com/blog/26786)も参考になります)

|種類|保持している情報|
|---|---|
|**AMI**|インスタンスの構成情報(アーキテクチャ＋紐づいたスナップショット等)|
|**スナップショット**|EBS内のデータ(OSの実イメージ＋後からインストールされたソフト等)|

AMIはスナップショットの紐付け情報も保持しているため、**AMIはスナップショットを内包する存在**とみなすこともできます。

<img width=360 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/4c00dfd8-33e9-04f6-0436-eb0451e55e63.png">

よって**実用上はAMIのみを取得**することでスナップショットを兼ねる事ができ、両者を別個にバックアップする必要は低いと言えます 
(以下のようにAMI作成画面には同時にスナップショットを取得する機能が存在します。

<img width=720 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/b6f5aa1d-90fd-68e6-1999-1b28c6724cef.png">

また、AMIもスナップショットもインスタンスタイプやネットワーク等の情報は保持していないため、これらを[後述の起動テンプレート](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#起動テンプレート)として保存しておくと、より迅速なインスタンスの復旧が実現できます。

一方で[後述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ライフサイクルマネージャー)ライフサイクルマネージャーで**バックアップを自動化する場合**は、より**更新頻度の高いスナップショットを高頻度に、それほど頻繁に変化のないAMIは低頻度に取得しても良い**かと思います。

スナップショット、AMIをバックアップとして使用する際の注意点について簡単に解説します

#### ・スナップショットの注意点
スナップショットをバックアップとして利用する場合、以下にご注意ください

- スナップショットの作成と復元は有料([後述](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ボリュームのコスト))
- スナップショットはリージョンごとに固有なので、リージョンごとに別個に取得が必要(ただし、[他のリージョンにコピーする機能](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html)がある)
- スナップショットを[他のアカウントと共有](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html)することもできます

スナップショットの詳細や作成法は、以下の公式ドキュメントが参考になります。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSSnapshots.html

#### ・AMIの注意点
AMIをバックアップとして利用する場合、以下にご注意ください

- 作成したAMIを長期間放置するとセキュリティパッチ等が当たらずに危険なので、前述の[**EC2 Image builder**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2-image-builder)で**定期的に中身を更新**する事が推奨されます
- AMIはリージョンごとに固有なので、リージョンごとに別個に取得が必要(ただし、[他のリージョンにコピーする機能](https://aws.amazon.com/jp/premiumsupport/knowledge-center/copy-ami-region/)がある)
- AMIを[他のアカウントと共有](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/sharingamis-explicit.html)することもできます

### ライフサイクルマネージャー
ルール(ポリシー)に基づき**インスタンスのバックアップ作成を自動化**するための機能です。

[前述のように](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2とバックアップ)インスタンスのバックアップには**AMIとスナップショットの2種類**が存在しますが、**本機能ではいずれかを選択することができます**。

例えば、「毎日○時にスナップショットによるバックアップを作成する」というポリシーを作成する事ができます。
具体的な設定方法は以下の記事をご参照ください

https://dev.classmethod.jp/articles/ec2-snapshot-by-amazon-dlm/

### AWS Backup
**ライフサイクルマネージャーと似たサービス**として、**AWS Backup**が挙げられます。

ライフサイクルマネージャーがEC2の一機能であるのに対し、AWS Backupは単独のサービスとして提供されているため、**EC2以外のサービスのバックアップ** (RDS, EFS, DynamoDB等)にも対応しています。

以下の記事で両者を比較されていますが、記事中でAWS Backupのメリットとして挙げられているAMIのバックアップ機能は、2020年末に[ライフサイクルマネージャーも対応](https://aws.amazon.com/jp/about-aws/whats-new/2020/11/ami-lifecycle-management-available-data-lifecycle-manager/)したため**EC2のバックアップ用であれば両者に大きな違いはなさそう**です。

https://tech.katomoh.net/difference-between-awsbackup-and-dlm/

[世代管理の方法](https://dev.classmethod.jp/articles/how-aws-backup-and-amazon-dlm-manages-backup-lifecycle/)に差があったり、AWS BackupはAMIには含まれないインスタンスタイプ等の情報も保持してくれるようですので、これらの要件や他のサービスとの併用の有無 (RDS等と併用するのであればAWS Backupの方が便利そうです)を考慮して、どちらを使用するか決定するのが良いかと思います。

(私見としては、インスタンスタイプ等を保持可能なAWS Backupの方がやや汎用性が高そうに感じます)

<br>

## その他のEC2関連機能
ここまで紹介したネットワーク、セキュリティ、バックアップ関係の機能以外にも、EC2には以下のような便利な機能が存在します

|名称|概要|
|---|---|
|[**起動テンプレート**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#起動テンプレート)|**インスタンス起動時の設定をテンプレート登録**し、**次回以降の入力を簡略化**|
|[**専有ホスト (Dedicated Hosts)**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#専有ホスト-dedicated-hosts)|**1台の物理サーバを1人のユーザで専有**し、**ソフトウェアライセンスの持ち込み**や**該当するセキュリティ要件への対応**を実現する|
|[**キャパシティの予約**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#キャパシティの予約)|キャパシティ(計算資源)の確保により起動エラーを防ぎ、**特定の期間インスタンスの確実な起動を確保**する|

### 起動テンプレート
インスタンスの起動時には、前述の[AMI](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ami-os)、[インスタンスタイプ](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスタイプ)、[ストレージ](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ストレージ-ebs)等様々な設定を適用することができます ([具体的な設定法は後述](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2の使用法))

一方で、**同じ設定のインスタンスを複数起動**したい場合、上記の設定を毎回入力していては面倒です。
そこで、**インスタンス起動時の設定**を「**起動テンプレート**」として登録することで、**次回以降の設定入力を簡略化**することができます。

この起動テンプレートは[**Auto Scaling**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#auto-scaling)使用時は**ほぼ必須**とも言える機能で、Auto Scalingグループ内のすべてのインスタンスに本機能で作成した**設定を渡す**ことができます。

起動テンプレートの作成方法は、以下の記事で詳細解説します

[Auto Scalingの記事 (作成中)]()

### 専有ホスト (Dedicated Hosts)
通常、AWSのようなIaaSでは1台の物理サーバを複数台の仮想サーバで共有しており、ひいては**複数のAWSアカウントのユーザが1台の物理サーバを共有**した状態となっていることが多いです。

一方で、[**専有ホスト**](https://aws.amazon.com/jp/ec2/dedicated-hosts/)では、**1台の物理サーバを1人のユーザで専有**することができ、

- **ユーザ独自のソフトウェアライセンスの持ち込み** (AWSで提供されていないOS等)
- **コンプライアンス**（セキュリティ要件）上他者と同じサーバでの動作を避けたい場合

**等の用途**に用いられます。

#### ・ハードウェア専有インスタンス
専有ホストと似たサービスに[**ハードウェア専有インスタンス**](https://aws.amazon.com/jp/ec2/pricing/dedicated-instances/)が挙げられます。

ハードウェア専有インスタンスも「同一物理サーバ上で他ユーザのインスタンスが起動しないこと」が保証されるという意味で専有ホストと共通していますが、あくまで**インスタンス単位**のサービスのため、ホスト(物理サーバ)単位で提供を受けられる専有ホストと比べると、**以下の制約**が生じます。

||専有ホスト|ハードウェア専有インスタンス|
|---|---|---|
|課金単位|ホスト(物理サーバ)単位|インスタンス単位|
|ホスト単位のソフトウェアライセンス持ち込み|可能|不可|
|ホスト内でのインスタンスの起動場所|ユーザ側で制御可能|ユーザ側で制御不可(AWS側で自動決定)|
|ソケット、コア、ホストIDの可視性|あり|なし|
|停止インスタンスの再起動時の使用ホスト|同一ホストが保証される|他のホストに移ることもある|

基本的には
**ハードウェア専有インスタンスより専有ホストの方が、ユーザ側で利用する際の自由度が高い**
と認識すれば良いかと思います。


### キャパシティの予約
**ある期間インスタンスを立ち上げられる権利**を予約するサービスが、**キャパシティ予約**です。

「立ち上げられる権利」と言うと分かりづらいですが、インスタンスの立ち上げ時には稀に`InsufficientInstanceCapacity`と呼ばれるキャパシティ不足に由来するエラーが発生し、インスタンスの立ち上げに失敗します。
手動立ち上げであれば再度立ち上げを実施すれば良いのですが、自動で立ち上げを設定している場合、失敗に気付けずに長時間に渡りインスタンスが停止、ひいては提供するサービスの停止に繋がってしまうこともあります。

このInsufficientInstanceCapacityエラーを防ぐためにキャパシティ(物理サーバ等の計算資源)を確保し、**特定の期間インスタンスの確実な起動を確保**するサービスが、**キャパシティの予約**です。

キャパシティの予約は、対応するインスタンス購入方式に応じて以下から選択します

|名称|対応するインスタンス購入方式|
|---|---|
|オンデマンドキャパシティ予約|オンデマンドインスタンス|
|キャパシティ予約|リザーブドインスタンス|

※最もオーソドックスなオンデマンドインスタンス用の名称が「キャパシティ予約」となっていないのは、本サービスが元々リザーブドインスタンス用のみに提供されていたことに由来します

<br>
<br>

# EC2のコスト
EC2でついやってしまいがちなのが、「**不要なインスタンスを利用し続けて請求料金が跳ね上がる**」事です。
何ヶ月も放置すると数万円程度はすぐに到達するので、個人利用者にとっては痛い出費となり、「**クラウド破産**」と揶揄されることもしばしばあります。

どこにコストが掛かるのかを把握した上で、コストと性能とのバランスを監視・分析・最適化していくことは、EC2のみならずクラウドを活用する上で最重要項目の一つとなります。

本記事では、EC2の「**コストの決定手順**」および「**コスト監視・最適化のためのTips集**」について解説します。

## コストの決定手順
EC2の利用コストは、以下のように決まります

**EC2の利用コスト = 
「インスタンス自体のコスト」 + 
「データ転送のコスト」 + 
「ボリュームのコスト」 + 
「その他のコスト」**

それぞれ解説します。

### インスタンス自体のコスト
**インスタンスの起動時**は、**以下の要素に応じてコストが発生**します。
(インスタンス**停止中・休止中**はこのコストは**発生しません**)

|名称|概要|
|---|---|
|[インスタンスのタイプ](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスのタイプ)|[前述のインスタンスタイプ](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスタイプ)|
|[インスタンスの購入方式](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスの購入方式)|同タイプのインスタンスでも3種類の購入方式により価格が変わる|
|[リージョン](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#リージョン)|リージョンにより価格が変わる|

具体的なコストは、「インスタンスの購入方式」で後述する[**料金表**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスの購入方式)を使用することで、大まかな価格を掴むことができます。

とはいえ、**料金に縛られすぎて本来クラウドで実現したい機能を制限**してしまっては**本末転倒**なので、基本的には**使いながら逐次料金を確認**して調整するのが良いかと思います。

それぞれ詳説します

#### ・インスタンスのタイプ
[前述のインスタンスタイプ](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスタイプ)により料金が変わります。

基本的には高性能なタイプほど高価なので、コストと性能のバランスを見て選択します。

#### ・インスタンスの購入方式
同じタイプのインスタンスでも、**以下の4種類の購入方式により料金が変わります**

|名称|課金体系 (リンク先に料金表)|適した用途|
|---|---|---|
|オンデマンドインスタンス|[使用時間に応じて、秒単位※の固定額で課金される](https://aws.amazon.com/jp/ec2/pricing/on-demand/)|通常はこちらを使用|
|リザーブドインスタンス|[1or3年単位で固定額で課金される](https://aws.amazon.com/jp/ec2/pricing/reserved-instances/pricing/)（時間あたり価格はオンデマンドより安い）|本番環境等の、長期稼働が確定したシステム|
|Saving Plans|[1or3年単位で最低利用額が定められる](https://aws.amazon.com/jp/savingsplans/compute-pricing/)、オンデマンドとリザーブドの中間的な契約方式|長期稼働が予想されるシステム|
|スポットインスタンス|[入札制で需給に応じて価格が決まる](https://aws.amazon.com/jp/ec2/spot/pricing/)<br>入札価格より相場が高くなると突然インスタンスが落ちる|突然落ちても良い用途で、コストを削減したい場合に使用|

※Linux以外のインスタンスは秒単位ではなく時間単位の課金です

リザーブドインスタンスやSavingPlansは**長期稼働**、スポットインスタンスは**入札相場の逐次確認＆突然落ちるリスクの受容**が必要となり、これらが強い制約となってしまうため、基本的には**初心者であればオンデマンドを選択**するのが無難です。

とはいえ、いずれも適切に利用すれば利用料金を半額以下にする事も可能なので、慣れてきたら積極活用しても良いかと思います。

リザーブドインスタンス、Saving Plans、スポットインスタンスについて簡単に解説します

##### - リザーブドインスタンス
1年、または3年単位でインスタンスを**長期契約**することで、時間当たりの契約額を大幅(34〜72%)に削減することができます。

本番環境等、長期でインスタンスを連続使用することが確定している用途に向いた契約方式と言えます。

途中で**インスタンスファミリーやOSを変更不可**の「**スタンダード**」と、**変更可能**な「**コンバーティブ**ル」が存在します。スタンダードの方が料金は安いので、**途中変更があるかどうかに応じて**どちらを購入するか選択してください。

また、購入したリザーブドインスタンスを途中で使用しなくなった場合、[**マーケットプレイス**](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ri-market-general.html)でインスタンスを売却することもできます。

##### - Savings Plans
**オンデマンドとリザーブドの中間的**な契約方式として、1 or 3年の期間で一定の使用量(USD/時間)を契約する代わりに割引が適用される**Savings Plans**という契約方法も存在します。

リザーブドインスタンスが「期間内ずっとインスタンスを起動し続ける」事を前提としているのに対し、Savings Plansは「期間内ずっと、1時間あたり最低◯ドル分インスタンスを使用する」という、**最低使用量が定められる**サービスとなります。

具体的には、**以下のルールが適用**されます (昔の携帯電話料金の「無料通話分」のシステムに近いです)

・実際の使用量が最低使用量を下回った場合、最低使用量に相当する料金が請求される
・最低使用量を超過した分は、通常のオンデマンドインスタンスの料金が適用される

EC2以外にもLambdaやFargateのようなサーバーレス向けサービスにも適用できます。
詳細は以下を参照ください。

https://aws.amazon.com/jp/savingsplans/compute-pricing/

##### - スポットインスタンス
AWSが予備用に保持しているインスタンスを、入札制で利用できるサービスです。

多くの場合オンデマンドと同等のインスタンスを低価格で利用する事ができますが、「相場によってはオンデマンドより高くなることもある」「**入札価格より相場が高くなると突然インスタンスが落ちる**」等のリスクがあり、**取り扱いに注意が必要な上級者向けサービス**と言えます。

スポットインスタンスに、[スポットフリート](https://dev.classmethod.jp/articles/auto-scaling-for-ec2-spot-fleets/)や[EC2フリート](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-fleet.html)のように**複数のインスタンスをまとめて制御・購入**する仕組みが存在するため、**戦略次第ではインスタンスが落ちるリスクとコスト両者を抑える**ことができます（具体的な戦略は**以下のサイトが参考**になります）

https://logmi.jp/tech/articles/321685


#### ・リージョン
リージョンにより多少料金が変わります（バージニア北部リージョンが安めです）

リージョンごとの料金も、[「インスタンスの購入方式」](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスの購入方式)のリンク先にある料金表で確認可能です

### データ転送のコスト
基本的には、以下の料金が掛かります

|通信経路|コスト|
|---|---|
|インターネットからEC2への通信 (内向き)|無料|
|EC2からインターネットへの通信 (外向き)|通信量に応じて課金 ($0.11/GB前後)|
|EC2から他リージョンへの通信|通信量に応じて課金 ($0.09/GB前後)|

具体的な料金表は以下のリンク「データ転送」を参照ください

https://aws.amazon.com/jp/ec2/pricing/on-demand/#Data_Transfer


### ボリュームのコスト
EC2と一緒に作成されるボリューム([EBS](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ストレージ-ebs))にも、以下の料金が発生します

|名称|コスト|
|---|---|
|EBS ボリューム|利用時間とボリューム容量に応じて課金|
|EBS スナップショット|S3へのバックアップ作成時＆復元時に課金|

具体的な料金表は以下のリンクを参照ください

https://aws.amazon.com/jp/ebs/pricing/

その他、以下の情報を知っていると便利です

- EBSでなく[インスタンスストア](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスストア)を使用している場合はボリュームのコストは掛かりません (インスタンス自体のコストに含まれる)
- スナップショットを長期保管(90日以上保持)したい場合、[EBS Snapshots Archive](https://dev.classmethod.jp/articles/reinvent2021_ebs_snapshot_archive/)という機能を使う事で、バックアップのコストを削減できます

### その他のコスト
その他、EC2と併用される以下のサービスにもコストが掛かります。
紐付けた**EC2インスタンスを削除してもこれらのサービスが残り、課金される事もあるのでご注意**ください。

|サービス名|コスト (リンク先に料金表)|
|---|---|
|[Elastic IP](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#elastic-ip)|実行中のインスタンスに紐づけられれたElastic IPは無料<br>[2個目以降または実行中のインスタンスに紐づけられていないElastic IPは時間課金](https://aws.amazon.com/jp/ec2/pricing/on-demand/#Elastic_IP_Addresses)|
|[キャリアIPアドレス](https://qiita.com/mksamba/items/9a45a666ae938053fa72)|[AWS WavelengthのIPアドレス](https://aws.amazon.com/jp/ec2/pricing/on-demand/)|
|[Elastic Load Balancing<br>(ELB)](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#elb-ロードバランサー)|[ロードバランサの種類に応じて時間課金](https://aws.amazon.com/jp/elasticloadbalancing/pricing/)|
|[オンデマンドキャパシティー予約](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#キャパシティの予約)|[対応するEC2インスタンスと同価格](https://aws.amazon.com/jp/ec2/pricing/on-demand/#On-Demand_Capacity_Reservations)|
|[Amazon CloudWatch](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html)|[利用時間に応じて時間課金](https://aws.amazon.com/jp/cloudwatch/pricing/)。課金体系が複雑なので、リンク中の「料金の例」に記載されたユースケースが参考になる|

その他、NATゲートウェイやエンドポイント等の**VPC関連サービス**にもコストが掛かります。詳しくは[こちらの記事](https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#vpcと外部ネットワークサービスとの接続)を参照ください（記事中の「外向き通信量に課金」は本記事の「データ転送のコスト」と同内容のため、2重課金はされません）


## コスト監視・最適化のためのTips集
EC2は起動時間に応じて課金されるため、**長期継続運用**するとインパクトのある金額が請求される事も多く、**コストダウン施策が事業上の競争力向上に繋がりやすい**サービスと言えます。

よってコストを監視して最適化するための仕組み作りが重要となるため、本用途で有用な機能・サービスを紹介したいと思います。

### インスタンスの消し忘れ防止
EC2インスタンスを使用し終わったにも関わらず**停止・終了し忘れた状態で放置**すると、数ヶ月で結構な額 (数万円オーダー)に到達します。
よくTwitter等で笑い話にされていますが、油断していると自分がやらかしてしまう王道パターンで、私もやらかした事があります。
(特に**普段使用しないリージョン**でインスタンスを消し忘れると、本当に気付けません)

以下の記事に消し忘れ防止のためのTipsがまとめられているので、不安な方はご参照ください

https://dev.classmethod.jp/articles/cost-check-tool/

### AWS Budgets
予め予算 (例: 月額5000円)を決めた上で、「予算の80%を超えたらメール通知」「Savings Plansの使用率がしきい値を下回ったらSNS通知」のような**きめ細やかなアラート通知**を実現できるのが、AWS Budgetsです。

「定期的にコストを確認」という人間の注意力に頼った確認方法はだいたいどこかでグダグダになって機能しなくなるので、**ピンポイントでコストが増大した場合だけ通知**してくれる本機能は、再現性のあるコストマネジメント手法として非常に役に立つでしょう

https://aws.amazon.com/jp/aws-cost-management/aws-budgets/

### AWS Cost Explorer
PC版のコンソールから費用を確認する方法は多数存在しますが、個人的には綺麗なグラフでUI表示できる[Cost Explorer](https://aws.amazon.com/jp/aws-cost-management/aws-cost-explorer/)がお気に入りです。
詳細は以下の記事がわかりやすいです

https://dev.classmethod.jp/articles/analyze_awsfee_by_costexplorer/

### AWS Console スマホアプリ
以下のAWS公式のコンソールスマホアプリをダウンロードすれば、スマホからサービス毎の利用料金を確認できます。
(Cost Explorerとほぼ同様のグラフ表示で確認可能です)

料金確認のためにいちいち多要素認証のPCのアプリを開くのは非常に面倒なので、スマホアプリを利用する事で料金確認を簡単に高頻度に実施し、結果として消し忘れに早く気づける可能性

https://play.google.com/store/apps/details?id=com.amazon.aws.console.mobile&hl=ja&gl=US

https://apps.apple.com/jp/app/aws-console/id580990573

### EC2 Global View
後述の[EC2 Global View](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2-global-view-1)を利用すれば全リージョンのEC2インスタンスを確認できるので、前述の「普段使用しないリージョンの消し忘れたインスタンス」に気づく上で有用なツールとなるでしょう


<br>
<br>

# EC2コンソール画面の見方
AWSコンソールにログインしてEC2に入ると、以下のような画面が表示されます。

<img width=960 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/f114b2c8-3ff7-7928-4fd8-d5013d6e0e05.png">

「EC2ダッシュボード」は、現在のアカウントがリージョン内に保持しているEC2リソースが一覧表示されています。

「左側のタブ」（ナビゲーションペイン）からはEC2**各リソースの設定画面**に飛べるので、それぞれ簡単に解説します

## EC2 Global View
全リージョンのVPCリソースおよびEC2インスタンスの数が一覧表示されます。
**他のリージョンの情報**も含め簡易的に確認したい場合や、消し忘れたインスタンスが存在しないかの確認に便利です

<br>

## イベント
AWSでは、セキュリティパッチ適用などの理由により、**インスタンスの再起動や停止等のメンテナンスイベント**が発生する事があります。

このようなイベントの対象となるインスタンスを、**一覧表示**するのが本タブです。
(本タブでの表示とは別に、AWSアカウントに関連付けられたメールアドレスへEメールによる通知も行われます)

なお、イベントの実施日時は完全に固定なわけではなく、以下のようにある程度の日時変更を要求する事ができるようです。

https://dev.classmethod.jp/articles/reschedule-amazon-ec2-scheduled-events/

<br>

## タグ
インスタンスを始めとしたEC2リソースに割り当てたタグ (`Name`等)を一覧表示・管理・追加します。

タグに関する詳細は、以下の公式ドキュメントを参照下さい

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/Using_Tags.html

また、以下のEC2ベストプラクティスの記事も参照下さい

https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a

<br>

## 制限
**インスタンス等のリソース数**には、**リージョン毎に上限**が設けられています。
本タブでは、これらリソース数の上限を以下のように一覧表示する事ができます。

<img width=720 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/75ffe7b3-7227-e476-08c0-1ceccad7484a.png">

例えばVPCの上限数「5」等は、ある程度のヘビーユーザーであれば十分到達しうる数のため、上限を把握しておく事が重要となります。

これら上限は申請により引き上げる事ができますが、実際に引き上げが適用されるまでにはタイムラグが存在するため、**現在のリソース数と上限値を逐次確認**し、**制限の引き上げが必要となる前に計画**する事が推奨されています

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-resource-limits.html

## インスタンス
### インスタンス
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスの購入方式)オンデマンドインスタンスの起動、一覧表示、設定を行います。
実際の起動法は[「EC2の使用法」](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2の使用法)を参照ください

### インスタンスタイプ
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスタイプ)インスタンスタイプのうち、現在有効なものを確認することができます。

### 起動テンプレート
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#起動テンプレート)起動テンプレートの作成、一覧表示、設定を行います。

### スポットリクエスト
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#--スポットインスタンス)スポットインスタンスの購入、一覧表示、設定を行います。

### Saving Plans
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#--savings-plans)Saving Plansの購入を行います。

### リザーブドインスタンス
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#--リザーブドインスタンス)リザーブドインスタンスの購入、一覧表示、設定を行います。

### 専有ホスト (Dedicated Hosts)
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#専有ホスト-dedicated-hosts)専有ホストの起動、予約、一覧表示、設定を行います。

### キャパシティの予約
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#キャパシティの予約)キャパシティの予約の作成、一覧表示、設定を行います。

<br>

## イメージ
### AMI
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ami-os)カスタムAMIの作成、一覧表示、設定、あるいはAMIを用いたインスタンスの起動を行います。

### AMIカタログ
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ami-os)AWSデフォルトAMI、サードパーティAMI(Marketplace AMIとコミュニティAMIの2種類に分けられる)、カスタムAMIの一覧を閲覧する事ができます

<br>

## Elastic Block Store
### ボリューム
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ストレージ-ebs)EBSの作成、一覧表示、設定を行います。

### スナップショット
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#スナップショット)スナップショットの作成、一覧表示、設定を行います。

### ライフサイクルマネージャー
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ライフサイクルマネージャー)ライフサイクルマネージャーの作成、設定を行います。

## ネットワーク & セキュリティ
### セキュリティグループ
インスタンスへの**アクセス制限**を適用するためのセキュリティグループを、作成、一覧表示、設定します。

詳細は以下のVPCの記事を参照ください

https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#vpcのセキュリティ機能

### Elastic IP
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#elastic-ip)Elastic IPの作成、一覧表示、設定を行います。

### プレイスメントグループ
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#プレイスメントグループ)プレイスメントグループの作成、一覧表示、設定を行います。

### キーペア
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#キーペア)キーペアの作成、一覧表示、設定を行います。

### ネットワークインターフェイス
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#eni-elastic-network-interface)ENIの作成、一覧表示、設定を行います。

<br>

## ロードバランシング
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#elb-ロードバランサー)ELBの作成、一覧表示、設定を行います。

<br>

## Auto Scaling
### 起動設定
[前述の起動テンプレート](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#起動テンプレート)と同様にインスタンス起動時の設定を保持し、効率的に起動するための機能です。
2022年時点では利用が推奨されず、**代わりに起動テンプレートを利用する事が推奨**されています。

詳細は以下の記事が分かりやすいです

https://dev.classmethod.jp/articles/migration-a-launch-configuration-to-a-launch-template-for-auto-scaling/

### Auto Scaling グループ
[前述の](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#auto-scaling)Auto Scalingの作成、一覧表示、設定を行います。

<br>
<br>

# EC2の使用法
[**ベストプラクティスに極力合致**](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-best-practices.html)するよう**実際にEC2インスタンスを作成して運用**する方法を解説します。

長くなったので、別記事にて後日投稿します

[記事作成中]()