AWS - Amazon EC2のソースを表示

== 概要 ==
Amazon EC2 (Amazon Elastic Compute Cloud) とは、クラウド上にOS付きの仮想マシン (VM) を作成できるサービスである。<br>
クラウド上に自身または自社専用のサーバを構築することができる。<br>
<br>
このように、クラウド上でOSありの仮想マシン環境を提供するサービスをIaaS (Infrastructure as a Service )と呼ぶ。<br>
Amazon EC2はIaaSの中でも最も広く使用されているサービスであり、AWSの主要サービスの1つである。<br>
<br>
Amazon EC2のようなIaaSをオンプレミスサーバと比較したメリットとして、物理的なハードが不要である事によるスペースや初期費用のメリットが挙げられる。<br>
また、それ以外にも以下に示すメリットが得られる。<br>
* 従量制(使用した分)だけ過不足なく料金が請求される。(コストの変動費化)
* 障害への耐性を簡単な設定で確保できる。(可用性)
* 適切な設定により柔軟に性能を向上できる。(パフォーマンス)
* アクセス権限を簡単に設定できる。(セキュリティ)
<br>
[[ファイル:AWS Amazon EC2 1.png|フレームなし|中央]]
<br>
また、より機能を限定したSaaSやPaaSと比較した場合の特徴としては、「様々なことができるが、何かをするためには自身で逐次設定が必要である」ことが挙げられる。<br>
ただし、近年ではサーバーレス技術を用いて設定管理を簡略化できるFargateやLambda等のサービスに置き換えられることも増えている。<br>
<br>
しかし、様々なことができ、かつ、料金が安いというAmazon EC2の特徴は多くの企業にとって魅力的である。<br>
<br><br>

== EC2の構造 ==
Amazon EC2は大きく分けて、3つの構成要素から成り立っている。<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|-
! style="background-color:#66CCFF;" | 名称 
! style="background-color:#66CCFF;" | 一般的なPCにおける役割
|-
| AMI (OS) || OS (Linux, Windows等) + 一部のミドルウェア
|-
| インスタンスタイプ || CPU + メモリ (+ ストレージ + GPU)
|-
| ストレージ (EBS) || ストレージ
|}
</center> 	
<br>
==== AMI (OS) ====
AMI (Amazon Machine Images) とは、インスタンスの起動時に実行するOSイメージを表す。<br>
また、ミドルウェアがインストールされたAMIもあり、用途に応じて選択することができる。<br>
<br>
AWSがデフォルトで提供するAMI以外にも、サードパーティ製のAMIやユーザが独自に作成できるカスタムAMIと呼ばれる仕組みが存在しており、環境構築の簡略化やバックアップ用途等で使用されている。<br>
<br>
AWSがデフォルトで提供するAMIを下表に示す。<br>
また、アーキテクチャも同時に選択できるが、アーキテクチャとインスタンスタイプのアーキテクチャを揃える必要がある。<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|+ 韓国ソウルリージョンで提供されているOS (2023/12現在)
|-
! style="background-color:#66CCFF;" | 名称 
! style="background-color:#66CCFF;" | 分類 
! style="background-color:#66CCFF;" | 概要
|-
| Amazon Linux || Linux || RHEL派生のAmazonがカスタマイズしたLinux
|-
| SLES || Linux || Slackware派生のLinux
|-
| RHEL || Linux || RHEL
|-
| Ubuntu Pro || Linux || Debian派生のLinux
|-
| Windows Server || Windows || -
|}
</center>
<br>
初めて使用する場合は、Amazon Linuxを選択することが推奨される。<br>
<br>
==== ミドルウェア ====
一般的なのWebサーバ等の用途であれば、OSのみがインストールされたAMIでよい。<br>
以下に示すような特殊用途を想定して、一部ミドルウェアがインストールされたAMIも提供されている。<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|-
! style="background-color:#66CCFF;" | AMIの名称 
! style="background-color:#66CCFF;" | 概要 
! style="background-color:#66CCFF;" | 用途
|-
| Deep Learning AMI || TensorFlowおよびPyTorchの実行環境(CUDA, GPUドライバ等) || Deep LearningによるAI開発
|-
| with SQL Server || SQL Serverがインストールされている || データベースサーバ
|-
| with .NET 6 || .NETの開発環境やMATEによるデスクトップ環境 || .NETを使用した開発 (Unityを使用したゲーム開発等)
|}
</center>
<br>
==== インスタンスタイプ ====
サーバ上で処理を実行する装置(CPU, RAM等)を選択する。<br>
<br>
CPUおよびRAM等を選択するために一意に付与されたIDをインスタンスタイプと呼び、t2.microのような名称で表される。<br>
名称の解釈を以下に示す。<br>
* 先頭の文字
*: インスタンスの種類(ファミリー)
*: 用途と対応
* 先頭から2つ目の数字
*: 世代
*: 数字が大きいほど高スペック
* nano、micro
*: サイズを表す。
*: 基本的に大きいほど高スペック
<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|-
! style="background-color:#66CCFF;" | 名称 
! style="background-color:#66CCFF;" | 概要
|-
| vCPU || 仮想CPUの個数<br>(詳細なCPUの種類は、[https://aws.amazon.com/jp/ec2/instance-types/ Amazon EC2の公式ドキュメント]を参照すること)
|-
| メモリ || 仮想メモリの容量
|-
| ネットワーク帯域幅 || EC2外部と通信する際の帯域幅 (通信速度)
|-
| ストレージ || インスタンスストア(後述)の容量 (EBSではないことに注意する)<br>通常は0
|-
| GPU || GPUの個数 (一般的なサーバ用途では<code>0</code>でよいが、Deep Learningをする場合は必要となる)
|}
</center>
<br>
また、用途とインスタンスタイプの関係の詳細を知りたい場合は、[https://aws.amazon.com/jp/ec2/instance-types/ Amazon EC2の公式ドキュメント]を参照すること。<br>
例えば、学習用途の場合は、t2.microを選択してよい。<br>
<br>
==== ストレージ (EBS) ====
一般的なPCにおけるストレージと同様に、Amazon EC2にもストレージを付与する必要がある。<br>
特に、起動用OSがインストールされたルートボリュームは必須である。<br>
<br>
Amazon EC2のストレージには、一般的にEBS (Elastic Block Store)というサービスが用いられるが、特殊な用途ではインスタンスストアと呼ばれるサービスも使用される。<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|-
! style="background-color:#66CCFF;" | 名称 
! style="background-color:#66CCFF;" | 冗長性 
! style="background-color:#66CCFF;" | 着脱(アタッチ)可否 
! style="background-color:#66CCFF;" | データの永続性 
! style="background-color:#66CCFF;" | バックアップ(スナップショット) 
! style="background-color:#66CCFF;" | 速度(スループット) 
! style="background-color:#66CCFF;" | 速度(IOPS) 
|-
| EBS || 可能 || あり || あり || 可 || 高速 || SSDは高速<br>HDDは低速
|-
| インスタンスストア || 不可 || なし || なし || 不可 || EBSより高速 || EBSよりかなり高速
|}
</center>
<br>
スループットとIOPSの違いを以下に示す。<br>
* スループット
*: 大きなファイルを一度に読み書きする時の速度
* IOPS
*: 細切れのファイルに頻繁に読み書きする時の速度
<br>
===== EBS =====
EBSは、Amazon EC2に対して自由に着脱(アタッチ / デタッチ)可能なストレージであり、一般的なストレージのように使用することができる。<br>
EBSもインスタンスタイプと似た<u>ボリュームタイプ</u>と呼ばれる一意の名称から選択することができる。<br>
<br>
主なボリュームタイプを下表に示す。<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|-
! style="background-color:#66CCFF;" | ボリュームタイプ名称 
! style="background-color:#66CCFF;" | 種類 
! style="background-color:#66CCFF;" | 耐久性 
! style="background-color:#66CCFF;" | スループット (MB/s) 
! style="background-color:#66CCFF;" | IOPS (回/s) 
! style="background-color:#66CCFF;" | 容量 
! style="background-color:#66CCFF;" | 備考
|-
| gp3 || SSD || 99.8% 〜 99.9% || 1000 || 16,000 || 1[GB] 〜 16[TB] || 
|-
| gp2 || SSD || 99.8% 〜 99.9% || 250 || 16,000 || 1[GB] 〜 16[TB] || 
|-
| io2Block Express || SSD || 99.8% || 1000 || 16,000 || 4[GB] 〜 64[TB] || 
|-
| io2 || SSD || 99.999% || 4000 || 256,000 || 4[GB] 〜 16[TB] || 
|-
| io1 || SSD || 99.999% || 1000 || 64,000 || 4[GB] 〜 16[TB] || 複数インスタンス共有可
|-
| st1 || HDD || 99.8% 〜 99.9% || 500 || 500 || 125[GB] 〜 16[TB] || ルートボリューム不可
|-
| sc1 || HDD || 99.8% 〜 99.9% || 250 || 250 || 125[GB] 〜 16[TB] || ルートボリューム不可
|}
</center>
<br>
基本的に、HDDタイプのsc1 / st1よりもSSDタイプのgp2やgp3の方が高性能かつ料金が高い。<br>
また、同じSSDタイプでもgp2 / gp3より、io1 / io2の方が高性能かつ料金が高い。<br>
<br>
gp2が容量に応じた時間課金のみであるのに対し、gp3は読み書きに伴うIOPSやスループットにも課金される。<br>
<br>
ボリュームタイプによる性能差は、スループットよりもIOPSの方が大きいため、IOPSに求められる要件と料金のバランスを見て判断することを推奨する。<br>
スループットやIOPSは、ボリュームの容量によっても変化するため、詳細を知りたい場合は[https://docs.aws.amazon.com/ja%20jp/AWSEC2/latest/UserGuide/ebs-volume-types.html Amazon EC2の公式ドキュメント]を参照すること。<br>
<br>
なお、EBSはAmazon EC2と一体化して動作するという特性上、同じAZ内のAmazon EC2インスタンスとしか紐付けることができない。<br>
また、io1を除き、1つのEBSを複数のAmazon EC2インスタンスで共有する事はできない。<br>
<br>
<u>※スナップショットとは</u><br>
<u>スナップショットは、EBSのデータをAmazon S3にバックアップする機能のことである。</u><br>
<u>これは、ユーザのAmazon S3ではなく、AWSが管理するAmazon S3バケットに保存される。</u><br>
<u>障害時の復旧等に有用な機能であるが、有料であることに注意する。</u><br>
<br>
<u>また、EBSのみで使用できる機能であるため、インスタンスストアでは使用できないことに注意する。</u><br>
<br>
<u>スナップショットによるバックアップの詳細は、[[AWS - Amazon EC2#バックアップ]]のページを参照すること。</u><br>
<br>

===== インスタンスストア =====
一般的に、Amazon EC2のストレージにはEBSが使用されるが、一部のインスタンスタイプではインスタンスストアと呼ばれるストレージが選択できる。<br>
<br>
インスタンスストアはEBSと比較してデータ消失のリスクがあるが (冗長性がない、かつ、インスタンス停止時にデータが自動的に削除される等)、<br>
高速アクセスが可能なストレージ(IOPSが速い)であり、耐障害性を犠牲にしてでも高頻度アクセスにおける処理速度を重視する用途 (一時ストレージ等)に向いている。<br>
<br>
選択可能なインスタンスストアの種類は、[https://docs.aws.amazon.com/ja%20jp/AWSEC2/latest/UserGuide/InstanceStorage.html Amazon EC2の公式ドキュメント]を参照すること。<br>
<br>
===== EBSとインスタンスストアの比較 =====
* EBS
*: 標準的な速度であるが、データの消失対策やコスト面に優れる。
* インスタンスストア
*: 大変高速であるが、データの消失対策やコスト面で弱い。
*: 使用例: 速度最優先の一時ストレージ向け
<br>
両者の比較は、[https://docs.aws.amazon.com/ja%20jp/AWSEC2/latest/UserGuide/ComponentsAMIs.html AWSの公式ドキュメント]でも比較されており、<br>
インスタンスストアが適した用途として頻繁に変更される情報 (バッファ、キャッシュ、スクラッチデータ、その他の一時コンテンツ等) の一時ストレージに最適と記載されている。<br>
<br>
===== S3 / EFSとの違い =====
EBSやインスタンスストアはOSのイメージを持つため、Amazon EC2インスタンスと一緒に動作する事が前提となるため、一般的なサーバの内蔵ストレージに相当する。<br>
一方、S3は静的サイトのホスティングに使用されることから、それだけで独立したサービスとして動作するストレージ (SaaS) である。<br>
<br>
また、AWSで使用されるストレージにEFSがあり、<br>
これはEBSのようにAmazon EC2にマウントでき、かつ、複数のAmazon EC2インスタンスで共有ができるため、NASに近い存在といえる。<br>
また、EFSはLambdaやFargate等のAmazon EC2以外のコンピューティングサービスでも使用できる。<br>
<br>
共に、KMSによる暗号化ができる等の共通点もある。<br>
<br>
その他、冗長化やデータの保持形式も異なっている。<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|+ 冗長化やデータの保持形式の違い
|-
! style="background-color:#66CCFF;" | 
! style="background-color:#66CCFF;" | 動作形態 
! style="background-color:#66CCFF;" | デフォルトの冗長化方法 
! style="background-color:#66CCFF;" | データ保持形式
|-
| EBS || Amazon EC2インスタンスと一緒に動作 || 単一AZ内で冗長化 || [https://www.redhat.com/ja/topics/data-storage/file-block-object-storage ブロックストレージ]
|-
| S3 || 単独のサービスとして動作 || 複数AZで冗長化 || [https://www.redhat.com/ja/topics/data-storage/file-block-object-storage オブジェクトストレージ]
|-
| EFS || Amazon EC2インスタンスにマウントされる事が多いが、<br>他サービスからも利用可能 || 複数AZで冗長化 || [https://www.redhat.com/ja/topics/data-storage/file-block-object-storage ファイルストレージ]
|}
</center>
<br><br>

== ネットワーク ==
外部からAmazon EC2へアクセスする場合は、ネットワークの構築をする必要がある。<br>
<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|-
! style="background-color:#66CCFF;" | 名称 
! style="background-color:#66CCFF;" | 説明
|-
| VPC || AWS上で仮想ネットワークを構築して、セキュリティや耐障害性を向上させる。
|-
| ENI (Elastic Network Interface) || インスタンスに新たなIPアドレスを付与する。
|-
| Elastic IP || インスタンスに固定のグローバルIPアドレスを付与する。
|-
| ELB (ロードバランサ) || 複数のインスタンスにアクセスを分散させて、可用性向上や負荷分散を自動化する。
|-
| Auto Scaling || 負荷に応じてインスタンス数を自動で変化させ、コストと性能のバランスを自動調整する。
|-
| プレイスメントグループ || 複数のインスタンスをグループ化して、インスタンス間の通信速度や耐障害性を向上させる。
|-
| SSHによるアクセス || キーペアで公開鍵認証によるSSH通信でインスタンスに接続して、外部からセキュアなインスタンスの操作を実現する。
|}
</center>
<br>
==== VPC ====
VPC (Virtual Private Cloud) とは、AWS上で仮想ネットワークを構築できるサービス (Amazon EC2とは別のサービス) であり、Amazon EC2も基本的にはこのVPC内に設置されて動作する。<br>
<br>
デフォルトの設定において、Amazon EC2インスタンスを作成するとデフォルトのVPCが自動的に紐付けられるため、単一のAmazon EC2であればVPCを意識しなくとも使用できる。<br>
しかし、複雑なシステムを構築する場合は、VPCの知識は必須となる。<br>
[[ファイル:AWS Amazon EC2 VPC 1.png|フレームなし|中央]]
<br>
VPCの詳細を知りたい場合は、[[AWS - Amazon VPC]]のページを参照すること。<br>
<br>

==== ENI ====
ENI (Elastic Network Interface) サービスを着脱 (アタッチ / デタッチ) することにより、ネットワークへの接続経路、すなわちインスタンスに付与されたIPアドレスの数を増減することができる。<br>
1つのENIに複数のIPアドレスを付与することもできる。<br>
<Br>
ENIが無い場合はネットワークにアクセスできないため、Amazon EC2インスタンスにはデフォルトで1つのENIが付加されている。<br>
また、ENIを追加することもできる。<br>
<br>
<u>※注意</u><br>
<u>なお、後述のElastic IPやセキュリティグループは、Amazon EC2インスタンスではなくENIに付与されているため、ENIのアタッチ / デタッチ時は再設定が必要となることに注意する。</u><br>
<br>
==== EFA ====
ENIに高速化が施されたEFA (Elastic Fabric Adapter) サービスも存在する。<br>
これは、大規模シミュレーションや機械学習等のハイパフォーマンス性能が求められる用途において、複数のコンピュータが連携して動作するHPC処理に適している。<br>
<br>
==== Elastic IP ====
Amazon EC2のインスタンスにおいて、グローバルIPアドレスは動的に付与されるため、再起動ごとにIPアドレスが変更される。<br>
これを防ぐため、Elastic IP (EIP) は固定のグローバルIPアドレスを割り振る。<br>
<br>
==== ELB ====
複数のサーバを並列に立ち上げ、アクセスを分散させることで負荷を軽減させる仕組みがロードバランサである。<br>
AWSにおいては、ELB (Elastic Load Balancer) と呼ばれるロードバランサがサービスとして提供されており、<br>
アクセスを複数のAmazon EC2インスタンス、あるいは、FargateやRDSのようなサービスに分散させることができる。<br>
<br>
また、下図のようにELB / ALBにおいて、分散先のインスタンスを複数のAZに配置することにより、冗長性の確保を実現することもできる。<br>
<br>
==== Auto Scaling ====
ELBで負荷分散をする場合、Amazon EC2インスタンスの数が重要となる。<br>
インスタンスの数が多いほど捌けるアクセス数が増えて性能が向上するがコストも増大するため、コストと性能のバランスを取り、インスタンスの数を調整することが望ましい。<br>
<br>
これに対応するため、負荷に応じてインスタンスの数を動的に変化させて、コストと性能のバランスを自動調整するサービスがEC2 Auto Scalingである。<br>
<br>
==== プレイスメントグループ ====
物理的距離の差により通信速度(RTT)が早くなる。 (往復距離に掛かる時間 (RTT: レイテンシ))<br>
同様にAWSにおいても、複数のインスタンスをグループ化してRTTが小さくなるよう配置することにより、同一AZ内のインスタンス同士の通信速度を向上させるプレイスメントグループと呼ばれる機能が存在する。<br>
<br>
プレイスメントグループでは、以下の3種類のグルーピング方法を選択することができ、<u>パーティション</u>と<u>スプレッド</u>は速度だけでなく耐障害性も向上させることができる。<br>
<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|-
! style="background-color:#66CCFF;" | 名称 
! style="background-color:#66CCFF;" | 配置 
! style="background-color:#66CCFF;" | 用途
|-
| クラスタ || グループ内のRTTが小さくなるようインスタンスを配置する。 || 速度重視<br>低RTT<br>高スループット
|-
| パーティション || インスタンスをパーティション単位で分けて、パーティション同士がラックと電源を共有しないよう配置する。 || 速度と耐障害性のバランス
|-
| スプレッド || 全てのインスタンスがラックと電源を共有しないよう配置する。 || 耐障害性重視 
|}
</center>
<br>
プレイスメントグループにより、具体的にどの程度速度が向上するかは、以下に示すWebサイトで詳細に検証されている。<br>
(スプレッドは、耐障害性のみを向上させる方式に見えるが、速度も向上する)<br>
https://dev.classmethod.jp/articles/ec2-placement-group-strategy/<br>
<br>
<u>なお、プレイスメントグループには、以下に示す注意点が存在する。</u><br>
* 既存のインスタンスを後からプレイスメントグループに追加することはできない。<br>インスタンス起動時に追加が必要となる。
* 一部のインスタンスタイプはプレイスメントグループを適用できない。<br>例えば、デフォルトのT2インスタンスは適用できない。
<br>
==== SSHによるアクセス ====
Amazon EC2において、インスタンス内部を操作する場合に第1の選択肢となる接続手法である。<br>
なお、SSHを使用する場合は、セキュリティグループのファイアウォールにおいて、該当するポートを開ける必要がある。<br>
<br>
AWSにおいては、公開鍵認証にキーペアを使用してSSH接続する。<br>
<br>
詳細については、[[AWS - Amazon EC2#セキュリティ機能#キーペア]]のページおよび[[AWS - Amazon EC2#セキュリティ機能#セキュリティグループ]]のページを参照すること。<br>
<br><br>

== セキュリティ機能 ==
コンソールには以下に示す2つの機能があるが、これらは最低限の機能であり対策としては不十分である。<br>
そのため、IAMによるポリシー設定とVPCのセキュリティ機能のページを参照すること。<br>
<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|-
! style="background-color:#66CCFF;" | 名称 
! style="background-color:#66CCFF;" | 説明
|-
| EBSとスナップショットの暗号化 || EBSやそのバックアップであるスナップショット内のデータを暗号化して、機密性を向上させる。
|-
| キーペア || キーペアで公開鍵認証によるSSH通信でインスタンスに接続して、外部からセキュアなインスタンスの操作を実現する。
|-
| セキュリティグループ || ネットワーク上のアクセス制御により、セキュリティを向上させる。<br>(ファイアウォールの役割)
|-
| EC2 Image Builder || ネットワーク上のアクセス制御により、セキュリティを向上させる。<br>(ファイアウォールの役割)
|}
</center>
<br>
==== EBSとスナップショットの暗号化 ====
EBS内のデータはデフォルトでは暗号化されていない。<br>
そのため、暗号化を行いセキュリティレベルを高める必要がある。<br>
<br>
EBSの暗号化は、AWSの暗号鍵管理サービスであるKMSの鍵を利用して、AES-256アルゴリズムで実行される。 (S3の暗号化方式の1つであるSSE-KMSと近い仕組みである)<br>
また、暗号化されたEBSから作成されたスナップショットも同様に暗号化される。<br>
<br>
EBSを暗号化するには、インスタンス起動時の[ストレージ]設定において、下図のように暗号化を有効にする。<br>

<br>
EBSボリュームを直接作成する場合は、下図のように[このボリュームを暗号化する]チュッくボックスにチェックを入力して、暗号化に使用するキーを指定する。<br>

<br>
※AWS管理キーについて (aws / ebs)<br>
EBSの暗号化で使用できるキーとして、ユーザが独自に作成したKMSキー(カスタマーキー)以外に、デフォルトで準備されたAWS管理キー(aws / ebs)が存在する。<br>
このAWS管理キーを使用することにより、KMSキーのポリシー管理が不要となるため、管理の手間を減らすことができる。<br>
<br>
KMSキーとAWS管理キーの違いについて詳細を知りたい場合は、[https://docs.aws.amazon.com/ja%20jp/kms/latest/developerguide/concepts.html AWSの公式ドキュメント]を参照すること。<br>
<br>
==== キーペア ====
キーペアとは、Amazon EC2インスタンスへの接続において、公開鍵認証に使用する鍵を指す。<br>
公開鍵をサーバ側で保持して、秘密鍵をクライアント側で保持することにより、公開鍵認証によるSSH接続を行う。<br>
<br>
<u>なお、一般的なオンプレで使用する公開鍵との違いがあることに注意する。</u><br>
* 一般的なオンプレではクライアント側で両鍵を生成するが、キーペアではサーバ側(AWS側)で鍵を生成する。
* 秘密鍵をAWSからのダウンロードする場合は、１度しかできない。<br>秘密鍵を紛失した場合は、キーペアの再生成が必要となる。
<br>
また、一般的なオンプレと同様、公開鍵と秘密鍵の特性から以下に示すことが成り立つ。<br>
* 秘密鍵を複数のクライアントで共有する事は避けるべきである。
* 公開鍵(インスタンス起動時に選択する鍵)を複数のインスタンスで共有することは構わない。
<br>
==== セキュリティグループ ====
セキュリティグループとは、インスタンスをグルーピングしてIPアドレスとポート番号に基づくアクセス制限を設定することにより、ファイアウォールのようなアクセス制御を実現する機能である。<br>
セキュリティグループはVPC内部の機能のため、詳細を知りたい場合は、[[AWS - Amazon_EC2#VPC|AWS - Amazon_EC2#VPC]]のページを参照すること。<br>
<br>
==== EC2 Image builder ====
作成したAMIを長期間放置する場合、内部のOSやパッケージにパッチや更新が適用されないため、セキュリティに関する脆弱性が放置されて危険である。<br>
このような事態を防ぐため、最新のパッケージがインストールされたAMIを自動で作成および展開できるEC2 Image builderと呼ばれる機能が準備されている。<br>
<br>
EC2 Image builderの詳細を知りたい場合は、[https://dev.classmethod.jp/articles/ec2-image-builder/ DevelopersIOのWebサイト]を参照すること。<br>
<br><br>

== バックアップ ==
Amazon EC2インスタンスをサービスに利用する場合、耐障害性等を考慮すると定期的にバックアップを取得する必要がある。<br>
バックアップには、AMIとスナップショットの2種類の方法があり、これらバックアップを自動取得するためのライフサイクルマネージャやAWS Backupを使用する。<br>
<br>
==== AMIおよびスナップショットによるバックアップの違い ====
スナップショットを取得できるのはEBS使用時のみであるため、インスタンスストアは考慮しないものとする。<br>
<br>
バックアップ元のインスタンス内容を再現するためには、AMIとスナップショット両方を取得する必要がある。<br>
AMIとスナップショットは、下表に示すように保持している情報が異なり、両方が揃って初めてインスタンスの構成情報を再現できる。<br>
<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|-
! style="background-color:#66CCFF;" | 種類 
! style="background-color:#66CCFF;" | 保持している情報
|-
| AMI || インスタンスの構成情報<br>(アーキテクチャ + 紐付くスナップショット等)
|-
| スナップショット || EBS内のデータ<br>(OSの実イメージ + ユーザがインストールしたソフトウェア等)
|}
</center>
<br>
AMIは、スナップショットの紐付け情報も保持しているため、AMIはスナップショットを内包する存在とみなすこともできる。<br>
したがって、実用上はAMIのみを取得することによりスナップショットを兼ねることができ、両者を別個にバックアップする必要性は低い。<br>
下図に示すように、AMI作成画面には、同時にスナップショットを取得する機能が存在する。<br>

<br>
また、AMIもスナップショットもインスタンスタイプやネットワーク等の情報は保持していないため、これらを起動テンプレートとして保存することにより、より迅速なインスタンスの復旧が実現できる。<br>
一方、ライフサイクルマネージャでバックアップを自動化する場合は、より更新頻度の高いスナップショットを高頻度に、それほど頻繁に変化しないAMIは低頻度にしても構わない。<br>
<br>
==== AMI / スナップショットの注意点 ====
* AMIをバックアップとして使用する場合の注意点
*: AMIを長期間放置する場合、セキュリティパッチが当たっていないため、EC2 Image builderで定期的に更新することを推奨する。
*: AMIはリージョンごとに固有なため、リージョンごとに別個に取得が必要である。
*: ただし、[https://aws.amazon.com/jp/premiumsupport/knowledge-center/copy-ami-region/ 他のリージョンにコピーする機能]がある。
*: <br>
*: AMIを[https://docs.aws.amazon.com/ja%20jp/AWSEC2/latest/UserGuide/sharingamis-explicit.html 他のアカウントと共有]することもできる。
*: <br>
* スナップショットの注意点
*: スナップショットの作成と復元は有料である。
*: スナップショットはリージョンごとに固有なため、リージョンごとに別個に取得が必要となる。
*: ただし、[https://docs.aws.amazon.com/ja%20jp/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html 他のリージョンにコピーする機能]がある。
*: <br>
*: スナップショットを[https://docs.aws.amazon.com/ja%20jp/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html 他のアカウントと共有]することもできる。
*: スナップショットの詳細や作成手順を知りたい場合は、[https://docs.aws.amazon.com/ja%20jp/AWSEC2/latest/UserGuide/EBSSnapshots.html AWSの公式Webサイト]を参照すること。
<br>
==== ライフサイクルマネージャ ====
ライフサイクルマネージャは、ルール(ポリシー)に基づき、インスタンスのバックアップ作成を自動化するための機能である。<br>
インスタンスのバックアップにはAMIとスナップショットの2種類が存在するが、ライフサイクルマネージャではいずれかを選択することができる。<br>
<br>
例えば、「毎日0時にスナップショットによるバックアップを作成する」というポリシーを作成することができる。<br>
<br>
設定方法の詳細については、[https://dev.classmethod.jp/articles/ec2-snapshot-by-amazon-dlm/ DevelopersIOのWebサイト]を参照すること。<br>
<br>
==== AWS Backup ====
ライフサイクルマネージャと似たサービスとして、AWS Backupがある。<br>
<br>
ライフサイクルマネージャがAmazozn EC2の機能であるのに対して、AWS Backupは単独のサービスとして提供されているため、Amazon EC2以外のサービスのバックアップ (RDS、EFS、DynamoDB等)にも対応している。<br>
<br>
AWS BackupにおけるAMIのバックアップ機能は、2020年末にライフサイクルマネージャも対応したため、Amazon EC2のバックアップであれば大きな隔たりはない。<br>
ただし、世代管理の方法に差があったり、AWS BackupはAMIには含まれないインスタンスタイプ等の情報も保持するため、他のサービスとの併用の有無(例: RDS等と併用する等)を考慮して、どちらを使用するかを決定する。<br>
<br>
インスタンスタイプ等を保持できるAWS Backupの方が汎用性が高いと思われる。<br>
<br><br>

== その他の機能 ==
ネットワーク、セキュリティ、バックアップの機能以外にも、Amazon EC2には下表に示す機能が存在する。<br>
<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|-
! style="background-color:#66CCFF;" | 名称 
! style="background-color:#66CCFF;" | 説明
|-
| 起動テンプレート || インスタンス起動時の設定をテンプレート登録して、次回以降の入力を簡略化する。
|-
| 専有ホスト<br>(Dedicated Hosts) || 1台の物理サーバを1人のユーザで専有して、ソフトウェアライセンスの持ち込みや該当するセキュリティ要件への対応を実現する。
|-
| キャパシティの予約 || キャパシティ(計算資源)の確保により、起動エラーを防いで特定の期間インスタンスの確実な起動を確保する。
|}
</center>
<br>
==== 起動テンプレート ====
インスタンスの起動時には、AMI、インスタンスタイプ、ストレージ等の様々な設定を適用することができる。<br>
<br>
例えば、同じ設定のインスタンスを複数起動する場合、これらの設定を毎回入力していては面倒である。<br>
そのため、インスタンス起動時の設定を<u>起動テンプレート</u>として登録することにより、次回以降の設定を簡略化することができる。<br>
<br>
特に、起動テンプレートはAuto Scalingの使用時は必須ともいえる機能であり、Auto Scalingグループ内の全てのインスタンスに当機能で作成した設定を渡すことができる。<br>
<br>
==== 専有ホスト (Dedicated Hosts) ====
一般的に、AWSのようなIaaSでは1台の物理サーバを複数台の仮想サーバで共有しており、複数のAWSアカウントのユーザが1台の物理サーバを共有した状態となることが多い。<br>
専有ホストでは、1台の物理サーバを1人のユーザで専有することができ、以下に示す用途に用いられる。<br>
* ユーザ独自のソフトウェアライセンスの持ち込み (AWSで提供されていないOS等)
* コンプライアンス（セキュリティ要件）上、他ユーザと同じサーバでの動作を避ける場合
<br>
専有ホストと似たサービスに[https://aws.amazon.com/jp/ec2/pricing/dedicated-instances/ ハードウェア専有インスタンス]がある。<br>
ハードウェア専有インスタンスも、<u>同一物理サーバ上で他ユーザのインスタンスが起動しないこと</u>が保証されるため、専有ホストと共通しているが、<br>
あくまでインスタンス単位のサービスのため、ホスト(物理サーバ)単位で提供を受けられる専有ホストと比較すると、以下に示す制約が生じる。<br>
<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|-
! style="background-color:#66CCFF;" | 
! style="background-color:#66CCFF;" | 専有ホスト 
! style="background-color:#66CCFF;" | ハードウェア専有インスタンス
|-
| style="font-weight: bold;background-color:#30ee30;" | 課金単位 
|| ホスト(物理サーバ)単位 || インスタンス単位
|-
| style="font-weight: bold;background-color:#30ee30;" | ホスト単位のソフトウェアライセンス持ち込み 
|| 可能 || 不可
|-
| style="font-weight: bold;background-color:#30ee30;" | ホスト内でのインスタンスの起動場所 
|| ユーザ側で制御可能 || ユーザ側で制御不可<br>(AWS側で自動決定)
|-
| style="font-weight: bold;background-color:#30ee30;" | ソケット、コア、ホストIDの可視性 
|| あり || なし
|-
| style="font-weight: bold;background-color:#30ee30;" | 停止インスタンスの再起動時の使用ホスト 
|| 同一ホストが保証される || 他のホストに移ることもある
|}
</center>
<br>
基本的に、ハードウェア専有インスタンスよりも専有ホストの方がユーザ側で利用する自由度が高い。<br>
<br>

==== キャパシティの予約 ====
キャパシティ予約とは、ある期間インスタンスを立ち上げられる権利を予約するサービスのことである。<br>
<br>
「立ち上げられる権利」とは、インスタンスの立ち上げ時において、<u>InsufficientInstanceCapacity</u>と呼ばれるキャパシティ不足に由来するエラーが発生して、インスタンスの立ち上げに失敗する場合がある。<br>
自動での立ち上げを設定している場合、失敗に気付かずに長時間に渡ってインスタンスが停止して、提供するサービスの停止に繋がる恐れがある。<br>
<br>
この<u>InsufficientInstanceCapacity</u>エラーを防ぐため、キャパシティ(物理サーバ等の計算資源)を確保して、特定の期間インスタンスの確実な起動を確保するサービスがキャパシティの予約である。<br>
<br>
キャパシティの予約は、対応するインスタンス購入方式に応じて下表から選択する。<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|-
! style="background-color:#66CCFF;" | 名称 
! style="background-color:#66CCFF;" | 対応するインスタンス購入方式
|-
| オンデマンドキャパシティ予約 || オンデマンドインスタンス
|-
| キャパシティ予約 || リザーブドインスタンス
|}
</center>
<br><br>


__FORCETOC__
[[カテゴリ:Web]]