はじめに
AWSの仮想マシン提供サービスであるAmazon EC2について、2022年9月時点での機能および使用法を、初学者でも理解しやすいことを心掛けてまとめました。
網羅度にこだわってまとめたので、EC2の全体像を把握したいという方は、ぜひご一読頂ければと思います。
また、「EC2の使用法」パートでは、公式ベストプラクティスに則った活用法について解説しておりますので、「現在EC2を活用しているが、適切に運用できるているか不安」という方にも、ご一読いただけるとありがたいです。
Amazon EC2とは
「Amazon Elastic Compute Cloud」の略です。後ろの2つの単語の頭文字がCなので、C2と略しているようです。
EC2はクラウド上にOS付きの仮想マシン（VM）を作成できるサービスであり、砕けた言い方をすると「インターネット上に自分専用のパソコン（サーバ）を立ち上げる」ことができます。
このようにクラウド上でOS付きの仮想マシン環境を提供するサービスをIaaS (Infrastructure as a Service)と呼びますが、EC2はIaaSの中でも最も有名かつ広く用いられているサービスであり、AWSの主要サービスの一つと言える存在です。
EC2のメリット
EC2（というよりIaaS）をオンプレサーバと比較したメリットとして、まず物理的なハードが不要である事によるスペースや初期費用のメリットが挙げられますが、それ以外にも以下のメリットが得られます。
- 使った分だけ過不足なく料金が請求される（コストの変動費化）
- 障害への耐性を簡単な設定で確保できる（可用性）
- 適切な設定により柔軟に性能を向上させられる（パフォーマンス）
- アクセス権限を簡単に設定できる（セキュリティ）
これらを実現する機能については後ほど詳説します。
また、より機能を絞ったSaaSやPaaSと比べた際の特徴は「何でもできるが、何かをするためには自分で逐次設定が必要」であることが挙げられ、近年ではサーバーレス技術を用いて設定管理を簡略化できるFargateやLambda等のサービスに置き換えられることも増えています。
ともあれ、「何でもできて」「コストが安い」というEC2の特徴自体は多くのエンジニアにとって魅力ではあるので、今後も広く用いられることは間違いないでしょう。
EC2の仕組み
EC2の仕組みについて、以下のセクションに分けて解説します
EC2の構造
EC2は大きく分けて、以下の構成要素から成り立っています。
| 名称 | 通常のPCにおける役割 |
|---|---|
| AMI (OS) | OS (Linux, Windows等) + 一部のミドルウェア |
| インスタンスタイプ | CPU + メモリ (+ NVMeストレージ + GPU) |
| ストレージ (EBS) | ストレージ (HDD, SSD) |
AMI (OS)
AMI (Amazon Machine Images)とは、インスタンス起動時に実行されるOSイメージを表します。
OSのみならずミドルウェアがインストールされたAMIも準備されており、後述のように用途に応じて選択することができます。
また、AWSがデフォルトで提供するAMI以外にも、サードパーティ製のAMIや、ユーザが独自に作成できるカスタムAMIと呼ばれる仕組みが存在し、環境構築の簡略化やバックアップ用途等で使用されています。
以下では、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を選択すれば問題ないかと思います。
また、アーキテクチャも同時に選択できますが、ここで選択したアーキテクチャと、インスタンスタイプのアーキテクチャを揃える必要があります。
・ミドルウェア
通常の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の個数 (個数だけでは情報不足であれば、公式ドキュメントで具体的なCPUの種類を確認できます) |
| アーキテクチャ | x86_64, Arm64等のCPUアーキテクチャ |
| メモリ | 仮想メモリの容量 |
| ネットワーク帯域幅 | EC2外部と通信する際の帯域幅 (通信速度) |
| ストレージ | インスタンスストア(後述)の容量(EBSではないので注意、通常は0) |
| GPU | GPUの個数 (通常は0だがDeep Learning用途で必要) |
また、AWS公式でも以下のような用途とインスタンスタイプの関係を示すドキュメントが提供されており、選定の参考となるかと思います。(練習用であればデフォルトのt2.microで良いかと思います)
ストレージ (EBS)
パソコンにおけるHDDやSSDと同様に、EC2にもストレージを付与する必要があります。
特に、起動用OSがインストールされたストレージ (ルートボリューム)は必須です。
EC2のストレージには一般的に、EBS (Elastic Block Store)というサービスが用いられますが、特殊な用途ではインスタンスストアと呼ばれるサービスも使用されます。
| 名称 | 着脱(アタッチ)可否 | 冗長性 | データの永続性 | バックアップ (スナップショット) |
速度(スループット) | 速度(IOPS) |
|---|---|---|---|---|---|---|
| EBS | 可能 | あり | あり | 可 | 高速 | SSDは高速, HDDは低速 |
| インスタンスストア | 不可 | なし | なし | 不可 | EBSより高速 | EBSより超高速 |
なお、スループットとIOPSの違いは以下のサイトが詳しいですが、大まかには以下のように解釈できます。
- スループット: 大きなファイルを一度に読み書きする際の速度
- IOPS: 細切れのファイルに頻繁に読み書きする際の速度
・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の方が高性能ですが、その分コストが高くなります。
またgp2が容量に応じた時間課金のみであるのに対し、gp3は読み書きに伴うIOPSやスループットにも課金されます(詳細はこちら)
ボリュームタイプによる性能差はスループットよりもIOPSの方が大きいので、基本的にはIOPSに求められる要件とコストのバランスを見て判断するのが良いでしょう (良くわからなければデフォルトのgp2で良いかと思います)
スループットやIOPSはボリュームの容量によっても変わるので、詳細は以下の公式ドキュメントを参照ください。
なお、EBSはEC2と一体化して動作するという特性上、同じAZ内のEC2インスタンスとしか紐づけられません。
また、io1を除き、1つのEBSを複数のEC2インスタンスで共有する事はできません。
※スナップショット
スナップショットとは、EBSのデータをS3にバックアップする機能です (ユーザのS3ではなく、AWSが管理するS3バケットに保存されます)
障害時の復旧等に有用な機能ですが、有料である事にご注意ください。
また、EBSのみで使用できる機能で、インスタンスストアでは使用できない事にご注意ください
スナップショットによるバックアップの詳細は後述します。
・インスタンスストア
通常、EC2のストレージには前述のEBSが用いられますが、一部のインスタンスタイプではインスタンスストアと呼ばれるストレージが選択できます。
インスタンスストアはEBSと比べデータ消失のリスクがある (冗長性がない＆インスタンス停止時にデータが消える)が、高速アクセス(特にIOPSが速い)が可能なストレージで、耐障害性を犠牲にしてでも高頻度アクセスにおける処理速度を重視したい用途 (一時ストレージ等)に向いています。
選択できるインスタンスストアの種類は、以下の公式ドキュメントに記載されています。
※EBSとインスタンスストアどちらを選択するか？
どちらを選択するかですが、ざっくり言うと以下のように選択するのが適切かと思います
- EBS: 速度はそこそこだが、データの消失対策やコスト面に優れる。一般的にはこちらを選択
- インスタンスストア: 超高速だが、データの消失対策やコスト面で弱い。速度最優先の一時ストレージ向け
両者の差は以下の公式ドキュメントでも比較されており、インスタンスストアが適した用途として頻繁に変更される情報 (バッファ、キャッシュ、スクラッチデータ、その他の一時コンテンツなど) の一時ストレージに最適と記載されています
また、下記ページも選択において参考になります。
※S3やEFSとの違い
AWSのストレージサービスといえばS3というイメージがある方も多いかと思いますが、EBSやインスタンスストアとの違いを考えてみます。
EBSやインスタンスストアはOSのイメージが入っていることから分かるように、EC2インスタンスと一緒に動作する事が前提となっており、通常のPCで言うと内蔵HDD(SSD)に相当します。
一方でS3は静的サイトのホスティングに使用される事からも分かるように、それだけで独立したサービスとして動作するストレージであり、通常のPCで言うとDropBoxやGoogleドライブのような存在です
また、もう一つAWSでよく使用されるストレージにEFSが挙げられ、こちらはEBSのようにEC2にマウントでき、かつ複数のEC2インスタンスで共有ができるため、NASに近い存在と言えます (捉え方によってはS3とEBSの中間的な存在とみなせる)。またEFSはLambdaやFargate等のEC2以外のコンピューティングサービスでも使用できます。
その他、冗長化やデータの保持形式にも以下のような差があります
(共にKMSによる暗号化ができる等の共通点もあります)
| 動作形態 | デフォルトの冗長化方法 | データ保持形式 | |
|---|---|---|---|
| EBS | EC2インスタンスと一緒に動作 | 単一AZ内で冗長化 | ブロックストレージ |
| S3 | 単独のサービスとして動作 | 複数AZで冗長化 | オブジェクトストレージ |
| EFS | EC2インスタンスにマウントされる事が多いが、他サービスからも利用可能 | 複数AZで冗長化 | ファイルストレージ |
EC2とネットワーク
EC2に外部からアクセスしようとすると、ネットワークの構築が不可欠となります。
ここではEC2と関連の深いネットワーク関係サービスについて解説します。
| 名称 | 概要 |
|---|---|
| VPC | AWS上で仮想ネットワークを構築し、セキュリティや耐障害性を向上させる |
| ENI (Elastic Network Interface) | インスタンスに新たなIPアドレスを付与する |
| Elastic IP | インスタンスに固定のグローバルIPアドレスを付与する |
| ELB (ロードバランサー) | 複数のインスタンスにアクセスを分散させ、可用性向上や負荷分散を自動化する |
| Auto Scaling | 負荷に応じてインスタンス数を自動で変化させ、コストと性能のバランスを自動調整する |
| プレイスメントグループ | 複数のインスタンスをグループ化し、インスタンス間の通信速度や耐障害性を向上させる |
| SSHによるアクセス | キーペアで公開鍵認証によるSSH通信でインスタンスに接続し、外部からセキュアなインスタンスの操作を実現する |
VPC
VPC (Virtual Private Cloud)とは、AWS上で仮想ネットワークを構築できるサービス (EC2とは別のサービス)であり、EC2も基本的にはこのVPC内に設置されて動作します。
デフォルト設定でEC2インスタンスを作成するとデフォルトのVPCが自動的に紐付けられるため、単体のEC2のみであればVPCを意識しなくとも使用自体はできてしまいますが、ある程度複雑なシステムを組もうとするのであれば、VPCの知識は必ず必要となります。
詳細は以下の記事にまとめたので、ぜひご参照下さい。
ENI (Elastic Network Interface)
通常のPCにおいて、NICと呼ばれるLANポートを内蔵したカードを着脱することで、ネットワークの接続経路を増やしたり減らしたりする事ができます。
AWSでも同様に、ENI (Elastic Network Interface)と呼ばれるサービスを着脱 (アタッチとデタッチ)する事で、ネットワークへの接続経路、すなわちインスタンスに付与されたIPアドレスの数を増やしたり減らしたりすることができます。
(1つのENIに複数のIPアドレスを付与することもできます)
ENIがないとネットワークにアクセスできないため、EC2インスタンスにはデフォルトで1個ENIが付加されていますが、さらにENIを追加することもできます (以下の記事のように複数のENIを付加するメリットは限られそうですが…)
なお、後述のElastic IPやセキュリティグループは、厳密にはEC2インスタンスではなくENIに付与されているため、ENIのアタッチ・デタッチ時は再設定が必要となることにご注意ください。
・EFA (Elastic Fabric Adapter)
ENIに高速化が施された、EFA (Elastic Fabric Adapter)と呼ばれるサービスも存在します。
大規模シミュレーションや機械学習等、高性能が求められる用途で複数のコンピュータが連携して動作するHPC (High Performance Computing)と呼ばれる処理方式に、このEFAは適しています。
以下の記事で詳細に検証されており、大変参考になります
Elastic IP
通常、EC2のインスタンスにおいてグローバルIPアドレスは動的に付与されるため、再起動するたびにIPアドレスが変わってしまいます。
これを防ぐため、固定のグローバルIPアドレスを割り振る機能が、Elastic IPアドレス(EIP)です。
詳細は以下の記事を参照ください
ELB (ロードバランサー)
複数のサーバを並列に立ち上げ、アクセスを分散させることで負荷を軽減させる仕組みをロードバランサと呼びます。
AWSにおいては、ELB (Elastic Load Balancer)と呼ばれるロードバランサーがサービスとして提供されており、アクセスを複数のEC2インスタンス (あるいはFargateやRDSのようなサービス)に分散させることができます。
また、下図のようにELB (ALB)において分散先のインスタンスを複数のAZに配置することで、冗長性の確保を実現することもできます。
ELBの詳細については別記事 (作成中)で解説します
Auto Scaling
ELBで負荷分散をする場合、インスタンスの数が重要となります。
インスタンスの数が多いほど捌けるアクセス数が増えて性能が向上しますが、その分コストも増大するため、コストと性能のバランスを取ってインスタンスの数を調整する事が望ましいです。
このような需要に対応するため、負荷に応じてインスタンスの数を動的に変化させ、コストと性能のバランスを自動調整するサービスが、EC2 Auto Scalingです。
Auto Scalingの詳細については別記事 (作成中)で解説します
プレイスメントグループ
物理的位置が遠いマシンと近いマシンでは、基本的に後者の方が通信速度(厳密には「行って帰ってくるまでの時間=RTT, レイテンシー」)が早くなります。
同様にAWSにおいても、複数のインスタンスをグループ化してRTTが小さくなるよう配置することで、同一AZ内のインスタンス同士の通信速度を向上させるプレイスメントグループと呼ばれる機能が存在します。
プレイスメントグループでは、以下の3種類のグルーピング方法を選択する事ができ、「パーティション」と「スプレッド」は速度だけでなく耐障害性も向上させる事ができます。
| 名称 | 配置 | 用途 |
|---|---|---|
| クラスター | グループ内のRTTが小さくなるようインスタンスを配置 | 速度重視 (低レイテンシー、高スループット) |
| パーティション | インスタンスをパーティション単位で分け、パーティション同士がラックと電源を共有しないよう配置 | 速度と耐障害性のバランス |
| スプレッド | 全てのインスタンスがラックと電源を共有しないよう配置 | 耐障害性重視 |
プレイスメントグループにより具体的にどの程度速度が向上するかは、以下の記事で詳細に検証されています。
(スプレッドは一見耐障害性のみを向上させる方式に見えますが、速度も向上するようです)
なお、プレイスメントグループの注意点としては以下が挙げられます。ご注意ください
- 既存のインスタンスを後からプレイスメントグループに追加する事はできない(インスタンス起動時に追加が必要)
- 一部のインスタンスタイプはプレイスメントグループを適用できない(例えばデフォルトのT2インスタンスは適用不可)
SSHによるアクセス
SSH (Secure SHell)とは、暗号化通信を実現するためのプロトコルの一つです。
主にサーバーの遠隔操作目的で使用され、EC2においてもインスタンス内部を操作する際に第1の選択肢となる接続手法です。
SSHでPCからEC2インスタンスにアクセスするために、以下のようにデフォルトのコマンドラインツールが使用できます。
- Mac, Linux(Ubuntu)の場合 → ターミナルを使用
- Windowsの場合 → コマンドプロンプトまたはPowerShellを使用
(よく「WindowsではSSH接続にTera Termが必要」という記述を見ますが、Windows2018年以降のWindows10ではOpenSSHというSSH接続ソフトがプリインストールされたため、デフォルトのツールでアクセス可能となりました)
なお、SSH接続にはTCP22番ポートを使用するため、セキュリティグループ等のファイアウォール機能でTCP22番ポートを開ける必要があります
・公開鍵認証とキーペア
SSHを使用することでインスタンスを遠隔操作する事ができるため、誰からでもアクセスできてはセキュリティ的に危険です。
そこで、限られた人だけがインスタンスにアクセスできるようにするための認証と呼ばれる仕組みが必要となります。
SSHにおいては、公開鍵認証と呼ばれる、
「公開鍵と秘密鍵の2つの鍵を作って公開鍵をサーバーに設置し、秘密鍵を持っているユーザーだけがサーバーにアクセスできる」
という仕組みで、認証(クライアント認証)を実現することが一般的です。
公開鍵認証については以下の記事が参考になります。
AWSにおいては、公開鍵認証に後述のキーペアを使用します
EC2のセキュリティ機能
冒頭で「EC2はクラウド上に立ち上げたPCのようなもの」と述べましたが、PCと同様にセキュリティを疎かにすると様々な攻撃を受け、非常に危険です。これを防ぐためにセキュリティ対策は必須と言えます。
コンソールには以下の2機能が準備されていますが、これらは最低限の機能であり対策としては不十分なため、IAMによるポリシー設定とVPCのセキュリティ機能の活用も併せて活用してください。
| 名称 | 概要 |
|---|---|
| EBSとスナップショットの暗号化 | EBSやそのバックアップであるスナップショット内のデータを暗号化し、機密性を向上させる |
| キーペア | キーペアで公開鍵認証によるSSH通信でインスタンスに接続し、外部からセキュアなインスタンスの操作を実現する |
| セキュリティグループ | ネットワーク上のアクセス制御によりセキュリティを向上させる(ファイアウォールの役割) |
| EC2 Image Builder | ネットワーク上のアクセス制御によりセキュリティを向上させる(ファイアウォールの役割) |
EBSとスナップショットの暗号化
EBS内のデータはデフォルトでは暗号化されていませんが、簡単な設定で暗号化を実現し、セキュリティレベルを高める事ができます。
EBSの暗号化は、AWSの暗号鍵管理サービスであるKMSの鍵を利用し、AES-256アルゴリズムで実行されます。
(S3の暗号化方式の一つであるSSE-KMSと近い仕組みになっています)
また、暗号化されたEBSから作成されたスナップショットも同様に暗号化されます。
EBSを暗号化するには、インスタンス起動時の「ストレージ」設定で下図のように暗号化を有効化するか
EBSボリュームを直接作成する場合は、以下のように「このボリュームを暗号化する」をチェックし、暗号化に使用するキーを指定します
※AWS管理キー (aws/ebs)
EBSの暗号化で使用できるキーとして、ユーザが独自に作成したKMSキー(カスターマーキー)以外に、デフォルトで準備されたAWS管理キー (aws/ebs)が準備されています。
このAWS管理キーを使用することでKMSキーのポリシー管理が不要となるため、管理の手間を減らす事ができます。
カスタマーキーとAWS管理キー(AWSキー)の違いは、以下の公式ドキュメントを参照下さい
キーペア
キーペアとは、EC2インスタンスへの接続において、前述の公開鍵認証に使用する鍵を指します。
公開鍵をサーバー側で保持し、秘密鍵(.pemという拡張子)をクライアント側で保持することで、公開鍵認証によるSSH接続を実現できます。
なお、通常のオンプレサーバーで使用される公開鍵との違いとして、以下に注意が必要です
- 通常のオンプレサーバーではクライアント側で鍵を生成するが、キーペアではサーバー側(AWS側)で鍵を生成
- 秘密鍵のAWSからのダウンロードは一度しか実施できない(鍵を無くしたらキーペアの再生成が必要)
また、通常のオンプレサーバーと同様に、公開鍵と秘密鍵の特性から以下が成り立ちます。
- 秘密鍵(.pemファイル)を複数クライアントで共有する事は避けるべき
- 公開鍵(インスタンス立ち上げ時に選ぶ鍵)を複数インスタンスで共有するのはOK
セキュリティグループ
セキュリティーグループとは、インスタンスをグルーピングしてIPアドレスとポート番号に基づくアクセス制限を設定することで、ファイアウォールのようなアクセス制御を実現する機能です。
セキュリティーグループは厳密にはVPC内の機能のため、詳細は以下の記事をご参照下さい
EC2 Image builder
作成したAMIを長期間放置すると、内部のOSやパッケージにパッチや更新が適用されず、脆弱性が放置されてセキュリティ的に危険な状態となります。
このような事態を防ぐために、最新バージョンのパッケージがインストールされたAMIを自動で作成・展開できるEC2 Image builderと呼ばれる機能が準備されています。
詳細は以下の機能が分かりやすいです。
EC2とバックアップ
EC2インスタンスをサービスに利用する場合、耐障害性等を考慮すると定期的にバックアップを取ることが望ましいです。
バックアップにはAMIとスナップショットの2種類の方法があり、これらバックアップを自動取得するためのライフサイクルマネージャーやAWS Backupという機能を使用すると便利です。
まずはAMIとスナップショットによるバックアップの違いについて解説します。
AMIとスナップショットの使い分け
バックアップ方法としてAMIを使用する場合とスナップショットをどう使い分けるかについて考えてみます。
(なお、スナップショットを取得できるのはEBS使用時のみなので、ここではインスタンスストアは考えない事とします)
結論から言うと、元あったインスタンスの中身を再現するためには、AMIとスナップショット両方を取得する必要があります
AMIとスナップショットは以下のように保持している情報が異なり、両者が揃って初めて元のインスタンスの構成情報を再現できるからです (こちらの記事も参考になります)
| 種類 | 保持している情報 |
|---|---|
| AMI | インスタンスの構成情報(アーキテクチャ＋紐づいたスナップショット等) |
| スナップショット | EBS内のデータ(OSの実イメージ＋後からインストールされたソフト等) |
AMIはスナップショットの紐付け情報も保持しているため、AMIはスナップショットを内包する存在とみなすこともできます。
よって実用上はAMIのみを取得することでスナップショットを兼ねる事ができ、両者を別個にバックアップする必要は低いと言えます
(以下のようにAMI作成画面には同時にスナップショットを取得する機能が存在します。
また、AMIもスナップショットもインスタンスタイプやネットワーク等の情報は保持していないため、これらを後述の起動テンプレートとして保存しておくと、より迅速なインスタンスの復旧が実現できます。
一方で後述のライフサイクルマネージャーでバックアップを自動化する場合は、より更新頻度の高いスナップショットを高頻度に、それほど頻繁に変化のないAMIは低頻度に取得しても良いかと思います。
スナップショット、AMIをバックアップとして使用する際の注意点について簡単に解説します
・スナップショットの注意点
スナップショットをバックアップとして利用する場合、以下にご注意ください
- スナップショットの作成と復元は有料(後述)
- スナップショットはリージョンごとに固有なので、リージョンごとに別個に取得が必要(ただし、他のリージョンにコピーする機能がある)
- スナップショットを他のアカウントと共有することもできます
スナップショットの詳細や作成法は、以下の公式ドキュメントが参考になります。
・AMIの注意点
AMIをバックアップとして利用する場合、以下にご注意ください
- 作成したAMIを長期間放置するとセキュリティパッチ等が当たらずに危険なので、前述のEC2 Image builderで定期的に中身を更新する事が推奨されます
- AMIはリージョンごとに固有なので、リージョンごとに別個に取得が必要(ただし、他のリージョンにコピーする機能がある)
- AMIを他のアカウントと共有することもできます
ライフサイクルマネージャー
ルール(ポリシー)に基づきインスタンスのバックアップ作成を自動化するための機能です。
前述のようにインスタンスのバックアップにはAMIとスナップショットの2種類が存在しますが、本機能ではいずれかを選択することができます。
例えば、「毎日○時にスナップショットによるバックアップを作成する」というポリシーを作成する事ができます。
具体的な設定方法は以下の記事をご参照ください
AWS Backup
ライフサイクルマネージャーと似たサービスとして、AWS Backupが挙げられます。
ライフサイクルマネージャーがEC2の一機能であるのに対し、AWS Backupは単独のサービスとして提供されているため、EC2以外のサービスのバックアップ (RDS, EFS, DynamoDB等)にも対応しています。
以下の記事で両者を比較されていますが、記事中でAWS Backupのメリットとして挙げられているAMIのバックアップ機能は、2020年末にライフサイクルマネージャーも対応したためEC2のバックアップ用であれば両者に大きな違いはなさそうです。
世代管理の方法に差があったり、AWS BackupはAMIには含まれないインスタンスタイプ等の情報も保持してくれるようですので、これらの要件や他のサービスとの併用の有無 (RDS等と併用するのであればAWS Backupの方が便利そうです)を考慮して、どちらを使用するか決定するのが良いかと思います。
(私見としては、インスタンスタイプ等を保持可能なAWS Backupの方がやや汎用性が高そうに感じます)
その他のEC2関連機能
ここまで紹介したネットワーク、セキュリティ、バックアップ関係の機能以外にも、EC2には以下のような便利な機能が存在します
| 名称 | 概要 |
|---|---|
| 起動テンプレート | インスタンス起動時の設定をテンプレート登録し、次回以降の入力を簡略化 |
| 専有ホスト (Dedicated Hosts) | 1台の物理サーバを1人のユーザで専有し、ソフトウェアライセンスの持ち込みや該当するセキュリティ要件への対応を実現する |
| キャパシティの予約 | キャパシティ(計算資源)の確保により起動エラーを防ぎ、特定の期間インスタンスの確実な起動を確保する |
起動テンプレート
インスタンスの起動時には、前述のAMI、インスタンスタイプ、ストレージ等様々な設定を適用することができます (具体的な設定法は後述)
一方で、同じ設定のインスタンスを複数起動したい場合、上記の設定を毎回入力していては面倒です。
そこで、インスタンス起動時の設定を「起動テンプレート」として登録することで、次回以降の設定入力を簡略化することができます。
この起動テンプレートはAuto Scaling使用時はほぼ必須とも言える機能で、Auto Scalingグループ内のすべてのインスタンスに本機能で作成した設定を渡すことができます。
起動テンプレートの作成方法は、以下の記事で詳細解説します
専有ホスト (Dedicated Hosts)
通常、AWSのようなIaaSでは1台の物理サーバを複数台の仮想サーバで共有しており、ひいては複数のAWSアカウントのユーザが1台の物理サーバを共有した状態となっていることが多いです。
一方で、専有ホストでは、1台の物理サーバを1人のユーザで専有することができ、
- ユーザ独自のソフトウェアライセンスの持ち込み (AWSで提供されていないOS等)
- コンプライアンス（セキュリティ要件）上他者と同じサーバでの動作を避けたい場合
等の用途に用いられます。
・ハードウェア専有インスタンス
専有ホストと似たサービスにハードウェア専有インスタンスが挙げられます。
ハードウェア専有インスタンスも「同一物理サーバ上で他ユーザのインスタンスが起動しないこと」が保証されるという意味で専有ホストと共通していますが、あくまでインスタンス単位のサービスのため、ホスト(物理サーバ)単位で提供を受けられる専有ホストと比べると、以下の制約が生じます。
| 専有ホスト | ハードウェア専有インスタンス | |
|---|---|---|
| 課金単位 | ホスト(物理サーバ)単位 | インスタンス単位 |
| ホスト単位のソフトウェアライセンス持ち込み | 可能 | 不可 |
| ホスト内でのインスタンスの起動場所 | ユーザ側で制御可能 | ユーザ側で制御不可(AWS側で自動決定) |
| ソケット、コア、ホストIDの可視性 | あり | なし |
| 停止インスタンスの再起動時の使用ホスト | 同一ホストが保証される | 他のホストに移ることもある |
基本的には
ハードウェア専有インスタンスより専有ホストの方が、ユーザ側で利用する際の自由度が高い
と認識すれば良いかと思います。
キャパシティの予約
ある期間インスタンスを立ち上げられる権利を予約するサービスが、キャパシティ予約です。
「立ち上げられる権利」と言うと分かりづらいですが、インスタンスの立ち上げ時には稀にInsufficientInstanceCapacityと呼ばれるキャパシティ不足に由来するエラーが発生し、インスタンスの立ち上げに失敗します。
手動立ち上げであれば再度立ち上げを実施すれば良いのですが、自動で立ち上げを設定している場合、失敗に気付けずに長時間に渡りインスタンスが停止、ひいては提供するサービスの停止に繋がってしまうこともあります。
このInsufficientInstanceCapacityエラーを防ぐためにキャパシティ(物理サーバ等の計算資源)を確保し、特定の期間インスタンスの確実な起動を確保するサービスが、キャパシティの予約です。
キャパシティの予約は、対応するインスタンス購入方式に応じて以下から選択します
| 名称 | 対応するインスタンス購入方式 |
|---|---|
| オンデマンドキャパシティ予約 | オンデマンドインスタンス |
| キャパシティ予約 | リザーブドインスタンス |
※最もオーソドックスなオンデマンドインスタンス用の名称が「キャパシティ予約」となっていないのは、本サービスが元々リザーブドインスタンス用のみに提供されていたことに由来します
EC2のコスト
EC2でついやってしまいがちなのが、「不要なインスタンスを利用し続けて請求料金が跳ね上がる」事です。
何ヶ月も放置すると数万円程度はすぐに到達するので、個人利用者にとっては痛い出費となり、「クラウド破産」と揶揄されることもしばしばあります。
どこにコストが掛かるのかを把握した上で、コストと性能とのバランスを監視・分析・最適化していくことは、EC2のみならずクラウドを活用する上で最重要項目の一つとなります。
本記事では、EC2の「コストの決定手順」および「コスト監視・最適化のためのTips集」について解説します。
コストの決定手順
EC2の利用コストは、以下のように決まります
EC2の利用コスト =
「インスタンス自体のコスト」 +
「データ転送のコスト」 +
「ボリュームのコスト」 +
「その他のコスト」
それぞれ解説します。
インスタンス自体のコスト
インスタンスの起動時は、以下の要素に応じてコストが発生します。
(インスタンス停止中・休止中はこのコストは発生しません)
| 名称 | 概要 |
|---|---|
| インスタンスのタイプ | 前述のインスタンスタイプ |
| インスタンスの購入方式 | 同タイプのインスタンスでも3種類の購入方式により価格が変わる |
| リージョン | リージョンにより価格が変わる |
具体的なコストは、「インスタンスの購入方式」で後述する料金表を使用することで、大まかな価格を掴むことができます。
とはいえ、料金に縛られすぎて本来クラウドで実現したい機能を制限してしまっては本末転倒なので、基本的には使いながら逐次料金を確認して調整するのが良いかと思います。
それぞれ詳説します
・インスタンスのタイプ
前述のインスタンスタイプにより料金が変わります。
基本的には高性能なタイプほど高価なので、コストと性能のバランスを見て選択します。
・インスタンスの購入方式
同じタイプのインスタンスでも、以下の4種類の購入方式により料金が変わります
| 名称 | 課金体系 (リンク先に料金表) | 適した用途 |
|---|---|---|
| オンデマンドインスタンス | 使用時間に応じて、秒単位※の固定額で課金される | 通常はこちらを使用 |
| リザーブドインスタンス | 1or3年単位で固定額で課金される（時間あたり価格はオンデマンドより安い） | 本番環境等の、長期稼働が確定したシステム |
| Saving Plans | 1or3年単位で最低利用額が定められる、オンデマンドとリザーブドの中間的な契約方式 | 長期稼働が予想されるシステム |
| スポットインスタンス |
入札制で需給に応じて価格が決まる 入札価格より相場が高くなると突然インスタンスが落ちる |
突然落ちても良い用途で、コストを削減したい場合に使用 |
※Linux以外のインスタンスは秒単位ではなく時間単位の課金です
リザーブドインスタンスやSavingPlansは長期稼働、スポットインスタンスは入札相場の逐次確認＆突然落ちるリスクの受容が必要となり、これらが強い制約となってしまうため、基本的には初心者であればオンデマンドを選択するのが無難です。
とはいえ、いずれも適切に利用すれば利用料金を半額以下にする事も可能なので、慣れてきたら積極活用しても良いかと思います。
リザーブドインスタンス、Saving Plans、スポットインスタンスについて簡単に解説します
- リザーブドインスタンス
1年、または3年単位でインスタンスを長期契約することで、時間当たりの契約額を大幅(34〜72%)に削減することができます。
本番環境等、長期でインスタンスを連続使用することが確定している用途に向いた契約方式と言えます。
途中でインスタンスファミリーやOSを変更不可の「スタンダード」と、変更可能な「コンバーティブル」が存在します。スタンダードの方が料金は安いので、途中変更があるかどうかに応じてどちらを購入するか選択してください。
また、購入したリザーブドインスタンスを途中で使用しなくなった場合、マーケットプレイスでインスタンスを売却することもできます。
- Savings Plans
オンデマンドとリザーブドの中間的な契約方式として、1 or 3年の期間で一定の使用量(USD/時間)を契約する代わりに割引が適用されるSavings Plansという契約方法も存在します。
リザーブドインスタンスが「期間内ずっとインスタンスを起動し続ける」事を前提としているのに対し、Savings Plansは「期間内ずっと、1時間あたり最低◯ドル分インスタンスを使用する」という、最低使用量が定められるサービスとなります。
具体的には、以下のルールが適用されます (昔の携帯電話料金の「無料通話分」のシステムに近いです)
・実際の使用量が最低使用量を下回った場合、最低使用量に相当する料金が請求される
・最低使用量を超過した分は、通常のオンデマンドインスタンスの料金が適用される
EC2以外にもLambdaやFargateのようなサーバーレス向けサービスにも適用できます。
詳細は以下を参照ください。
- スポットインスタンス
AWSが予備用に保持しているインスタンスを、入札制で利用できるサービスです。
多くの場合オンデマンドと同等のインスタンスを低価格で利用する事ができますが、「相場によってはオンデマンドより高くなることもある」「入札価格より相場が高くなると突然インスタンスが落ちる」等のリスクがあり、取り扱いに注意が必要な上級者向けサービスと言えます。
スポットインスタンスに、スポットフリートやEC2フリートのように複数のインスタンスをまとめて制御・購入する仕組みが存在するため、戦略次第ではインスタンスが落ちるリスクとコスト両者を抑えることができます（具体的な戦略は以下のサイトが参考になります）
・リージョン
リージョンにより多少料金が変わります（バージニア北部リージョンが安めです）
リージョンごとの料金も、「インスタンスの購入方式」のリンク先にある料金表で確認可能です
データ転送のコスト
基本的には、以下の料金が掛かります
| 通信経路 | コスト |
|---|---|
| インターネットからEC2への通信 (内向き) | 無料 |
| EC2からインターネットへの通信 (外向き) | 通信量に応じて課金 ($0.11/GB前後) |
| EC2から他リージョンへの通信 | 通信量に応じて課金 ($0.09/GB前後) |
具体的な料金表は以下のリンク「データ転送」を参照ください
ボリュームのコスト
EC2と一緒に作成されるボリューム(EBS)にも、以下の料金が発生します
| 名称 | コスト |
|---|---|
| EBS ボリューム | 利用時間とボリューム容量に応じて課金 |
| EBS スナップショット | S3へのバックアップ作成時＆復元時に課金 |
具体的な料金表は以下のリンクを参照ください
その他、以下の情報を知っていると便利です
- EBSでなくインスタンスストアを使用している場合はボリュームのコストは掛かりません (インスタンス自体のコストに含まれる)
- スナップショットを長期保管(90日以上保持)したい場合、EBS Snapshots Archiveという機能を使う事で、バックアップのコストを削減できます
その他のコスト
その他、EC2と併用される以下のサービスにもコストが掛かります。
紐付けたEC2インスタンスを削除してもこれらのサービスが残り、課金される事もあるのでご注意ください。
| サービス名 | コスト (リンク先に料金表) |
|---|---|
| Elastic IP | 実行中のインスタンスに紐づけられれたElastic IPは無料 2個目以降または実行中のインスタンスに紐づけられていないElastic IPは時間課金 |
| キャリアIPアドレス | AWS WavelengthのIPアドレス |
| Elastic Load Balancing (ELB) |
ロードバランサの種類に応じて時間課金 |
| オンデマンドキャパシティー予約 | 対応するEC2インスタンスと同価格 |
| Amazon CloudWatch | 利用時間に応じて時間課金。課金体系が複雑なので、リンク中の「料金の例」に記載されたユースケースが参考になる |
その他、NATゲートウェイやエンドポイント等のVPC関連サービスにもコストが掛かります。詳しくはこちらの記事を参照ください（記事中の「外向き通信量に課金」は本記事の「データ転送のコスト」と同内容のため、2重課金はされません）
コスト監視・最適化のためのTips集
EC2は起動時間に応じて課金されるため、長期継続運用するとインパクトのある金額が請求される事も多く、コストダウン施策が事業上の競争力向上に繋がりやすいサービスと言えます。
よってコストを監視して最適化するための仕組み作りが重要となるため、本用途で有用な機能・サービスを紹介したいと思います。
インスタンスの消し忘れ防止
EC2インスタンスを使用し終わったにも関わらず停止・終了し忘れた状態で放置すると、数ヶ月で結構な額 (数万円オーダー)に到達します。
よくTwitter等で笑い話にされていますが、油断していると自分がやらかしてしまう王道パターンで、私もやらかした事があります。
(特に普段使用しないリージョンでインスタンスを消し忘れると、本当に気付けません)
以下の記事に消し忘れ防止のためのTipsがまとめられているので、不安な方はご参照ください
AWS Budgets
予め予算 (例: 月額5000円)を決めた上で、「予算の80%を超えたらメール通知」「Savings Plansの使用率がしきい値を下回ったらSNS通知」のようなきめ細やかなアラート通知を実現できるのが、AWS Budgetsです。
「定期的にコストを確認」という人間の注意力に頼った確認方法はだいたいどこかでグダグダになって機能しなくなるので、ピンポイントでコストが増大した場合だけ通知してくれる本機能は、再現性のあるコストマネジメント手法として非常に役に立つでしょう
AWS Cost Explorer
PC版のコンソールから費用を確認する方法は多数存在しますが、個人的には綺麗なグラフでUI表示できるCost Explorerがお気に入りです。
詳細は以下の記事がわかりやすいです
AWS Console スマホアプリ
以下のAWS公式のコンソールスマホアプリをダウンロードすれば、スマホからサービス毎の利用料金を確認できます。
(Cost Explorerとほぼ同様のグラフ表示で確認可能です)
料金確認のためにいちいち多要素認証のPCのアプリを開くのは非常に面倒なので、スマホアプリを利用する事で料金確認を簡単に高頻度に実施し、結果として消し忘れに早く気づける可能性
EC2 Global View
後述のEC2 Global Viewを利用すれば全リージョンのEC2インスタンスを確認できるので、前述の「普段使用しないリージョンの消し忘れたインスタンス」に気づく上で有用なツールとなるでしょう
EC2コンソール画面の見方
AWSコンソールにログインしてEC2に入ると、以下のような画面が表示されます。
「EC2ダッシュボード」は、現在のアカウントがリージョン内に保持しているEC2リソースが一覧表示されています。
「左側のタブ」（ナビゲーションペイン）からはEC2各リソースの設定画面に飛べるので、それぞれ簡単に解説します
EC2 Global View
全リージョンのVPCリソースおよびEC2インスタンスの数が一覧表示されます。
他のリージョンの情報も含め簡易的に確認したい場合や、消し忘れたインスタンスが存在しないかの確認に便利です
イベント
AWSでは、セキュリティパッチ適用などの理由により、インスタンスの再起動や停止等のメンテナンスイベントが発生する事があります。
このようなイベントの対象となるインスタンスを、一覧表示するのが本タブです。
(本タブでの表示とは別に、AWSアカウントに関連付けられたメールアドレスへEメールによる通知も行われます)
なお、イベントの実施日時は完全に固定なわけではなく、以下のようにある程度の日時変更を要求する事ができるようです。
タグ
インスタンスを始めとしたEC2リソースに割り当てたタグ (Name等)を一覧表示・管理・追加します。
タグに関する詳細は、以下の公式ドキュメントを参照下さい
また、以下のEC2ベストプラクティスの記事も参照下さい
制限
インスタンス等のリソース数には、リージョン毎に上限が設けられています。
本タブでは、これらリソース数の上限を以下のように一覧表示する事ができます。
例えばVPCの上限数「5」等は、ある程度のヘビーユーザーであれば十分到達しうる数のため、上限を把握しておく事が重要となります。
これら上限は申請により引き上げる事ができますが、実際に引き上げが適用されるまでにはタイムラグが存在するため、現在のリソース数と上限値を逐次確認し、制限の引き上げが必要となる前に計画する事が推奨されています
インスタンス
インスタンス
前述のオンデマンドインスタンスの起動、一覧表示、設定を行います。
実際の起動法は「EC2の使用法」を参照ください
インスタンスタイプ
前述のインスタンスタイプのうち、現在有効なものを確認することができます。
起動テンプレート
前述の起動テンプレートの作成、一覧表示、設定を行います。
スポットリクエスト
前述のスポットインスタンスの購入、一覧表示、設定を行います。
Saving Plans
前述のSaving Plansの購入を行います。
リザーブドインスタンス
前述のリザーブドインスタンスの購入、一覧表示、設定を行います。
専有ホスト (Dedicated Hosts)
前述の専有ホストの起動、予約、一覧表示、設定を行います。
キャパシティの予約
前述のキャパシティの予約の作成、一覧表示、設定を行います。
イメージ
AMI
前述のカスタムAMIの作成、一覧表示、設定、あるいはAMIを用いたインスタンスの起動を行います。
AMIカタログ
前述のAWSデフォルトAMI、サードパーティAMI(Marketplace AMIとコミュニティAMIの2種類に分けられる)、カスタムAMIの一覧を閲覧する事ができます
Elastic Block Store
ボリューム
前述のEBSの作成、一覧表示、設定を行います。
スナップショット
前述のスナップショットの作成、一覧表示、設定を行います。
ライフサイクルマネージャー
前述のライフサイクルマネージャーの作成、設定を行います。
ネットワーク & セキュリティ
セキュリティグループ
インスタンスへのアクセス制限を適用するためのセキュリティグループを、作成、一覧表示、設定します。
詳細は以下のVPCの記事を参照ください
Elastic IP
前述のElastic IPの作成、一覧表示、設定を行います。
プレイスメントグループ
前述のプレイスメントグループの作成、一覧表示、設定を行います。
キーペア
前述のキーペアの作成、一覧表示、設定を行います。
ネットワークインターフェイス
前述のENIの作成、一覧表示、設定を行います。
ロードバランシング
前述のELBの作成、一覧表示、設定を行います。
Auto Scaling
起動設定
前述の起動テンプレートと同様にインスタンス起動時の設定を保持し、効率的に起動するための機能です。
2022年時点では利用が推奨されず、代わりに起動テンプレートを利用する事が推奨されています。
詳細は以下の記事が分かりやすいです
Auto Scaling グループ
前述のAuto Scalingの作成、一覧表示、設定を行います。
EC2の使用法
ベストプラクティスに極力合致するよう実際にEC2インスタンスを作成して運用する方法を解説します。
長くなったので、別記事にて後日投稿します