AWS入門 第2話 - 仮想のネットワークを作ってサーバーを立ててみよう
2024.10.11こんにちは。まるとです。
今回はAWS上に自身だけのネットワーク環境の作成し、作成したネットワーク環境に対して仮想マシンを配置していきたいと思います。
Amazon VPC 〜自分だけのネットワーク環境を作る〜
組織がネットワーク環境を構築する際は、もちろんルーターやL3スイッチなど物理的な機器や配線等が必要となります。
AWSでは、Amazon Virtual Private Cloud (VPC、以下VPCと表記します。)と呼ばれるサービスを使用することで、AWSクラウド上に論理的に分離された仮想のネットワークを構築することができます。
ブラウザやコマンドラインを使用して設定を行うことで、効率的に自組織のネットワークを構築することが可能です。
オンプレミス環境では物理機器の設置や配線が必要ですが、AWSではこれらが不要であるため、初期費用を抑えつつ迅速にネットワークの構築が可能です。
それでは早速作っていきましょう。
AWSマネジメントコンソールを開く
では、早速AWSに環境構築をするために「AWSマネジメントコンソール」と呼ばれるAWS上のリソースをブラウザ上で管理、操作するための画面があります。
AWSマネジメントコンソールを開くには以下のURLをクリックするか、AWS公式サイトの右上にある「コンソールにサインイン」をクリックします。
サインインが完了すると以下のような画面が開きます。これがAWSマネジメントコンソールのホーム画面です。
※画像は筆者のそこそこ使い込んでいるアカウントのため、画面は少し異なる可能性があります。
また、右上のリージョン選択からどの地域にリソースを構築するのかも選択できます。
今回は東京リージョンにリソースを構築していくために、「アジアパシフィック (東京)」を選択してください。
右上に「東京」という表示があればOKです。
Amazon VPCダッシュボードを開く、デフォルトVPCに関する補足
続いてネットワークをAWS上に構築するため、先ほども挙げたVPCの構築を行います。
それでは早速、VPC ダッシュボードを開いて見ましょう。
VPCの設定画面を開くには、AWSマネジメントコンソールの左上にある検索ボックスに「VPC」と入力してサービス名をクリックします。
※検索ボックス横にある「サービス」からもVPC ダッシュボードを開くことができますが、検索ボックスから開いた方が速いのでおすすめです。
VPCダッシュボードを開くと最初は以下の画面となります。
最初のダッシュボード画面では、選択されたリージョンに存在するリソースの数などが表示されます。
まずは、VPCの一覧を見て見ましょう。VPCの一覧を確認するにはサイドバーの「仮想プライベートクラウド -> お使いのVPC」を選択します。
クリックすると、VPCの一覧が表示されます。
お気づきの方もいらっしゃると思いますが、特に新規AWSアカウントの場合、標準でVPCが一つ存在します。
これを「デフォルトVPC」と呼びます。
デフォルトVPCは直ぐにAWSリソースを構築できるよう、AWSアカウントの新規作成時に自動で作成されます。
後述するEC2（仮想マシン）を新規で配置するには、非常に便利です。
一方で、本記事では新規にネットワークを構築することに趣を置いていること、サブネットの切り分けなど、細かなカスタマイズを入れることから今回使用しない方向でいきます。
なお、デフォルトVPCについては、公式ドキュメントで詳しい説明がございます。
VPCを一から構築する
それでは改めて一からVPCを構築していきましょう！
今回作成する構成は以下を想定しています。
※画像ではアベイラビリティーゾーンと呼ばれるものが1つになっていますが、これは検証のためです。
本番環境の場合はアベイラビリティーゾーンを2つ以上にすることをおすすめします。理由は後述します。
図に出てくる用語
| 用語 | 説明 |
|---|---|
| Internet Gateway | インターネットとの接続ポイント |
| Availability Zone (AZ、アベイラビリティーゾーン) | データセンターの集合体の一つ、各AZは地理的に離れたところにある |
| Public Subnet（パブリックサブネット） | 標準でVPC外と通信ができるネットワーク |
| Private Subnet (プライベートサブネット) | 標準でVPC外と通信ができないネットワーク |
例えば1組織に例えると以下のような形になります。
| 用語 | 説明 |
|---|---|
| Internet Gateway | 組織との出入り口 |
| VPC | 組織 |
| Availability Zone | 支社、もしくは支店 |
| Public Subnet | 組織の人なら誰でも入れる部屋 |
| Private Subnet | 組織の中でも限られた人が入れる部屋（セキュリティルームなど） |
そしてこれらを合わせることで一つのVPCができあがります。
それでは実際に作ってみましょう！
VPCを作成するには、オレンジ色のボタン「VPCを作成」をクリックします。
「VPCを作成」をクリックすると、作成するリソースの種別、各種項目の設定値を入力できる画面になります。
従来はVPCを作成し、その後サブネットの定義やその他の設定を順番に行う必要がありましたが、現在は「作成するリソース」で「VPCなど」を選択することで、VPC、サブネットの定義を一括でできます。
そのため、今回は「作成するリソース」で「VPCなど」を選択します。
名前タグの自動生成
それでは設定していきましょう。まず、最初に名前タグを指定していきます。
AWSのリソースにはほとんどの場合、リソースにタグと呼ばれるものをつけることができます。
例えば、本番環境であることを示すタグ、コストの分類を示すタグ...というように目印をつけることができます。
特にNameタグと呼ばれる名前タグは、リソースを識別するための重要なタグとなります。
今回はわかりやすく、<名前>VPCとつけていきます。
特に、「自動生成」を有効化している場合、テキストフィールドに名前を入力するだけで、この後作成されるリソースに適切な名前を自動で生成してくれます。
プレビューの各リソースの名前を見てみてください。
IPv4 CIDR ブロック
続いて、IPv4 CIDR ブロックを指定していきます。
ここではこれから作成するVPC自体のネットワーク範囲を指定していきます。
今回は最初から指定されている10.0.0.0/16を指定していきます。
もし、本番環境などでCIDRブロックの指定に悩んだ場合は、以下のブログも合わせてお読みください。
IPv6 CIDR ブロック
続いて、IPv6 CIDR ブロックの指定を行います。
もし、各リソースにIPv6アドレスを付与したい場合は、ここでAmazon 提供のIPv6 CIDR ブロックを指定します。
IPv6アドレスを付与したくない、もしくはご自身で管理しているIPv6 CIDR ブロックなどを利用したい場合は、「IPv6 CIDR ブロックなし」を選択します。
※IPv6 CIDR ブロックは後から追加、設定できます。
テナンシー
続いて、テナンシーの選択を行います。
通常、AWSの基盤側となるハードウェアは他のユーザと共有となっています。
各ユーザごとに仮想化により環境は分かれているものの、ライセンスやコンプライアンスなどの観点からハードウェアを専有したい場合、「専有」を選択します。
なお、ハードウェアを占有するため、デフォルト（ハードウェアの共有）よりも費用が高めとなります。
多くの要件ではテナンシー「デフォルト」で問題ありませんが、要件によっては専有を選択するケースもあります。
今回は「デフォルト」を選択します。
アベイラビリティーゾーンの数
アベイラビリティーゾーン（以下、AZ）とは色々なデータセンターの集合体の一つです。
例えば、災害などが発生した際やなんらかの障害（電源、ネットワークなど）により、サービスを稼働できなくなるリスクがあります。
このような問題が発生してもサービスを稼働できるよう、各リージョンにはAZが最低3個以上あります。
また、各AZは他のAZから物理的に離れた距離にあるものの、100km以内に配置されています。
2つのAZにリソースを配置しておくことで、1つのアベイラビリティーで障害が発生しても、もう一つのAZでサービスを稼働し続けることができます。
そのため耐障害性、可用性の観点から本番環境の多くでは2つのアベイラビリティーゾーンに跨がった構成を撮ることが多く見受けられます。
ただし、今回はお試しのため、アベイラビリティーゾーンの数は「1つ」に設定します。
「AZのカスタマイズ」をクリックすることで、どこのAZに配置するかも指定できますが、今回は任意の項目を指定します。
パブリックサブネットの数・プライベートサブネットの数
続いて、パブリックサブネット、プライベートサブネットの数を指定していきます。
パブリックサブネットでは名前の通り、公開するサブネット、つまりインターネットと接続できるサブネット、プライベートサブネットはインターネットからアクセスできないサブネットとなります。
例えば、Webサーバーは外部に公開されてほしいけど、データベースにはインターネットから接続できないようにしたいという場合に、Webサーバーはパブリックサブネット、データベースはプライベートサブネットに配置する、という設計ができます。
なお、本来サブネットを作成しただけでは、パブリック、もしくはプライベートサブネットと自動で切り分けが行われません。
VPCがインターネットと接続するにはインターネットゲートウェイと呼ばれる、インターネットとの接続地点が必要となります。
また、パブリックサブネットにするにはインターネットゲートウェイの他、ルートテーブルと呼ばれるネットワークの経路を指定する必要があります。
ただし、今回は最初に「作成するリソース」で「VPCなど」を指定しているため、インターネットゲートウェイの配置やルートテーブルの設定が自動で行われます。
そのため、パブリックサブネットの数とプライベートサブネットの数を指定するだけで、自動で切り分けが行われます。
各種サブネットの数も本番環境では要件に沿って定める必要がありますが、今回はお試しのためそれぞれ1つに指定します。
また、配置するリソース数などによって各サブネットのCIDRブロックをカスタマイズすることを推奨しますが、今回は既に設定されている値を指定します。
NAT ゲートウェイ
続いてNAT ゲートウェイについて説明します。
先ほど、パブリックサブネット、プライベートサブネットの説明で、パブリックサブネットはインターネットと接続できる、プライベートサブネットはインターネットと接続できない、という記載をしました。
ただ、仮にプライベートサブネットにLinuxの仮想マシンを配置した場合、OSやミドルウェアのアップデートがインターネットからできない状態となります。
このように状況によっては外部からはアクセスできないようにしてほしいけど、プライベートサブネットからインターネットへの中から外向きには接続をできるようにしたい、という要件のためにNAT ゲートウェイと呼ばれるものがございます。
プライベートサブネットからインターネットへの接続手段としてNATゲートウェイの他、NAT変換を行うEC2 インスタンス、通称NAT インスタンスと呼ばれるものがありますが、NAT ゲートウェイからユーザ側で管理が不要となるマネージドサービスとなります。
ただし、NAT ゲートウェイは時間あたりの課金に加えてデータ転送量に応じた課金が発生するため、設計上必要かどうかを検討した上で配置する必要があります。
今回はプライベートサブネットでインターネットの接続は不要とするので「なし」に設定します。
VPC エンドポイント
他AWSサービスとインターネットを介さずに接続したい、という要件に向けてVPC エンドポイントと呼ばれるものがあります。
例えばオブジェクトストレージサービスである、Amazon Simple Storage Service (Amazon S3)との通信はコンプライアンス・セキュリティの観点からインターネットを介したくないという場合に利用します。
VPC エンドポイントにはインターフェイス型とゲートウェイ型の2種類がございます。
これらの違いについては以下のブログを参照ください。
なお、本画面ではS3ゲートウェイのみの表示となっていますが、他にも様々なVPC エンドポイントがございます。
今回は使用しないので「なし」に設定します。
DNS オプション
パブリックDNS名を割り当てたい場合、DNS ホスト名の有効化、Amazon 提供のDNSサーバーを介したDNS解決を使用したい場合は、DNS解決を有効化にそれぞれチェックを入れます。
今回は両方ともチェックを入れた状態にします。
実際に作成する
ここまで設定値を見てきました。本検証の場合、以下のような設定値となっていると思います。
| 項目名 | 設定値 |
|---|---|
| 作成するリソース | VPCなど |
| 名前タグの自動生成 | チェックあり、任意の名前 |
| IPv4 CIDR ブロック | 10.0.0.0/16 |
| IPv6 CIDR ブロック | IPv6 CIDR ブロックなし |
| テナンシー | デフォルト |
| アベイラビリティゾーン (AZ) の数 | 1 |
| AZ のカスタマイズ/第 1 アベイラビリティーゾーン | ap-northeast-1a |
| パブリックサブネットの数 | 1 |
| プライベートサブネットの数 | 1 |
| サブネット CIDR ブロックをカスタマイズ/ap-northeast-1a のパブリックサブネット CIDR ブロック | 10.0.0.0/20 |
| サブネット CIDR ブロックをカスタマイズ/ap-northeast-1a のプライベートサブネット CIDR ブロック | 10.0.128.0/20 |
| NAT ゲートウェイ ($) | なし |
| VPC エンドポイント | なし |
| DNS オプション/DNS ホスト名を有効化 | チェックあり |
| DNS オプショナル/DNS 解決を有効化 | チェックあり |
それでは実際に「VPCを作成」ボタンをクリックしてみましょう。
ボタンをクリックすると設定された値に沿ってVPCが作成されます。これにてVPCの作成・設定は完了です。
続いて、作成したVPCに仮想マシンを起動してみましょう！
仮想マシンを起動する
続いて、AWS上に仮想マシンを起動していきます。
仮想マシンを起動するにはAmazon Elastic Compute Cloud（Amazon EC2）と呼ばれるサービスを使用します。
前述の手順で自身だけの仮想ネットワーク（VPC）を作成したため、その中に仮想マシンを起動していきます。
なお、仮想マシンの単位をインスタンスを呼びます。以降もこのインスタンスという表現を使っていきます。
それでは早速やっていきましょう！
※インスタンスの起動の際、動作などを細かく指定できる「高度な詳細」という設定項目がございますが、本記事では割愛します。
気になる方は以下をご確認ください。
AWSマネジメントコンソールでEC2のページを開く
それではEC2 インスタンスを起動するためにEC2のページを開きます。
RDSの時と同様に左上の検索ボックスに「EC2」と入力、サービス名をクリックします。
すると、以下のような画面が表示されます。これがEC2 ダッシュボードです。
インスタンスを起動する
EC2 ダッシュボードを開けたら早速、インスタンスを起動してみましょう！
「インスタンスを起動」というオレンジ色のボタンをクリックします。
「インスタンスを起動」というオレンジ色のボタンをクリックすると、どのような設定で起動するのか指定できる画面に移ります。
それでは順に設定していきましょう！
※名前とタグという項目の説明は割愛します。必要に応じて適切な名前を付けてください。
Amazon マシンイメージの選択
まず最初に目につくのが「アプリケーションおよび OS イメージ (Amazon マシンイメージ)」です。
中でも特にEC2を使っていると出てくるAmazon マシンイメージ（以下、AMI）について、簡単に説明するとOSやアプリケーションなどEC2 インスタンスの起動に必要な情報がまとまったテンプレートです。
本来であれば、LinuxなどのOSのインストールなどからセットアップを行う必要がございますが、OSインストール後の状態をイメージとして保存し、インスタンスを新規構築時にイメージから起動することで実際に利用可能になるまでの時間が短縮します。
今回はAmazon Linux 2023と呼ばれる、AWSが提供しているLinuxを使用します。
クイックスタートタブにある「Amazon Linux」を選択肢、Amazon マシンイメージ (AMI)では「Amazon Linux 2023 (ami-0ef29ab52ff72213bという記載があるもの)」、アーキテクチャは「64 ビット (x86)」を選択します。
これでAmazon Linux 2023がインストールされたインスタンスが起動します。
インスタンスタイプの選択
インスタンスタイプはCPUやメモリをはじめとしたスペックのテンプレートです。
CPUやメモリ、ネットワーク性能など分かれていますが、t系、m系など最初につく英字によって、スペックの特徴が変わります。
全ては取り上げませんが、よく聞くt系、m系インスタンスについてご説明します。
t系インスタンスはバースト可能なインスタンスタイプです。
一定のCPU使用率よりも低い使用率で使うと、CPUクレジットと呼ばれるクレジットが加算されていきます。
CPU使用率の基準値（例: 10%、20%など）を超えて使用する場合はCPUクレジットを消費して、基準値以上のCPUを利用できます。
CPUクレジットが枯渇した場合、基準値までCPU使用率が制限されるため、一時的な検証や特定の時間以外は負荷が低いシステムなどで用いられることが多いです。
また、無料利用枠として設定されていることから、個人が一時的に学習する用途でも使用されることがあります。
m系インスタンスはt系とは違い基準値の指定が存在せず、vCPUの数やメモリなどのバランスが考慮されたインスタンスタイプです。
常に一定のCPU使用率がある、vCPUとメモリを程よく使うなど、多くのユースケースに合致したインスタンスタイプです。
サービスを一般公開する、本番環境である、という利用であれば1つの案としてm系インスタンスを使用することがおすすめです。
なお、いきなり大きめのインスタンスタイプを選択する必要はありません。
インスタンス起動後もインスタンスタイプの変更は可能なため、まずは小さめのインスタンスタイプで足りなくなったら大きくする、反対に過剰なスペックなので後から小さいインスタンスタイプに切り替える...ということができます。
今回は検証かつ学習目的のため、無料利用枠にも設定されているt2.microを使用していきます。
キーペア (ログイン)
インスタンスにログインするためのキーペア（公開鍵と秘密鍵のセット）です。
SSH接続などに使用します。
初めてEC2を使用する場合はキーペアが存在しないため、「新しいキーペアの作成」をクリックします。（キーペア作成時の設定は任意の値）
ネットワーク設定
続いて、EC2 インスタンスのネットワーク設定です。
どこのVPC、サブネットに配置するのか、グローバルIPアドレスを割り当てるのか、ファイアウォールの設定などはこの項目で行います。
通常ではセキュリティグループと呼ばれるファイアウォールの設定のみが有効化されていますが、せっかくなのでネットワーク設定の右側にある「編集」ボタンをクリックして全ての項目を見てみましょう。
設定値としては以下のようになっています。
※高度なネットワーク設定は割愛
| 項目名 | 説明 |
|---|---|
| VPC | 起動先のVPC |
| サブネット | 起動先のサブネット |
| パブリックIPの割り当て | グローバルIPv4アドレスを割り当てるかどうか（パブリックサブネットに配置した場合のみ） |
| ファイアウォール(セキュリティグループ) | プロトコルやポートを元にしたファイアウォール、ルールとして追加したものが許可される |
それでは設定していきましょう。VPC、サブネットは前述の手順で作成したものを使用します。
この後の手順でインスタンスへの接続を行うので、パブリックサブネットに配置しつつ、パブリックIPの自動割り当てを有効化します。
なお、パブリックサブネットに配置、パブリックIPの自動割り当てをしなくてもインスタンスに接続する手段はございますが、比較的簡単に接続するために上記の方法で設定します。
続いて、ファイアウォール (セキュリティグループ)の設定です。
EC2ではOSの外側にセキュリティグループと呼ばれるファイアウォールが存在します。
セキュリティグループはルールにない項目は拒否する、ホワイトリスト側のファイアウォールです。
初めて触る場合はセキュリティグループが存在しない状態のため、「セキュリティグループを作成」をクリックし、任意のセキュリティグループ名、説明を記載します。
また、SSHでの接続はあらゆる場所から接続を許可するのは、セキュリティ上あまり好ましくありません。
今回はAWSマネジメントコンソール上からインスタンスに接続を行えるようにしたいため、ソースタイプから「カスタム」を選択して、ソース「com.amazonaws.<リージョン>.ec2-instance-connect」を指定します。
「com.amazonaws.<リージョン>.ec2-instance-connect」はEC2 Instance Connectと呼ばれるAWSからインスタンスに接続できるサービスのエンドポイントです。
これでネットワークの設定は完了です。
本手順に沿って設定を行った場合、以下のようになっています。
| 項目名 | 設定値 |
|---|---|
| VPC | 本記事の前半で作成したVPC |
| サブネット | VPC上に存在するパブリックサブネット |
| パブリックIPの割り当て | 有効化 |
| ファイアウォール(セキュリティグループ) | セキュリティグループを作成 |
| セキュリティグループ名 | 任意の名前 |
| 説明 | 任意の説明 |
| インバウンドセキュリティグループのルール - タイプ | ssh |
| インバウンドセキュリティグループのルール - ソースタイプ | カスタム |
| インバウンドセキュリティグループのルール - ソース | com.amazonaws.<リージョン>.ec2-instance-connectに応じたプレフィックスリストのID（pl-で始まる） |
ストレージを設定
インスタンスに割り当ているストレージ（保存領域）を指定します。
gp3と記載のある箇所はストレージのタイプです。それぞれIOPSなどに違いがありますが、今回詳しい説明は割愛します。
設定の際は8GiB、gp3を使用して下さい。
なお、ストレージのタイプについて詳しくは以下のページをご確認ください。
起動してみる
これで諸々の設定は終わりです。
インスタンスを起動する前にAMIが「Amazon Linux 2023」で無料利用枠の対象と記載あるもの、インスタンスタイプが「t2.micro」、ネットワーク設定のセキュリティグループのインバウンドルールでソースが「com.amazonaws.<リージョン>.ec2-instance-connectに応じたプレフィックスリストのID（pl-で始まる）」、ストレートを設定が「1x8GiB gp3」になっていることを最低限確認してください。（予期しない課金を防ぐためです。）
問題ない場合は「インスタンスを起動」をクリックしてみましょう。
インスタンスの起動に成功すると以下のように、正常に開始しましたというメッセージと共に、緑色のハイライトが表示されます。
問題ない場合は、「すべてのインスタンスを表示」をクリックしてください。
ボタンをクリックすると、インスタンス一覧が表示されます。
なお、インスタンスが正常かどうかは「ステータスチェック」という列で緑色のチェックマークが付いているかどうかで確認できます。
これでインスタンスの起動は完了です。続いてインスタンスに接続してみましょう。
インスタンスに接続する
インスタンスに接続するには、接続したいインスタンスにチェックを入れた状態で、右上にある「接続」ボタンをクリックします。
あとはEC2 Instance Connectタブを選択した状態で、そのまま「接続」ボタンをクリックします。
※警告が表示されていますが、ネットワーク設定のセキュリティグループのインバウンドルールでソースが「com.amazonaws.<リージョン>.ec2-instance-connectに応じたプレフィックスリストのID（pl-で始まる）」に設定されてあれば問題ありません。
接続ボタンをクリックすると、インスタンスに接続ができます。
これで完了です。お疲れ様でした。
作成したリソースの掃除
AWSでは使用した分だけ課金するという従量課金のモデルが採用されています。
今回は可能な限り無料枠の範囲内、多額の料金が発生しない範囲でリソースを作成しましたが、作成したリソースをそのままにすると課金が発生します。
そのため、リソースを削除していく必要があります。
EC2 インスタンスの削除
EC2 インスタンスを削除するには、削除したいインスタンスにチェックを入れ、「インスタンスの状態」から「インスタンスを終了 (削除)」を選択します。
確認が入るので「終了 (削除)」を選択することでインスタンスを削除が行われます。これでOKです。
VPCの削除
EC2 インスタンスの削除が完了したら、続いてVPCの削除をします。
VPCダッシュボードからサイドバーの「お使いのVPC」を選択し、作成したVPCを選択します。
その後、「アクション」から「VPCの削除」を選択して確認すればOKです。
まとめ
今回は実際にVPC、EC2の構築を行ってみました。
ハードウェアなどを実際に設置することなく、画面上で設定を行っていくだけで簡単にネットワークや仮想マシンの構築ができ、欲しいと思った時にすぐに手に入ることを感じることができたら幸いです。
今回の記事は以上となります。ありがとうございました。
![[アップデート] Amazon DocumentDB のインスタンスベースクラスターが AWS Secrets Manager を使ったパスワード管理の統合をサポートしました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-d68351ceabdf61da8b5199452e233293/a147805341404e59db51dd45b7f0f380/amazon-documentdb)
![[レポート] VPC Lattice と PrivateLink を利用したクロス VPC リソースアクセス「Simplify cross-VPC resource access with PrivateLink and VPC Lattice」 #NET218](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
