AWSのEC2ってなんやねん

1. はじめに

どもども、東京喰種にどハマり中の井上弥風（いのうえみふう）です
今回は「EC2ってなんやねん」です

1.1 この記事を書こうと思った理由

現在インフラ案件でAWS構築に取り組んでいて、プロジェクト内でELBを利用していることからELBの内部機能を完全に理解したいと思っていました

手始めに「ロードバランサーってなんやねん」という記事を書き、その流れで「ELBってなんやねん」も書いてみたのですが、ELBの背後にあるEC2の冗長化やオートスケーリングの部分がいまいちピンときませんでした

そこで、まずはELBの背後にあるEC2についてしっかりと理解することから始めようと思い、この記事を書くことにしました！って感じです

1.2 記事のゴール

この記事を通じて、ELBを完全に理解するための基礎として、その背後にあるEC2が何なのか、どのように利用されるのかを明確にすることが当記事のゴールです

1.3 対象読者

• EC2の基本から学びたい人
• EC2について網羅的に知りたい人
• EC2の技術的な詳細まで把握したい人

ではではレッツゴー！

2. EC2の基礎

2.1 EC2とは何か？

一番最初に、「EC2」とは何でしょうか？
EC2とはAWSが提供する仮想サーバーを利用できるサービスです
このサービスを使えば、ユーザーは必要に応じて仮想サーバーを自由に設定して利用することが可能になります

そもそもサーバー・仮想サーバーってなに？
まず、「仮想サーバー」の前に「サーバー」って何でしょうか？

サーバーとは、簡単に言うと「アプリケーションが動作する環境」です
例えば、プログラミング言語でTODOアプリを作ったとします
このアプリを動かすためには、アプリだけではなくそれを実行する環境が必要になり、その実行環境がサーバーです
芸人さん(アプリ)だけではお笑いは成立せず、舞台(サーバー)があることで始めてお客さんにサービスを提供できるといった感じですね！

そして「仮想サーバー」とは、物理サーバーを仮想化技術を用いて複数の独立したサーバーに分割することを言います
この仮想化によって、一つの物理サーバーを複数のユーザーやアプリケーションが共有できるようになります

例としてビルが物理サーバーだとすると、その中の一室を借りる会社が仮想サーバーといった関係性です
空いている他のフロアが無駄にならないように、効率的に空間を利用するのが仮想化のポイントです

EC2はこの仮想サーバーを提供するサービスで、物理サーバーの管理はAWSが担当し、ユーザーは仮想サーバーの設定や運用に集中することができます

EC2とEC2インスタンスの違い
「EC2」と「EC2インスタンス」はよく混同されがちですが、ここでちょっと整理しましょう

• EC2インスタンス
  • 実際の仮想サーバーそのもので、アプリケーションが動作する実行環境です
• EC2
  • これは、仮想サーバーを提供するAWSのサービス名です

普段の会話では「EC2」という言葉でインスタンスを指すこともありますが、技術的な文脈では両者に明確な違いがあることを理解しておきましょう^^

2.2 AMI

AMI（Amazon Machine Image）は、EC2インスタンスを構築するためのテンプレートで、以下の情報が含まれます

1. オペレーティングシステム（OS）
2. アプリケーション
3. ルートデバイスのストレージ
4. 起動に必要な許可設定

何だか色々と含まれており「結局AMIって何なの？？」って感じですが、簡単に言うとEC2インスタンス、つまり仮想サーバーを作成する際の設計図のようなものです

一つの設計図があればいくつでも同じ家が建てられるのと同じで、AMIを用いることで、利用者は一貫して同じEC2インスタンスを利用することが可能になります^^

簡単に言うと「AMIの選択」とは「どのようなソフトウェアを利用するかの選択」といった所です

下記はAMIの選択画面ですが、AMIにはAmazon LinuxやmacOS, Windows等が存在し、自由に利用したいものを選択することができます
ここで選択したAMI(設計図)を基にEC2インスタンス(家)が建つイメージですね！

AMIの配布場所はたくさんある！！

AMIは、EC2インスタンスを起動するためのテンプレートとして、さまざまなストアで提供されています
以下は主なAMIの配布先です

• クイックスタート AMI
  • AWSが予め準備しているAMIで、選べるOSはAmazon LinuxやWindows、Red Hatなど多岐にわたります
  • 早速使用を開始したい場合は、クイックスタートAMIから選択すると良いでしょう
• カスタム AMI
  • ユーザーが自分で作成するAMIで、自分の要件に完全に合わせることができます
  • これらは「マイAMI」とも呼ばれ、EC2インスタンスから直接作成することが可能です
• AWS Marketplace AMI
  • AWSのパートナーベンダーから提供されるAMIで、WordPressなどのアプリケーションがプリインストールされています
  • 特定のアプリケーションをAWSで使用したい場合に便利ですが、AWSの利用料に加えて、ベンダーからの追加料金が発生することを念頭に置く必要があります
• コミュニティAMI
  • 一般に公開されており、他の三つのカテゴリが要件を満たさない場合に利用されます
  • これらは他のユーザーによって作成されたもので、広範なニーズに対応しています

選択するAMIは目的に応じて異なりますが、基本的な学習や一般的な用途ではクイックスタートAMIが最も簡単で便利です
特定の要件がある場合はカスタムAMIやAWS Marketplaceを検討すると良いでしょう

このセクションではAMIの詳細について軽く解説しましたが、AMIの内側は非常に奥深いものです
詳しくは「3. AMIの徹底解説」でAMIの詳細について解説しているため、気になる方はぜひそちらをご覧ください^^

2.3 インスタンスタイプの選択

いきなりですが、コンピューターの処理速度と性能は、そのハードウェアに大きく依存します
また、プログラム（ソフトウェア）とはコードの集まりであり、いくら優れたコードを書いても、それを実行するハードウェア（CPU、メモリ、ストレージ、ネットワーク能力）が性能不足では、プログラムの潜在能力は引き出せないんですね

EC2のインスタンスタイプの選択は、まさにこのハードウェアの性能を選ぶプロセスです
利用可能なインスタンスタイプは多く存在し、各インスタンスタイプは特定の用途に最適化されています
例えば、計算処理に強い「コンピューティング最適化インスタンス」、メモリに富んだ「メモリ最適化インスタンス」、入出力操作が頻繁なアプリケーションに適した「ストレージ最適化インスタンス」などがあります

ここまでの内容を整理すると、AMIの選択とは「ソフトウェアの選択」であり、インスタンスタイプの選択とは「ハードウェアの選択」と言えます

下記はインスタンスタイプの選択画面ですが、インスタンスタイプにはt2.nanoやt2.microなど非常に多くのインスタンスタイプが存在します
ここで選択したインスタンスタイプを基にサーバーやアプリが処理を行うため、インスタンスタイプの選択は非常に重要になってきます

2.4 購入オプション

続いてEC2インスタンスの購入オプションについてです
AWSリソースは基本的に使用した分だけ料金が発生しますが、EC2インスタンスではさらに柔軟にコストを管理するための3つの購入オプションが用意されています

①オンデマンドインスタンス

オンデマンドインスタンスは最も柔軟性が高く、長期契約を必要としません
課金は時間単位、または秒単位（最低60秒）で行われ、必要に応じていつでもインスタンスを開始または停止できます
このオプションは、開発、テスト、短期的なプロジェクトに特に適しており、コストを抑えながら必要に応じてリソースをスケールアップまたはダウンさせることができます

②リザーブドインスタンス

リザーブドインスタンスは、1年または3年の定義された期間でEC2インスタンスを予約し、前払い金額や契約期間に基づいて大幅な割引を受けることができます
このオプションは既に安定して運用されているシステムや長期的なプロジェクトに最適ですが、契約途中でのキャンセルはできないため、利用計画は慎重に立てる必要があります

③スポットインスタンス

スポットインスタンスはAWSの未使用のコンピューティング容量を市場価格で購入することができるオプションで、入札価格を設定します
スポット料金がこの価格を下回るときにのみインスタンスが利用可能になりますが、料金が入札価格を超えると予告なくインスタンスが終了されることがあります
コスト効率を追求する一方で、予測不能な停止に対応できる用途に適しています

2.5 まとめ

ここまでEC2の概要を簡単に説明してきましたが、一旦これまでの内容を振り返ってみましょう

①EC2とEC2インスタンスの違い

• EC2: AWSのサービス名であり、仮想サーバーを提供するプラットフォームです
• EC2インスタンス: 実際の仮想サーバーそのもので、アプリケーションが動作する具体的な実行環境を指します

②AMI（Amazon Machine Image）

AMIは、EC2インスタンスを起動する際のテンプレートで、OS、アプリケーション、ストレージの設定などが含まれています
AMIを利用することで、一貫した環境で迅速にインスタンスを起動することが可能です

③インスタンスタイプ

AWSでは、異なるコンピューティング、メモリ、ストレージのニーズに応じて、多様なインスタンスタイプを提供しています
ユーザーは用途に合わせて最適なインスタンスタイプを選択することができます

④購入オプションの種類

EC2インスタンスは、オンデマンドインスタンス、リザーブドインスタンス、スポットインスタンスなど、異なる購入オプションがあります
これにより、コスト効率や利用条件に応じて、最適な運用計画を立てることが可能です

ここまではEC2の概要について説明してきましたが、この中でもAMIは非常に奥深いものです
そのため、ここからはAMIの詳細を見ていきましょう^^

3. AMIの徹底解説

3.1 AMIの基本

「2. EC2の基礎」でAMIの概要はお話ししましたが、ここからはAMIに含まれる下記4つの情報の詳細について深堀っていきます

1. オペレーティングシステム（OS）
2. アプリケーション
3. ルートデバイスのストレージ
4. 起動に必要な許可設定

3.2 AMIに含まれる4つの情報

①オペレーティングシステム（OS）

オペレーティングシステム（OS）は、コンピューターシステム全体を管理し、アプリケーションとハードウェア間の仲介役を務める基本ソフトウェアです
我々が利用するWindowsやmacにもOSは存在し、EC2インスタンスにもOSが存在しており、その役割は基本的に同じで「アプリケーションとハードウェア間の仲介役」をすることです

例えば、Windowsでは「コマンドプロンプト」、macOSでは「ターミナル」でコマンドを実行する場面を想像してみてください
この場面では、コマンドプロンプト(またはターミナル)がアプリケーションとして機能し、そこから入力されるコマンドに基づいてCPUやメモリなどのハードウェアが動作を開始します

具体的な流れとしては、ユーザーが入力したコマンドをOSが解釈し、OSがCPUやメモリなどのハードウェアに指示を出します
重要なのは、ユーザーのコマンドがOSによってハードウェアが理解できる形式に変換され、その後処理が進行するという点です

また、LinuxとWindowsでは使用できるコマンドが異なります
たとえば、Linuxでは「sudo」や「yum」コマンドが利用できますが、Windowsではこれらのコマンドは使用できません
これは、OSごとに異なるシステムコールや機能が備わっているためです
Windows OSで「sudo」や「yum」が使えないのは、そのOSがこれらのコマンドを解釈できないためです
簡単に言うと、各OSは自国の言語を利用するため、Linuxの言語(例として英語)をWindowsの言語(例として日本語)で理解できないのと同じです

EC2インスタンスにおいてもこの原則は同じで、選択したOSによって使用できるコマンドが異なります
例えば、Amazon Linux、Ubuntu、Windowsなど、多様なOSが選択可能ですが、EC2でWindows OSを選択した場合は、Linuxのコマンドは使用できません

②アプリケーション

AMIには、開発者がすぐに使用できるように様々なソフトウェアツールやアプリケーションが含まれています
これにより、開発者は同じ環境を毎回一から構築する手間を省くことができます

例えば、「てんちゃん」という転職者と企業をマッチングさせるアプリを開発するシナリオを考えてみましょう
このアプリは、AWSのリソースと通信する際に利用するAWS CLIを使用します
例としてLinuxサーバーを構築してそのLinuxサーバー上でアプリケーションを動かす場合、基本的にはAWS CLIを別途インストールする必要があるのですが、AMIにはAWS CLIや様々なソフトウェアツールがプリインストール(事前に含まれている)されています

パッケージマネージャーやセキュリティツール、AWS CLIなどが最初からインストールされていることで、特定の作業を実行するために必要なソフトウェアが最初から揃っており、開発者は同じセットアップを繰り返す手間を省くことができます

コンテナ使用時の考慮点

EC2インスタンス上でDockerコンテナを起動する場合、事前にDockerfileを使用してAWS CLIやyumなどの必要なアプリをインストールしておくため、基本的にDockerイメージにはアプリを実行するために必要なものがすべて含まれています
EC2インスタンス上でDockerコンテナを実行する場合、通常利用に比べてAMIにアプリをプリインストールする必要性が低くなります
ただし、セキュリティツールなどはプリインストールしておいた方が良い場合もあります

例えば、ウェブサーバーを運用するDockerコンテナでは、ファイアウォール設定やウイルス対策ソフトウェアを含めたセキュリティ対策が組み込まれたイメージを使用することで、安全な運用が保証されます
これにより、AMIの選択はコンテナの種類や運用環境によって異なることが明確になります

コンテナを利用しない場合、直接EC2インスタンス上でアプリケーションを実行するシナリオでは、プリインストールされたアプリが環境構築の時間短縮に役立ちます
このように、使用する技術に応じてAMIの役割は異なります

③ルートデバイスのストレージ

ここでは、AMIのルートデバイスのストレージに焦点を当てて解説します
そもそもルートデバイスとは、EC2インスタンスが起動する際に使用する主要なデータストレージのことです
このルートデバイスには二つの主要なタイプがあります

• Amazon EBS-backed AMI(以下EBS)
  • EBS（Elastic Block Store）を使用してデータを永続的に保存します
  • インスタンスが停止してもデータは保持されるため、長期間のデータ保存に適しています
  • ストレージのサイズ変更が容易で、データの量に応じてスケールアップやダウンが可能です
• Amazon instance store-backed AMI(以下インスタンスストア)
  • このタイプは一時的なストレージ（インスタンスストア）を利用し、EC2インスタンスと共に存在します
  • インスタンスの停止や終了とともにデータは失われるため、短期間のデータ保存に適しています

要するにルートデバイスのストレージとは、EC2インスタンスが利用するデータの保管場所であり、その種別によってデータの持続性や管理方法が異なります
EBSはデータの持続性を求める用途に、インスタンスストアは一時的なデータ保管に適しています

ルートデバイスもAMIと同じく非常に奥深いものですので、その詳細については「3.4 ルートデバイスタイプに関する深掘り」で解説しています
気になる方は是非ご覧ください^^

④起動に必要な許可設定

AMIに含まれる四つ目の情報である起動許可ですが、起動許可とは「誰がAMIを基にEC2インスタンスを起動できるか」を定める権限設定を指します

例えば、Amazon LinuxやMacOSのAMIは公開設定になっており、誰でもこれらを使用してEC2インスタンスを起動できます
これは、これらのAMIがパブリックに設定されているためです

一方で、自分で作成したAMIはデフォルトで非公開設定になっており、作成者のみがアクセス可能です
このような設定があるため、企業が独自のAMIを組織内でのみ利用することでセキュリティを強化することが可能になったりします

また、「AWS Marketplace」は第三者が作成したAMIを提供するプラットフォームであり、「Docker Hub」のように開発者がさまざまなAMIを提供しています
MarketplaceのAMIは一般に公開されており、広く利用可能ですが、安全であるとは限りません
中には脆弱性のあるAMIや悪意のあるAMIも存在するため、使用する際には慎重な選定が必要です

⑤AMIに含まれる4つの情報の整理

ここまでAMIについて解説してきましたが、その内容を簡単に振り返ります

1. OS: AMIにはOSが組み込まれており、ユーザーは必要に応じて異なるOSを選択してインスタンスを起動できます
2. アプリケーション: AWS CLIやセキュリティツールなど、事前にインストールされたアプリケーションが含まれています
   1. これにより、開発者は基本的なソフトウェアツールを都度準備する手間を省けます
3. ルートデバイスタイプ: これはインスタンスがデータを保存する場所を選択するオプションです
   1. 主にEBS（永続的なストレージ）とインスタンスストア（一時的なストレージ）の二種類があります
4. 起動に必要な許可設定: この設定により、AMIを公開または非公開に設定することが可能で、セキュリティの管理が強化されます

たとえ話で言うと、「AMI」とは車の設計図に似ています
設計図があるおかげで基本的な部品の配置場所が決まっており、都度設計をする必要がありません
選んだ設計図に基づいて部品を組み込むだけです
重要なのは、AMIが実際の車（仮想サーバー）ではなく、設計図であるという点です

AMIを基にして、具体的なEC2インスタンスが作成される過程は、「3.3 ルートデバイスタイプに関する深掘り」以降でさらに詳しく解説します

3.3 ルートデバイスタイプに関する深掘り

EC2インスタンスのルートデバイスタイプは「データの保存場所を選択するだけ」と理解されがちなのですが、実際にはもっと深い意味があります
そのため、ここではルートデバイスについて詳しく掘り下げます

①そもそもルートデバイスとは何なのか？

ルートデバイスとは、OSがインストールされているディスクのパーティションを指します
「何言ってんねんワレェェェ！！」って感じですが、一つずつ説明していきます！

②OSの役割

まず、OSはアプリケーションとハードウェア（例えばCPUやメモリ）の間で仲介します
たとえ話でいうと、アプリケーションは日本語しか話せず、ハードウェアは英語しか話せません
OSは両言語を話せる通訳のような存在で、双方のコミュニケーションを助ける立ち位置にいます

③OSの実態って何？

「OSはPCの心臓部」とよく言われますが、実際にはただのプログラムで、特定の目的のために作られています
その目的が、アプリケーションとハードウェア間の通信を取り持つことっていうだけですね

④OSはどこに存在するのか

次に、プログラムはどこかに配置されていないと実行できませんね
例えば、AWSのLambdaでプログラムを実行するには、コードをLambda関数にデプロイ(配置)する必要があります
OSもまた、動作するためには配置する場所が必要です

⑤パーティション

ハードディスクはデータの物理的な保管場所で、パーティションはその中で区切られた特定の領域です
これを現実世界に例えると、ハードディスクが荷物(データ)を保管する倉庫で、パーティションは倉庫内の特定のエリアのようなものです

⑥その上でルートデバイスとは何か

ルートデバイスとは、OSがインストールされているハードディスクのパーティションを指します
つまりルートデバイスとは倉庫の中のOSが存在する特定のエリアのようなものですね

これがEC2インスタンスが最初にアクセスするディスク領域であり、OSの起動と実行に必要なファイルやOS自体がここに格納されています

つまり、EC2インスタンスが起動するために最初にアクセスする場所 = ルートデバイス！ていう訳です

⑦結論、EC2インスタンスのルートデバイスタイプとは？

EC2インスタンスのルートデバイスタイプは以下の理解だけでとどまることがあります

• EBS
  • 永続的なストレージのため、長期保存に有効
• インスタンスタイプ
  • 一時的なストレージのため、一時保存に有効

しかし、EC2インスタンスのルートデバイスタイプとは単にデータの保持場所・保存期間だけを指しているのではなく、OSの配置場所も選択しているという事なのです

OSは起動時に必要な設定ファイルを読み込むのですが、OSを含めそれら設定ファイルも選択したルートデバイス内に配置されるという訳なんですね

「ルートデバイス = データの保存場所！」ではあるものの、OSとかもここに配置される！！という理解をしておきましょう^^

3.4 AMIを基にEC2インスタンスが起動する？

これまでの振り返り：AMIの役割

ここまで、「AMIはEC2インスタンスを構築するためのテンプレートとして機能する」と解説してきました
しかし、AMIから直接EC2インスタンスが起動するわけではありません

このセクションでは、ルートデバイスタイプがEBSのAMIに焦点を当て、その起動プロセスの違いを解説します（ルートデバイスタイプによって、EC2の起動プロセスが異なるため）

①AMIの実態

AMI自体は、OSやソフトウェアツールのデータを直接含まず、EC2インスタンスを起動するための情報のみを保持しています
「さっきAMIがOSやアプリケーションの情報を持つって言ってなかったっけ？？嘘つき！！」って感じですが、詳しく見ていきましょう^^

以下はAMIの主要な構成要素です

1. イメージのID
2. イメージのタイプ（EBSかインスタンスストアか）
3. EBSスナップショットへのリンク
4. アクセス権限設定
5. 起動時スクリプト（例：ユーザーデータ）

「イメージのタイプ」は、ルートデバイスの種類を示し、「EBSスナップショットへのリンク」は具体的なデータの位置を指します

つまり、AMIは上記のような情報を持っているだけで、OSやアプリケーションの情報は持っていないんですね

②そもそもEBSスナップショットとは？

AMIが持つ情報に含まれる「EBSスナップショットへのリンク」ですが、そもそもEBSとは何でしょうか？
EBS（Elastic Block Store）とは、AWSで提供されるデジタルストレージサービスです
このサービスは、データを安全に保存する「デジタル倉庫」と考えることができます(単にデータの保管場所って理解でOKです👍)

続いてスナップショットとは、「ある時点でのデータ状態の記録」として機能します
これは、データバックアップの一形態で、例えば、今日のデータが突然失われた場合でも、昨日のスナップショットがあれば、その時点までデータを復元することが可能になります
イメージとしてはタイムマシンに乗って過去に戻り、データを昨日の状態に「戻す」感じですね！

「EBS」と「スナップショット」を理解した上で「EBSスナップショット」とは、EBSボリューム(データの保存場所)内のデータを特定の時点で保存したものです

AMIに含まれる「EBSスナップショットへのリンク」とは、AMIが特定のEBSスナップショットを指し示す情報を持っているということです

③EBSスナップショットに含まれる情報

ではでは、EBSスナップショットにはどういった情報が含まれるのでしょうか？
EBSスナップショットには、AMIに関連付けられたOSやアプリケーションの実際のデータが含まれています
たとえば、Amazon Linux 2023のAMIを使用する場合、そのEBSスナップショットにはAmazon Linux 2023のOSやプリインストールされたソフトウェアが保存されています

つまり、AMI自体にはEC2インスタンスを直接起動するためのOSやソフトウェアツールが含まれていないものの、EBSスナップショットにはそれらの情報が保存されているのです！

整理すると、AMIが参照するEBSスナップショットが実際にEC2インスタンスの起動に必要な情報を保持しているという事ですね

ここで理解したことを踏まえて、次のステップに進みましょう^^

④OSやアプリケーションの配置場所

続いて、OSやアプリケーションはどこに配置されていないといけないのでしょうか？
より具体的に言うと、EC2インスタンスを起動するOSやその他設定ファイルはどこに存在しないとEC2インスタンスは起動できないのでしょうか？

結論としては、EC2インスタンスを起動する際、OSやアプリケーション（例えば、AWS CLIなどのツール）はルートデバイス内に配置される必要があります

これまでの説明から、OSやソフトウェアツールがルートデバイスに存在する必要があること、しかしこれらのデータはEBSスナップショットに保存されていることが分かりました
つまり、EC2インスタンスを起動するにはルートデバイス内にデータが必要だが、それらのデータはEBSスナップショットにあるという事ですね

では、実際のEC2インスタンスの起動時にはどのようなプロセスが行われるのでしょうか？
どんどん見ていきます

⑤EC2インスタンスの起動プロセス

EC2インスタンスを起動するプロセスの具体的な流れとしては、AMIに関連付けられたEBSスナップショットからデータを複製し、このデータをEC2インスタンスのルートデバイスに転送する流れになります
この転送されたEBSボリュームが、EC2インスタンスのルートデバイスとして機能するわけです

これにより、必要なOSやソフトウェアツールがEC2インスタンスのルートデバイス内に配置され、EC2インスタンスの起動が可能になるわけですね

EBSボリュームとEBSスナップショットの違い

• EBSボリューム
  • 実際にデータが保存されている場所であり、EC2インスタンスの実行中にデータを読み書きするためのストレージとして機能します
  • データの保存場所そのものですね
• EBSスナップショット
  • EBSボリュームの特定の時点でのデータの完全なコピーであり、バックアップ目的で利用されます

つまりEBSスナップショットもEBSボリュームの一つなのですが、「EBSスナップショットは特定の時点でのデータを示す」というのがEBSボリュームとの明確な違いです

EBSスナップショットからEBSボリュームを作成することで、スナップショット時点のデータ状態を新しいEC2インスタンスで利用することができるわけですね

⑥まとめ

EC2インスタンスをに起動するためには、AMIを介してEBSスナップショットからルートデバイスへ必要なデータを転送し、そのデータを基にインスタンスが構築されます
このプロセスは、レストランで料理が厨房（EBSスナップショット）で準備され、最終的にお客さんのテーブル（ルートデバイス）に運ばれる過程に似ていますね！

4. EC2のライフサイクル管理

ワイが最近地味に忙しいのと、しっかり解説しようとするとバリ重なのでTODO🙏
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html

5. 実践：EC2へアクセスしてみる

ここからは、手を動かしながら学びます
具体的には、EC2インスタンスを起動し、SSHで接続してみることで、EC2の仕組みについてより深く理解を深めます

5.1 このセクションのゴール

このセクションでは、EC2インスタンスと関連リソースを作成し、SSHでログインが可能かを確認することが目標です
ここではリソースの詳細な説明は省略しますが、実際の操作を通じて学びを深めます

5.2 リソースの作成手順

1. VPCの作成
2. EC2インスタンス用のサブネット作成
3. インターネットゲートウェイの作成
4. インターネットゲートウェイをVPCにアタッチ
5. メインルートテーブルにインターネットゲートウェイ向けのルートを設定
6. EC2インスタンスにアタッチするセキュリティグループの作成
7. EC2インスタンスの作成
8. SSH接続でログイン

以下が完成イメージです

5.3 VPCの作成

まずはVPCを作成します

作成完了でざんす

5.4 EC2インスタンス用のサブネット作成

次にサブネット作成します
先ほど作成したVPCを選択して、AZをap-northeast-1aにします

5.5 インターネットゲートウェイの作成

次にIGWを作成します

5.6 インターネットゲートウェイをVPCにアタッチ

IGWを作成出来たので、画面右側の「VPCにアタッチ」を選択して、VPCにIGWをアタッチします

アタッチしたいVPCを選択して作成します

5.7 メインルートテーブルにインターネットゲートウェイ向けのルートを設定

続いて、VPCを作成するとデフォルトで作成されるメインルートテーブルを修正します

画面右の「ルートを編集」を選択し

IGW向けのルートを追加します

5.8 EC2インスタンスにアタッチするセキュリティグループの作成

次にEC2インスタンスにアタッチするセキュリティグループを作成します
インバウンドルールにSSHを設定し、今回はマイIPを指定します

5.9 EC2インスタンスの作成

最後にEC2インスタンスを作成します
今回はAmazon Linux 2023とt2.microを選択します

Amazon Linux 2023の選択がAMIの選択(主にソフトウェア部分)であり、t2.microの選択がインスタンスタイプの選択(主にハードウェア部分)という訳ですね^^

SSH接続に利用するキーペアを作成します
補足ですが、「8. ワイが感じた疑問②：EC2へのSSH接続の仕組み」でEC2へのSSH接続の詳細を解説しているので、気になる方はご覧ください^^
「何のためのキーペア作成なん？これ？？」とかが分かります👍

作成したVPCとサブネットを設定し、セキュリティグループもアタッチします

インスタンス作成中なので、しばらく待ちます

完全に起動したら、作成したEC2インスタンスのチェックボックスをクリックし、接続ボタンをクリックします

5.10 SSH接続でログイン

SSHクライアントタブを選択し、Windowsであればコマンドプロンプト(macであればターミナル)でssh -i "○○" ec2-user@○○を実行します
※コマンドを実行するカレントディレクトリにキーペア作成時に発行された鍵を配置してください

ログインできました！

やっていることとしてはEC2インスタンスを取り巻く環境を作って、作成したいEC2インスタンスのAMIとインスタンスタイプの選択・VPCやセキュリティグループの設定をする程度なので、意外と簡単ですね！

続いて、EC2インスタンスを踏み台サーバーにしてRDSへアクセスしてみます！
もう少しで「EC2マスターですよろしく卍」と初めて会う人に名乗れるようになります！

6.1 EC2を踏み台サーバーにしてRDSへアクセスしてみる

このセクションでは、EC2インスタンスとRDS、その他関連リソースを作成し、EC2インスタンスを踏み台サーバーとしてRDSに接続できるかを確認することが目標です
実務でもこのような構成でRDSと通信することはあるので、しっかり身に付けていきましょう^^

6.2 リソースの作成手順

1. VPCを作成
2. インターネットゲートウェイを作成し、VPCにアタッチ
3. サブネットを作成
   1. EC2用のパブリックサブネットを一つ
   2. RDS用のプライベートサブネットを二つ（RDSの仕様により二つが必要）
4. EC2用ルートテーブルを作成
5. RDS用ルートテーブルを作成
6. EC2用セキュリティグループを作成
7. RDS用セキュリティグループを作成
8. EC2インスタンスを作成
9. RDSのサブネットグループを作成し、プライベートサブネット二つを指定
10. RDSインスタンスを作成
11. EC2にSSHでログインし、Postgresをインストール
12. EC2からRDSに接続し、データベース一覧確認コマンドを実行

以下が構成図です！

6.3 VPCを作成

まずはVPCを作成します

6.4 インターネットゲートウェイを作成し、VPCにアタッチ

次にIGWを作成し、

VPCにアタッチします

6.5 サブネットを作成

続いてEC2インスタンス用のパブリックサブネットと、RDS用のプライベートサブネットを作成します

今回はEC2インスタンス用には1つのパブリックサブネットを設定し、RDS用には2つのプライベートサブネットを作成します
プライベートサブネットを二つ作成する理由としては、RDSは冗長化構成を組むため、少なくとも2つのサブネットが必要だからです
これは、RDSがサブネットグループを使用して構成されるため、2つ以上のサブネットが必須となる仕様に基づいているんですね

まずは先ほど作成したVPCIDを選択します

test-public-subnet-aというEC2インスタンス用のパブリックサブネットを作成します

続いてtest-private-subnet-aという一つ目のRDS用のプライベートサブネットを作成し、

test-private-subnet-cという二つ目のRDS用プライベートサブネットも作成します

出来ましたね^^

6.6 EC2用ルートテーブルを作成

次に、EC2用のルートテーブルを作成します

次に、EC2インスタンス用のルートテーブルにIGW向けのルートを設定します

最後に、EC2インスタンス用のルートテーブルを表示した状態で「サブネットの関連付けを編集」を選択し、

test-public-subnet-aを選択して関連付けを完了させます

6.7 RDS用ルートテーブルを作成

続いてRDSも同じく、RDS用のルートテーブルを作成します

こちらも同じくサブネットとルートテーブルを関連付けるため、test-private-subnet-aとtest-private-subnet-cを選択して関連付けを完了させます

6.8 EC2用セキュリティグループを作成

ではでは、次にEC2インスタンスにアタッチするセキュリティグループを作成します
今回もEC2インスタンスにはSSHでログインするため、インバウンドルールにSSHを設定します

アウトバウンドルールも設定する必要があるのですが、一旦デフォルトでOKです

6.9 RDS用セキュリティグループを作成

続いてRDS用のセキュリティグループを作成します
今回はEC2インスタンスからのアクセスが来るため、インバウンドルールでPostgreSQLとEC2インスタンスにアタッチするセキュリティグループを指定します

アウトバウンドルールはデフォルトでOKです

EC2インスタンスのアウトバウンドルールではRDS用のルールを設定する必要があったのですが、先ほどのタイミングではまだRDS用のセキュリティグループが存在していなかったため、このタイミングで設定します
アウトバウンドルールでPostgreSQLを設定し、RDSにアタッチするセキュリティグループを指定します

ここまでで、EC2インスタンスはアウトバウンドルールとしてRDSのセキュリティグループを許可し、RDS用のインバウンドルールとしてEC2インスタンスのセキュリティグループを許可する設定が完了しました^^

6.10 EC2インスタンスを作成

続いてEC2インスタンスを作成します
今回もAmazon Linux 2023をAMIとして利用します

インスタンスタイプは無料のt2.microを利用します

SSH接続する際に必要なキーペア作成を作成します

ネットワーク設定で、ここまでで作成してきたVPCとサブネット、セキュリティグループを設定します

他はデフォルトでOKですので、EC2インスタンスの作成を完了させましょう^^

6.11 RDSのサブネットグループを作成し、プライベートサブネット二つを指定

続いてRDSのサブネットグループを作成します

サブネットはRDS用に作成したサブネットtest-private-subnet-aとtest-private-subnet-cを選択します

6.12 RDSインスタンスを作成

最後に、RDSを作成します

今回はPostgreSQL 15.4を利用します

下記は適当な値を入力します

下記もデフォルト設定のまま進みます

サブネットグループは先ほど作成したものを設定し、セキュリティグループはRDS用のセキュリティグループをアタッチします

他はデフォルト設定で、RDSの作成を完了させましょう^^

6.13 EC2にSSHでログインし、Postgresをインストール

ではでは、まずはEC2インスタンスにSSHでログインします

出来ましたね！

6.14 EC2インストールからRDSに接続し、データベース一覧確認コマンドを実行

まずは、EC2インスタンスからRDSデータベースへ接続する手順について説明します
接続する前の準備として、以下のコマンドを順に実行してください

1. sudo dnf update -y：インストールされている全てのパッケージを最新の状態に更新します
2. sudo dnf install postgresql15：RDSのPostgreSQLデータベースと接続するためのクライアントソフトウェアをインストールします

順に実行していきます

エラーログをスクショしていなかったのですが、、私の環境ではsudo dnf update -yを実行するとエラーが発生しました
原因としては、EC2インスタンスが外部にアクセスしてパッケージを取得しようとした際に、アウトバウンドルールでHTTPS向けのルールを設定していなかったため、外部に出られずエラーになっていました

EC2インスタンスのセキュリティグループの設定を見直して、アウトバウンドルールにHTTPSを許可することで無事コマンドが通りました
(下記のルールに更新)

sudo dnf update -yとsudo dnf install postgresql15が実行出来たら、以下コマンドでPostgresにアクセスします

psql --host=test-db-cluster-instance-1.○○○○.rds.amazonaws.com --port=5432 --dbname=postgres --username=postgres

hostやdbnameなどは正しいものに置き換えてください
(デフォルト設定だとportは5432, dbnameとusernameはpostgresのことが多いです)

コマンドを実行すると、DBに入ることが出来ました^^
では最後に\lでDB一覧を表示してみます

出来ました！！
これでEC2インスタンスを踏み台にしてRDSへ接続することが完了したので、今日からあなたもEC2マスターです！！
お疲れ様です！！

7. ワイが感じた疑問①：EC2もサーバー、Apacheもサーバー、サーバーの上でサーバーが動く？

みなさんは「Apache」という用語を聞いたことがありますか？
簡単に説明すると、ApacheはWebサーバーの一種です
Webサーバーとは、ウェブページやアプリケーションに必要なデータを配信する役割を持つソフトウェアです
つまり、私たちがサイトにアクセスすると、その情報を返してくれるのがWebサーバーで、その中の一つがApacheという感じです^^

このApacheは、EC2インスタンス上でも起動可能です
つまり、EC2インスタンスの上でApacheを動かすことができるわけです
ここで私は一の疑問を感じました
「EC2インスタンスもサーバー、Apacheもサーバー...サーバーの上でサーバーが動いているって、どういうこと？」

結論としては、、EC2インスタンスは「実行環境」を提供するサーバーであり、Apacheはその上で動く「アプリケーションレベルのサーバー」という関係性でした
EC2インスタンスはWebアプリケーションを直接ユーザーに提供するわけではなく、様々なアプリケーションやソフトウェアが動作するための基盤として機能しているわけですね

逆に、ApacheのようなWebサーバーは、実行環境の上で動き、直接ユーザーにサービスを提供します
現実世界に例えると、EC2インスタンスは土地のようなもので、Apacheはその土地に建てられた店舗のような存在ですね
店舗が顧客にサービスを提供するように、Apacheはウェブページやアプリケーションをユーザーに提供しているわけですね

技術的な詳細を付け加えると、ApacheはEC2インスタンスのポートを使用してサーバーを起動し、ネットワーク上で「リッスン」します
つまり、ApacheがEC2インスタンスの一部をWebサーバーとして使用している訳ですね！

8. ワイが感じた疑問②：EC2へのSSH接続の仕組み

今回、EC2への接続にはSSHを利用しました
みなさん、EC2インスタンス作成時にキーペアを作成したこと、そしてそのキーペアを使ってSSHでログインする流れ、何となく覚えていますか？
では、なぜSSHでの接続でキーペアを利用するのか、その理由を詳しく見ていきましょう

SSHとは？

そもそもSSH（Secure Shell）は、遠隔地のコンピュータに安全に接続するためのプロトコルです
このプロトコルを使うと、データが全て暗号化されるため、セキュリティが保たれます
自宅からオフィスのサーバーにアクセスする場合や、遠隔地にあるサーバーのメンテナンスが必要な時にSSHが活躍します
映画で見るハッカーが遠隔操作でシステムに侵入するシーン、あれがSSHの一種の使用方法をドラマチックに表現したものですね

キーペアとは何か？

SSH接続には「公開鍵認証方式」という認証メソッドが使われます
これは、セキュリティの高いデジタルキーの一組を使って認証を行う方法で、キーペアと呼ばれる「公開鍵」と「秘密鍵」から成り立っています
EC2インスタンスに公開鍵を登録しておき、自分が持つ秘密鍵を使ってログインします
これにより、許可された人だけがアクセスできるようになります
(公開鍵認証方式の詳細は後ほど詳しく説明します)

SSHとTelnetの比較

元々よく遠隔操作で使われたTelnetは、通信内容が暗号化されないためセキュリティリスクが高いとされていました
SSHはその安全な代替として開発され、通信過程での情報を暗号化することで、より安全な遠隔操作を実現しています

公開鍵暗号方式の基本

EC2インスタンスへのSSH接続を理解するためには、公開鍵暗号方式の知識が必要です
この方式は、暗号化手法の中で非常に重要な位置を占めています
主要な暗号化方式は以下の三つです

1. 公開鍵暗号方式
2. 共通鍵暗号方式
3. ハイブリッド暗号化方式

公開鍵暗号方式では、公開鍵と秘密鍵の二つのキーペアを使用します
この方式の大きな特徴は、データの暗号化に公開鍵を使用し、復号には秘密鍵を使用する点です
公開鍵で暗号化されたデータは、対応する秘密鍵がないと復号できません
これにより、たとえ暗号化されたデータが盗まれたとしても、秘密鍵が安全であれば内容を解読されることはありません

しかし、もし秘密鍵が盗まれた場合は、そのキーを用いて暗号化された全てのデータが危険にさらされます
そのため、秘密鍵の管理は非常に重要です

実際の使用例

具体的な使用例としては、誰かがあなたにデータを送信する際に、あなたの公開鍵を使用してデータを暗号化します
この暗号化されたデータはインターネットを通じて安全に送信され、あなたは自分の秘密鍵を用いてそれを復号することができます
このプロセスにより、第三者によるデータの盗聴や改ざんを防ぐことが可能になります

SSHでのコネクション確立の流れ

ここでは、EC2インスタンスへのSSH接続ではなく、一般的なSSH接続の仕組みについて解説します

SSH接続では、操作を行う側を「クライアント」、操作される側を「サーバー」と呼びます
クライアントには秘密鍵が、サーバーには対応する公開鍵が配置されている必要があります

接続プロセスは以下のように進行します

1. 認証の開始: クライアントがサーバーにSSHによるログインを依頼すると、サーバーは乱数を生成します
2. 乱数の暗号化: 生成した乱数はクライアントの秘密鍵に紐づく公開鍵で暗号化され、クライアントに送信されます
3. 乱数の復号とハッシュ生成: クライアントは受け取った暗号化された乱数を秘密鍵で復号し、その乱数からハッシュ値を生成してサーバーに送り返します
4. ハッシュの照合: サーバーは自身で生成した乱数から同じハッシュ値を生成し、クライアントから送り返されたハッシュ値と照合します
5. コネクションの確立: ハッシュ値が一致すれば、クライアントの認証が成功し、コネクションが開始されます

(汚くてすみません...)

このプロセスはセキュリティを確保しつつ、適切なクライアントのみがサーバーにアクセスできるように設計されています
少し複雑ですよねw

EC2とSSHの関係性とキーペアの意義

では続いて、EC2へSSH接続する際の流れを見ていきます

EC2とSSHの関係性

EC2へのSSH接続も、一般的なSSH接続のプロセスと同じです
この場合、アクセスするPCが「クライアント」、EC2インスタンスが「サーバー」として機能します
クライアントはEC2サーバーにログインするためにSSHプロトコルを使用し、セキュアな通信チャネルを確立します

EC2で発行するキーペアの正体

「EC2で発行するキーペアの正体」はSSH接続の際に利用する秘密鍵何ですね
EC2側ではその秘密鍵に紐づく公開鍵を持っており、その公開鍵で暗号化したデータをローカルにある秘密鍵で復号し、ハッシュ値を作成してEC2へ送り返すことで、SSH接続が可能になっているわけですね

キーペアの正体、分かりましたでしょうか！！

結論：SSHの重要性

SSHは、データを安全に暗号化してやり取りすることができる遠隔操作の仕組みです
この技術により、インターネットを介してEC2インスタンスを含むサーバー操作が可能になるわけですね

「SSH = サーバーとかを遠隔操作するときに安全に利用できるやつ！！」

9. ワイが感じた疑問③：「EC2は運用が大変」って聞くけど実際どうなん？

よくFargateと比較してEC2は運用管理が大変って聞きますよね
「実際どうなん？？」と思ったので備忘録も兼ねて解説していきます

サーバー管理の課題

まず、EC2を利用するとサーバー管理が必要になります
これは、Fargateのサーバーレス環境と比べて大きな違いですね

Fargateでは、ユーザーはOSやセキュリティアップデートを気にする必要がなく、管理業務から解放されますが、EC2ではそのすべてを自分で手がける必要があります

パッチ適応

EC2では、OS（例：Amazon Linux 2023）やセキュリティパッチの適用がユーザーの責任です
これにはSSH接続を使ってEC2インスタンスにアクセスし、コマンドを手動で実行する作業が含まれるわけですね(他のやり方もあるみたいですが)

Fargateではこれらの作業が不要であり、知識不足や手順ミスが原因でヒューマンエラーを引き起こすリスクも低減されるといった点も大きな違いですね

EC2の利点

ただ、EC2はデメリットだけが存在するわけではなく、もちろん利点も存在します

カスタムAMIの利用、CPUやメモリの自由な設定、踏み台サーバーやWAFとの連携など、EC2の柔軟性と拡張性は大きな魅力なので、メリットはありデメリットもあるといった感じですね

結論

EC2の運用はサーバー管理に直結し、技術的な知識と注意を要しますが、それによって得られるカスタマイズの自由度と拡張性は、特定の状況やニーズには不可欠です
そのため、「Fargateが良い、EC2が悪い」と単純に決めるのではなく、状況に応じた適切な選択が求められるわけですねー

10. まとめ

ここまで読んでくださった読者の皆様、ありがとうございました！！
正直な感想として、書きすぎました！w
次は「ELBってなんやねん」を書く予定ですが、たまに寄り道しているので腰を据えて待っててください^^

良かったらTwitterフォローしてねっ！
https://twitter.com/mi_01_24fu