【2022年版】Amazon EC2 ベストプラクティス

# はじめに
以下の記事で紹介したように、**EC2**は**AWS上にOS付きの仮想マシン（VM）を作成**できるサービスであり、**多種多様なサーバー用途に**広く用いられています。

https://qiita.com/c60evaporator/items/06aa523c470d52782c7b

**EC2の利点**としては、オンプレサーバと比べて「環境構築、管理の手間が減らせること」、FargateやLambdaのようなサーバーレスサービスと比べて「**自由度が高い**」等が挙げられますが、自由度が高いゆえに**自己流の活用法でも何とかなって**しまい、

「**適切に活用できているか自信がない…**」

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/07fc3a48-302f-cd25-6003-3bac4270f81c.png)

といった方も多いかと思います。
そのような方のために、以下の**公式ベストプラクティス**が準備されています。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-best-practices.html

が、上記のベストプラクティス、解説が非常に簡潔で具体例も少なく、初学者には実践が難しいと感じたため、本記事では備忘録も兼ねて**具体例を交えて解説**したいと思います。

# ベストプラクティス一覧
[公式ベストプラクティス](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-best-practices.html)は、以下の項目に分かれています。

|分類|ベストプラクティス推奨事項|関連機能|
|---|---|---|
|セキュリティ|[**IDフェデレーション、IAMユーザー、IAMロールによるAWSリソースおよびAPIへのアクセス管理**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#idフェデレーションiamユーザーiamロールによるアクセス管理)|[IAM](https://qiita.com/c60evaporator/items/0121399880625cc1de51)|
|セキュリティ|[**セキュリティグループに対して、最小権限となるルールを適用**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#セキュリティグループに対して最小権限となるルールを適用)|[セキュリティグループ](https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#セキュリティグループ)|
|セキュリティ|[**定期的にインスタンスのOSやアプリケーションにパッチ処理、更新、および保護を適用**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#定期的にインスタンスのosやアプリケーションにパッチ処理更新および保護を適用)|[AMI](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ami-os)<br>[EC2 Image builder](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2-image-builder)|
|セキュリティ|[**Amazon Inspectorでインスタンス上のソフトウェア脆弱性や意図しない公開の有無をスキャン**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#amazon-inspectorでインスタンス上のソフトウェア脆弱性や意図しない公開の有無をスキャン)|[Amazon Inspector](https://dev.classmethod.jp/articles/re-introduction-2020-inspector/)|
|ストレージ|[**データの永続性、バックアップ、および復元に対するルートデバイスタイプの影響について理解する**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#データの永続性バックアップおよび復元に対するルートデバイスタイプの影響について理解する)|[EBS](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ストレージ-ebs)<br>[インスタンスストア](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスストア)|
|ストレージ|[**オペレーティングシステム用およびデータ用として個別にEBSボリュームを使用**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#オペレーティングシステム用およびデータ用として個別にebsボリュームを使用)|[EBS](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ストレージ-ebs)|
|ストレージ|[**インスタンスで一時データの格納に使用できるインスタンスストアを使用**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#インスタンスで一時データの格納に使用できるインスタンスストアを使用)|[インスタンスストア](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスストア)|
|ストレージ|[**EBS ボリュームとスナップショットを暗号化**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#ebsボリュームとスナップショットを暗号化)|[EBSとスナップショットの暗号化](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ebsとスナップショットの暗号化)|
|リソース管理|[**AWS リソースを追跡および識別するために、インスタンスメタデータおよびリソースのカスタムタグを使用します**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#aws-リソースを追跡および識別するためにインスタンスメタデータおよびリソースのカスタムタグを使用)|[タグ](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#タグ)<br>[コスト配分タグ](https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)<br>[タグベース認可](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_tags.html)|
|リソース管理|[**Amazon EC2 の現在の制限を表示**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#amazon-ec2-の現在の制限を表示)|[制限](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#制限)|
|リソース管理|[**AWS Trusted AdvisorでAWS環境を検査**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#aws-trusted-advisorでaws環境を検査)|[AWS Trusted Advisor](https://aws.amazon.com/jp/premiumsupport/technology/trusted-advisor/best-practice-checklist/)|
|バックアップと復旧|[**定期的にスナップショットを使用してEBSボリュームをバックアップし、インスタンスからAMIを作成**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#定期的にスナップショットを使用してebsボリュームをバックアップしインスタンスからamiを作成)|[ライフサイクルマネージャー](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ライフサイクルマネージャー)<br>[AWS Backup](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#aws-backup)|
|バックアップと復旧|[**複数のアベイラビリティゾーンにアプリケーションの重要なコンポーネントをデプロイし、データを適切にレプリケート**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#複数のアベイラビリティゾーンにアプリケーションの重要なコンポーネントをデプロイしデータを適切にレプリケート)|[ELB](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#elb-ロードバランサー)<br>[Auto Scaling](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#auto-scaling)<br>[RDSのマルチAZ構成](https://aws.amazon.com/jp/rds/features/multi-az/)<br>[S3クロスリージョンレプリケーション](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/replication.html#crr-scenario)|
|バックアップと復旧|[**インスタンスが再開したときに、動的なIPアドレスを処理するアプリケーションを設計**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#インスタンスが再開したときに動的なipアドレスを処理するアプリケーションを設計)|[Elastic IP](https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#elastic-ip)<br>[ELB](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#elb-ロードバランサー)<br>[Auto Scaling](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#auto-scaling)|
|バックアップと復旧|[**イベントを管理し、対応**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#イベントを管理し対応)|[Cloud Watch](https://aws.amazon.com/jp/cloudwatch/)|
|バックアップと復旧|[**フェイルオーバーを処理する準備が整っていることを確認**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#フェイルオーバーを処理する準備が整っていることを確認)|[ENI](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#eni-elastic-network-interface)<br>[Auto Scaling](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#auto-scaling)|
|バックアップと復旧|[**インスタンスとEBSボリュームを復元するプロセスを定期的にテストして、データとサービスの正常な復元を確認**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#インスタンスとebsボリュームを復元するプロセスを定期的にテストしてデータとサービスの正常な復元を確認)|[AMI](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ami-os)|
|ネットワーク|[**アプリケーションのTTL値をIPv4とIPv6で255に設定します**](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#アプリケーションのttl値をipv4とipv6で255に設定)|アプリケーション側で対応|

それぞれ**具体的な活用方法**を解説します

<br>
<br>

# セキュリティ関連
セキュリティに関連したベストプラクティスを解説します

<img width=160 src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/294bc9ba-ce96-2605-0423-20f8a6a558a1.png>

## IDフェデレーション、IAMユーザー、IAMロールによるアクセス管理
こちらはEC2というよりIAMのベストプラクティスに近く、EC2以外のサービスでも共通して意識すべき事項です。

EC2を始めとした**AWSサービスへのアクセス権限**付与は、基本的に**IAM**から実行されます。
よってAWS内のセキュリティ確保のため、[**公式のIAMベストプラクティス**](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html)を**理解して実践すること**が推奨されます。

詳細は**以下の記事**の「**IAMセキュリティのベストプラクティス**」にまとめたので、こちらをご参照下さい

https://qiita.com/c60evaporator/items/0121399880625cc1de51#iamセキュリティのベストプラクティス


## セキュリティグループに対して、最小権限となるルールを適用
こちらはEC2というよりVPCの機能における注意点となります。

[**セキュリティグループ**](https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#セキュリティグループ)とは、**VPC内のリソース (インスタンス)と外部との通信を制限**する機能であり、オンプレネットワークにおける**ファイアウォールに相当**します。

前述のIAMがホスト(AWSサービス)上でのセキュリティの要であれば、セキュリティグループは**ネットワーク上でのセキュリティの要**であり、適切に設定することで外部からの攻撃を遮断する事ができます。

具体的には、**以下の内容を理解・実践する事が推奨**されています

- **デフォルト**では25番ポート(SMTP=メール転送での踏み台防止)以外全ての[**外向き通信**](https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#外向き通信と内向き通信)を**許可する**
- セキュリティグループは[「**ホワイトリスト式**」(拒否ルールを作成できない)](https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#ファイアウォールとacl)と理解する
- セキュリティグループは[「**ステートフル**」(最初の要求パケットの方向のみを考慮)](https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#ステートフル)と理解する
- セキュリティグループのフィルタリングは「**外部側IPアドレス**」「**ポート番号**」[「**プロトコル**」](https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#プロトコルとは)に**基づくことを把握して設定**する
- **ルールの追加と削除は随時**行うことができ、**関連付けられたインスタンスに自動的に適用**される
- 複数のセキュリティグループをインスタンスに関連付けると、各セキュリティグループのルールが効率的に集約され適用される

詳細は以下の公式ドキュメントをご参照下さい

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/security-group-rules.html

**以下のVPCの記事**もご参照頂ければと思います

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

## 定期的にインスタンスのOSやアプリケーションにパッチ処理、更新、および保護を適用
サーバーには**パッチや更新ファイルを適用しないと**脆弱性が放置されて**セキュリティ上危険**ですが、これはEC2インスタンスでも同様です。

よって**パッチや更新ファイルを定期的に適用**する事が重要です。
例えばAmazon Linux OSのAMIを選択した場合、以下のように`sudo yum update`を実行してパッケージを一括更新します (**更新にはインターネットへの外向き通信許可=VPCのパブリックサブネットが必要**ですが、[**こちら**](https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#ゲートウェイエンドポイント経由でプライベートサブネットからyumコマンド実行)のような**裏技**もあります)

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/install-updates.html

また、[**EC2 Image builder**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2-image-builder)を使用することで**最新バージョンのパッケージがインストールされたAMIを自動で作成・展開**できるため、こちらを利用して更新を自動化する事も有効です。

## Amazon Inspectorでインスタンス上のソフトウェア脆弱性や意図しない公開の有無をスキャン
[**Amazon Inspector**](https://docs.aws.amazon.com/ja_jp/inspector/latest/user/what-is-inspector.html)とは、**インスタンス内の脆弱性や外部からのアクセス可能性を自動スキャン**するサービスです。
(EC2インスタンスだけでなく、ECR上のコンテナイメージもスキャン対象となります)

具体的には、以下の2項目を検査します ([参考](https://docs.aws.amazon.com/ja_jp/inspector/latest/user/findings-types.html))

- **脆弱性評価**: [CVE](https://www.ipa.go.jp/security/vuln/CVE.html)の最新情報に基づき脆弱性を検出し、[CVSS形式](https://www.ipa.go.jp/security/vuln/CVSS.html)で定量的に評価される。
- **ネットワーク到達可能性**: 外部からアクセスできるインスタンスを検出

有料のサービスですがそれほど高くはないので、セキュリティリスクを抑えたい用途では積極的に利用して良いかと思います。

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

https://dev.classmethod.jp/articles/re-introduction-2020-inspector/

<br>
<br>

# ストレージ関連
ストレージ (EBS, インスタンスストア)に関連したベストプラクティスを解説します

<img width=160 src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/317fe280-9cf7-6005-5115-4cc93f17615e.png>

## データの永続性、バックアップ、および復元に対するルートデバイスタイプの影響について理解する
[**EBS**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ebs)と[**インスタンスストア**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスストア)の**差を理解して適切に使い分ける**という事を表す項目です。

ざっくり言うと以下のように選択するのが適切かと思います

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

詳細は**以下の記事**の「**ストレージ (EBS)**」を参照下さい

https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ストレージ-ebs

## オペレーティングシステム用およびデータ用として個別にEBSボリュームを使用
EC2インスタンスには、複数のEBSボリュームをアタッチする事ができます。

デフォルトではOS用に1個のEBSボリュームがアタッチされており、これがデータ用のボリュームも兼ねています。
一方でこのベストプラクティスでは**OS用とデータ用で別個のEBSボリュームをアタッチ**することを推奨しています。

これにより、**インスタンス終了後**(OS用のルートボリュームはデフォルトで削除される)も**データ用のボリュームが保持**され、他のインスタンスにアタッチする事で**簡単に再利用**できます。

インスタンス終了後もボリュームを保持する方法の詳細は、以下の公式ドキュメントを参照ください

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/terminating-instances.html#preserving-volumes-on-termination

## インスタンスで一時データの格納に使用できるインスタンスストアを使用
インスタンスストアを使用する際は、[**データ消失リスクがある**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#インスタンスストア) (冗長性がない＆インスタンス停止時にデータが消える)**ことを把握**し、適切な用途 (一時ストレージ等)に使用する必要があります。

例えば、高速化等を目的として**インスタンスストアをデータベース用途で使用する場合**、ユーザー側で[**レプリケーションファクター**](https://www.networld.co.jp/sp/learn_first/backup/2nd/p28.html#:~:text=RF%20%EF%BC%88Replication%20Factor%EF%BC%89%E3%81%A8%E3%81%AF,%E3%81%A8%E3%81%84%E3%81%86%E8%A8%AD%E5%AE%9A%E3%81%AE%E3%81%93%E3%81%A8%E3%81%98%E3%82%83%E3%80%82)を設定して**耐障害性を確保**する事が推奨されています。

## EBSボリュームとスナップショットを暗号化
セキュリティレベルを高めたい場合、インスタンスに紐づけられたボリュームである**EBS**と、そのバックアップである**スナップショット**を**暗号化**する事が推奨されます。

詳細は**以下の記事**の「**EBSとスナップショットの暗号化**」を参照下さい

https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ebsとスナップショットの暗号化

<br>
<br>

# リソース管理
インスタンス等のリソースを管理しやすくするためのベストプラクティスを解説します

<img width=420 src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/70f41929-34cb-a080-c42f-b0777ef170d9.png>

## AWS リソースを追跡および識別するために、インスタンスメタデータおよびリソースのカスタムタグを使用
こちらはEC2に限らず、多くのAWSサービスにおいて有用な運用法となります。

インスタンスを始めとしたEC2のリソース (あるいはEC2以外も含めた多くのAWSリソース)では、[**タグ**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#タグ)付けによる**分類**が可能です。

タグ付けによりユーザーによる**リソースの検索を効率化**できるのみならず、[**請求書の分類**(コスト配分タグ)](https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)や[**IAMによるアクセス制御**(タグベース認可)](https://dev.classmethod.jp/articles/iam-visual-editor-reference/)をタグに基づき実施する事もできます。

最も馴染み深いタグは、インスタンスの名称を表す`Name`ですが、それ以外にも「用途」、「所有者」、「環境」等を表すタグを追加する事で、インスタンス数が増えた際も効率的な管理を実現できます。

タグ付けの方法はコンソールやCLI、IaC (CloudFormation)等、使用するツールにより異なるため、以下の公式ドキュメントを参照下さい。

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

## Amazon EC2 の現在の制限を表示
**インスタンス等のリソース数**には、**リージョン毎に上限**が設けられています。

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

詳細は**以下の記事**の「**制限**」を参照下さい

https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#制限

## AWS Trusted AdvisorでAWS環境を検査
**Trusted Advisor**はEC2に限らず、多くのAWSサービスにおいて有用な**自動チェックツール**です。

具体的には、「コスト最適化」「パフォーマンス」「セキュリティ」「耐障害性」「サービスの制限」という**5種類の事項**に関して、**ベストプラクティスから外れた非効率・不安全な状態となっているリソースを簡単に検知**できます。

ただし、**多くの機能は有料の**[AWSサポートプラン](https://aws.amazon.com/jp/premiumsupport/plans/)において「ビジネス」以上のプランを選択しないと使用できない事にご注意ください。
全ての検知項目は、以下の公式ドキュメントを参照下さい

https://aws.amazon.com/jp/premiumsupport/technology/trusted-advisor/best-practice-checklist/

**無料で使用できる機能**として、例えば以下の「**セキュリティ**」**に関する項目の検査**を実施できます。

<img width=720 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/5feee4a9-7a40-8b2e-bba5-a9d59f3806ad.png">

❗️マークが付いている項目が検査によりベストプラクティスに合致していないと判定されたリソースの検出を表しています。
(上例では、デフォルトのセキュリティグループでSSH用の22番ポートが無制限アクセスとなっているため、検知されているようです。このようにデフォルト設定であっても必ずしも安全とは言い切れないため、**Trusted Advisorはより安全なクラウド運用を実現するために役立ちます**)

<br>
<br>

# バックアップと復旧
バックアップに関連したベストプラクティスを解説します

<img width=200 src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/ed6428ed-0d94-2579-7188-7ae17fc19a56.png>

## 定期的にスナップショットを使用してEBSボリュームをバックアップし、インスタンスからAMIを作成
インスタンスやEBSをバックアップするにはスナップショットとAMIの2種類の方法があり、これらのバックアップを自動化するためには**ライフサイクルマネージャー**や**AWS Backup**と呼ばれる機能を使用すると便利です。

詳細は**以下の記事**の「**EC2とバックアップ**」を参照下さい

https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#ec2とバックアップ

## 複数のアベイラビリティゾーンにアプリケーションの重要なコンポーネントをデプロイし、データを適切にレプリケート
こちらはEC2に限らず、多くのAWSサービス(特にEC2のようにデフォルトでは冗長化が弱いサービス)において意識する必要のある事項です。

EC2インスタンスは単一のAZに設置されて冗長化されておらず、ストレージとして使用されるEBSも単一AZ内の冗長化のみで、**AZに障害が発生した際に単一障害点となってサービスが停止**してしまいます。

よって、**ELBやAuto Scaling等と組み合わせて複数AZへインスタンスを設置してトラフィックを分散**させたり、スナップショット等で定期的にバックを取得(保存先のS3はデフォルトで複数AZにレプリケートされる)する事で、**耐障害性を高める事が推奨**されています。

詳細は**以下のELBの記事**を参照下さい

https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#elb-ロードバランサー

また、RDSやS3にデータを保持している場合は、併せて[RDSのマルチAZ構成](https://hacknote.jp/archives/40122/)や[S3のクロスリージョンレプリケーション]()を適用することで、システム全体としての冗長性を向上させられます。

## インスタンスが再開したときに、動的なIPアドレスを処理するアプリケーションを設計
[こちらの公式ドキュメント](https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-recover-ip-address/)に記載されているように、インスタンスのデフォルトでは**インスタンスに動的なIPアドレスが自動で割り振られます**

この動的なIPアドレスやAWS側がIPv4アドレスプールから自動選択するため、ユーザ側が事前に知る事はできません。よって、**インスタンスの切り替えや再起動時にIPアドレスが変わる事を見越してアプリケーションを設計する必要**があります。

具体的には、以下の3種類の方法 (特に前者2つ)が有効な対処法となります。

### 対処1: Elastic IP
上記への対処法として最もシンプルな方法は[**Elastic IP**](https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77#elastic-ip)を使用する事です。
Elastic IPはインスタンスに**固定のグローバルIPアドレスを付与**する機能であり、インスタンスの切り替えや再起動時に同じElastic IPを付与することで、**IPアドレスの変化を防ぐ**事ができます。

### 対処2: ELBとAuto Scaling
また複数インスタンスの使用を許容するのであれば、**ELB**単体、または**ELBとAuto Scalingを組み合わせる**ことで、**IPアドレスの変化を意識する事なくインスタンスへのリクエストの自動配分**を実現する事もできます。

### 対処3: ダイナミックDNS
Elastic IPを使用しなくとも、**ダイナミックDNS**を使用することで、より**安価にIPアドレスの変化に対応**する事ができます (以下のドキュメント参照)

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/dynamic-dns.html

ただし[こちらのサイトの「DNSのTTL」](https://nw.seeeko.com/archives/50534781.html)で言及されているように、DNSはキャッシュ更新までにタイムラグがあるという特性上、新しいIPアドレスが反映されるまでに時間が掛かり(最大24時間程度)、**古いIPアドレス**(=終了したインスタンス)**がリクエストを受信し続ける**リスクがある事にご注意ください (基本的には**公開サービスには向かない**方法です)

## イベントを管理し、対応
EC2を安定運用していくためには、**異常発生時の検知**や**障害発生時の事後分析**のために、**インスタンスの各種情報をモニタリング**する必要があります。

インスタンスのようなAWSのリソースのモニタリングには**CloudWatch**を使用することが基本です。

モニタリング対象を何とするかはユースケースにより異なるため、**目的に応じて計画的にモニタリング対象を定めること**が求められますが、**ベストプラクティスでは以下のメトリクスを最低限モニタリング対象に含めること**が推奨されています。

|モニタリング対象の項目|モニタリング対象の項目|エージェント/CloudWatch Logs のモニタリング|
|---|---|---|
|CPU使用率|CPUUtilization||
|ネットワーク使用率|NetworkIn<br>NetworkOut||
|ディスクパフォーマンス|DiskReadOps<br>DiskWriteOps||
|ディスクの読み書き|DiskReadBytes<br>DiskWriteBytes||
|メモリの使用率、ディスクスワップの使用率、ディスクスペースの使用状況、ページファイルの使用状況、ログ収集|CPUUtilization|[参考](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)|

**最も簡単に閲覧**するのであれば、以下のようにCloudWatchのトップページから「すべてのメトリクス」→「EC2」→「自動ダッシュボードを表示」と飛ぶと便利です

<img width=840 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/8ee8bc2e-f2a3-b033-9c0a-98c6971e949d.png">

**・ダッシュボードの表示内容**

<img width=840 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/678c0878-1386-6650-2f98-2f1ff49b0bf6.png">

詳細は以下公式ドキュメントを参照下さい

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

## フェイルオーバーを処理する準備が整っていることを確認
EC2における**フェイルオーバー**とは、ある**インスタンスが障害で停止した際に、代わりのインスタンスに簡単に、あるいは自動的に切り替え、サービスの提供を維持**する事を指します。

ベストプラクティスでは、以下の2種類の方法が紹介されていますが、ある程度スケールしたサービスであれば自動化された**対処2**がおすすめです。

### 対処1: ENIの付け替え
インスタンスがネットワークにアクセスするためには、[ENI (Elastic Network Interface)](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#eni-elastic-network-interface)を経由する必要があります。
逆に言うと、**ENIにElastic IPで固定IPアドレスを付与**すれば、ENIを他のインスタンスに付け替えるだけで簡単に**同じIPアドレスを付与**する事が出来ます。

なので、正規のインスタンスに**Elastic IPを付与したENIをアタッチ**した上で、**予備のインスタンスを予め準備** (あるいはAMIやスナップショットの形で保持して新たにインスタンス立ち上げ)しておけば、**障害発生時に手動でENIを付け替える事で簡単にフェイルオーバーを実現**できます。

### 対処2: Auto Scalingを使用
[**Auto Scaling**](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#auto-scaling)を使用すれば、CloudWatchまたは[ELB](https://qiita.com/c60evaporator/items/06aa523c470d52782c7b#elb-ロードバランサー)の[**ヘルスチェック機能**]()で**障害発生を検知**し、**自動で新たなインスタンスを起動してフェイルオーバー**できます。

<br>

## インスタンスとEBSボリュームを復元するプロセスを定期的にテストして、データとサービスの正常な復元を確認
[前述のように](https://qiita.com/c60evaporator/items/aec4f5eff42802c9511a#定期的にスナップショットを使用してebsボリュームをバックアップしインスタンスからamiを作成)、ライフサイクルマネージャーやAWS Backupを使ってインスタンスのバックアップ(AMI + スナップショット)を取得する事ができます。

一方で、[AMIとスナップショットから**インスタンスを復元する方法**](https://tracl.cloud/archives/engineerblog/aws-ami-backup-restore)やインスタンスタイプ**等を把握しておかないと**正しい復元が実現できないため、**いざという時パニックとなる恐れ**があります。

このような事態を防ぐため、**定期的にバックアップからの復元訓練**を実施し、**復元後のインスタンスが想定通り動作すること**を確認しましょう。
(このあたりを「面倒臭い」と感じるのであれば、学習コストをかけてでも環境構築をより自動化できるFargateやECSのようなコンテナサービス、あるいはCloudFormationやTerraformのようなIaCサービスを使用する事をお勧めします)

<br>
<br>

# ネットワーク関連
ネットワークに関連したベストプラクティスを解説します

<img width=200 src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/610167/badc131e-4ac9-3750-3d38-a19fe1ee0423.png>

## アプリケーションのTTL値をIPv4とIPv6で255に設定
`ping`コマンド等で見たことのある方も多いかと思いますが、IPパケットには**TTL**と呼ばれる仕組みが存在します。

TTLは**ルータを経由するたびに減少**する数であり、0になるとパケットが強制的に廃棄され、リクエストが通らなくなります。
よって初期値 (**TTL値**)を**経由するルータ数より大きく設定する必要**があります。

本来はネットワーク界の「ハメ技」とも言える[ルーティングループ](https://nw.seeeko.com/archives/50283919.html#10%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97)を防ぐための仕組みですが、クラウドのような経由ルータ数が多くなりがちな複雑なシステムでは、**パケット破棄を防ぐために、アプリケーション側でTTL値を255のような大きな値に設定**する事が推奨されます。

なお、TTLの詳細については以下の記事がわかりやすいです

https://wa3.i-3-i.info/word13138.html