VPC を手作業で組み立てて、ウィザードと比べてみた

はじめに

こんにちは、クラスメソッドオペレーションズ株式会社 26新卒の村上です。

AWS の学習を進める中で、Amazon VPC を作る機会がありました。マネジメントコンソールには「VPC など」というウィザードがあり、これを選ぶと必要なリソースが一度にできあがります。とても便利なのですが、作り終えたあとに「結局、何が作られたんだろう」と分からないままになってしまいました。

そこで今回は、ウィザードを使わずに手作業で最小構成を組み立て、EC2 インスタンスに接続できるところまでやってみました。そのうえで、同じものをウィザードでも作って両者を比べてみます。

比べてみると、ウィザードが自動で設定してくれる項目と、利用者が個別に設定する項目が見えてきました。予想と違っていた点もあり、勉強になりました。

想定読者

• ウィザードで作成される VPC の構成要素を確認したい方
• AWS を触り始めたばかりの方

検証環境

本検証では、EC2 インスタンスの稼働料金のほかに、ルート EBS ボリュームとパブリック IPv4 アドレスも課金対象になります。実際の料金は利用時間や無料利用枠の適用状況によって変わるため、検証後は請求とコスト管理の画面で確認することをおすすめします。

事前準備：Session Manager で接続できるようにする

VPC を作る前に、EC2 インスタンスへの接続方法を用意しておきます。

今回は SSH を使わず、AWS Systems Manager Session Manager で接続します。SSH キーペアを作る必要がなく、セキュリティグループのインバウンドを開ける必要もないためです。

その準備として、Systems Manager の「デフォルトのホスト管理設定」が有効になっていることを確認します。この設定を有効にすると、EC2 インスタンスごとに IAM インスタンスプロファイルを用意しなくても、Systems Manager の管理対象として登録できます。

ただし、公式ドキュメントによると、対象のインスタンスが IMDSv2 を使用していることや、SSM Agent 3.2.582.0 以降がインストールされていることが前提とのことでした。今回は Amazon Linux 2023 を使い、起動後にマネージドノードとして登録されたことを確認してから接続しています。

デフォルトのホスト管理設定が有効になっていることを確認する

手作業で組み立てる

ここからは、ウィザードを使わずに一つずつ作っていきます。

1. VPC を作る

VPC コンソールの「お使いの VPC」から「VPC を作成」を開きます。

ここで重要なのが、「作成するリソース」で「VPC のみ」を選ぶことです。もう一方の「VPC など」がウィザードで、これを選ぶとサブネットやインターネットゲートウェイまで一括で作られてしまいます。今回は一つずつ手で作りたいので「VPC のみ」を選びます。

「作成するリソース」で「VPC のみ」を選ぶ

IPv4 CIDR ブロックには 10.0.0.0/16 を指定しました。これは「この VPC の中で使える IP アドレスの範囲」を決めるものです。

作成が完了したら、VPC の「リソースマップ」タブを開いてみます。

作成直後のリソースマップ。サブネットもインターネットゲートウェイもまだ無い

サブネットもインターネットゲートウェイもありません。

ただし、何も無いわけではありませんでした。公式ドキュメントによると、VPC を作成するとメインルートテーブル・デフォルトのネットワーク ACL・デフォルトのセキュリティグループ・DHCP オプションセットが自動的に付属するとのことです。つまりここは「サブネットも、インターネットへの経路もまだ無い」状態、と表現するのが正確でした。

2. 作成直後のルートテーブルを見てみる

ここで一度、ルートテーブルを覗いてみます。VPC を作ると、ルートテーブルが1つ自動的に作られます。

10.0.0.0/16 → local の1行しかない

登録されているルートは 10.0.0.0/16 → local の1行だけです。

これは「10.0.0.0/16 宛ての通信は VPC の中で処理する」という意味で、VPC 内部の通信のためのルートです。逆に言えば、この時点では VPC の外に出るための経路が1つも無いことになります。

この話は後半でもう一度出てきます。

3. サブネットを作る

次にサブネットを作ります。VPC で確保した 10.0.0.0/16 の中を区切って、実際にリソースを配置する区画を作る作業です。

10.0.0.0/16 の中に 10.0.1.0/24 を切り出す

アベイラビリティーゾーンは ap-northeast-1a、CIDR は 10.0.1.0/24 を指定しました。サブネットは必ず1つのアベイラビリティーゾーンに属します。

4. インターネットゲートウェイを作ってアタッチする

VPC の外と通信するために、インターネットゲートウェイ（IGW）を作ります。

ここで注意したのが、作っただけでは VPC と繋がらないという点です。作成後に「アクション」→「VPC にアタッチ」を実行して、はじめて VPC と紐づきます。

作成したあと、VPC にアタッチする

5. ルートテーブルにルートを追加する

インターネットゲートウェイをアタッチしましたが、これだけではまだ外に出られません。「外に出たいときは、このゲートウェイを通る」という経路をルートテーブルに書く必要があります。

先ほど local の1行しか無かったルートテーブルに、ルートを追加します。

0.0.0.0/0 の宛先をインターネットゲートウェイに向ける

0.0.0.0/0 は「すべての IPv4 アドレス」を表します。

それなら VPC 内部宛ての通信までインターネットゲートウェイに送られてしまうのでは、と思ったのですが、そうはなりませんでした。ルートテーブルではより具体的なルートが優先される（最長プレフィックス一致）ためです。10.0.0.0/16 宛ての通信には local が選ばれ、それ以外の通信に 0.0.0.0/0 → インターネットゲートウェイ が選ばれます。

6. ルートテーブルとサブネットを関連付ける

ルートテーブルは、どのサブネットに適用するかを指定します。

作成したサブネットを関連付ける

この画面をよく見ると、関連付ける前から、サブネットのルートテーブル ID の欄に「メイン」と表示されていました。

VPC を作ったときに自動で作られるルートテーブルは「メインルートテーブル」と呼ばれます。公式ドキュメントには「それ以外の場合、サブネットはメインルートテーブルに暗黙的に関連付けられます」と書かれていました。

つまり今回の構成では、この関連付けの操作をしなくても通信経路は変わりませんでした。とはいえ、どのサブネットにどのルートテーブルが効いているのかを自分の目で確認できたので、やってみてよかったと思っています。

この点は、後半のウィザードとの比較でもう一度出てきます。

7. パブリック IP の自動割り当てを有効にする

サブネットの設定で「パブリック IPv4 アドレスの自動割り当て」を有効にします。

パブリック IPv4 アドレスの自動割り当てを有効にする

8. EC2 インスタンスを起動する

ここまでで受け皿ができたので、EC2 インスタンスを起動します。

作成した VPC とサブネットを指定する

キーペアは「キーペアなしで続行」を選びました。Session Manager で接続するため、SSH でのログインを使わないからです。

そしてセキュリティグループですが、インバウンドルールを1つも作りませんでした。既定で入っている SSH のルールも削除しています。

インバウンドルールはゼロ件のまま起動する

なお、アウトバウンドは EC2 の起動画面では設定できません。新規にセキュリティグループを作ると、自動的に「すべて許可」で作成されます。

アウトバウンドはすべて許可になっている

インスタンスから外へ出ていく通信は、特に何もしなくても許可されている状態でした。

ただし、アウトバウンドが許可されているだけでは Systems Manager につながりません。調べてみると、今回接続できたのは次の条件がそろっていたからのようです。

• SSM Agent が動作している
• セキュリティグループのアウトバウンドで HTTPS（TCP 443）が許可されている
• ルートテーブルに 0.0.0.0/0 → インターネットゲートウェイ がある
• インスタンスにパブリック IPv4 アドレスが割り当てられている
• DNS 名前解決ができる
• SSM Agent が Systems Manager と通信するための認証情報を取得できる

ここまでの手順で作ってきたものが、そのまま接続の条件になっていたことになります。

最後の認証情報については、今回は EC2 インスタンスに IAM インスタンスプロファイルをアタッチせず、事前準備で確認したデフォルトのホスト管理設定の仕組みを使っています。

なお、通信面では Systems Manager のエンドポイントへ到達できる必要があります。今回はセキュリティグループのアウトバウンドがすべて許可で、インターネットゲートウェイへの経路とパブリック IPv4 アドレスもあったため、条件を満たしていたことになります。

9. Session Manager で接続する

インスタンスのステータスチェックが完了したら、パブリック IPv4 アドレスが割り当てられていることを確認します。

パブリック IPv4 アドレスが割り当てられている

「接続」ボタンから「セッションマネージャー」タブを開き、接続します。

セッションマネージャータブから接続する

ブラウザの新しいタブでターミナルが開きます。外部への通信ができるか確認してみます。

curl -I https://aws.amazon.com

HTTP/2 200 が返ってきた

HTTP/2 200 が返ってきました。VPC の中から外に出られています。

セキュリティグループのインバウンドを1つも開けていないのに、EC2 インスタンスに入って作業ができました。ここまでが手作業パートです。

ウィザードで同じものを作ってみる

ここからが本題です。同じような構成を「VPC など」（ウィザード）でも作ってみます。

CIDR は手作業版と区別するため 10.1.0.0/16 にし、アベイラビリティーゾーン1つ・パブリックサブネット1つ・NAT ゲートウェイなし、という設定にしました。

名前と CIDR を入力する

サブネットの数と NAT ゲートウェイ、DNS オプションを選ぶ

この画面で目を引くのが、右側に表示される作成予定リソースのプレビューです。ここまで手作業で1つずつ作ってきたものが、まとめて並んでいます。

作成予定のリソースが一覧で表示される

ルートテーブルとネットワーク接続も作られる

作成後のリソースマップも見てみます。

VPC・サブネット・ルートテーブル・インターネットゲートウェイが揃っている

見た目には、手作業で作ったものと同じ構成ができあがっています。名前も -vpc -subnet-public1-ap-northeast-1a -rtb-public -igw と自動で付けられていました。

ここで1つ気づいたことがあります。作成前のプレビューでは、ルートテーブルは1つと表示されていました。ところが作成後のリソースマップを見ると、2つになっています。

プレビューに表示されるのはウィザードが明示的に作るリソースだけで、VPC を作れば必ず一緒にできるメインルートテーブルは数に入っていないようでした。この2つ目のルートテーブルが、次に説明する違いに関わってきます。

しかし、細かく見ていくと違いがありました。

比べて分かったこと

違い1：DNS ホスト名が有効になっていた

ウィザードの設定画面には「DNS オプション」という欄があり、「DNS ホスト名を有効化」「DNS 解決を有効化」の両方に既定でチェックが入っています。

一方、「VPC のみ」で作ったときには、この選択肢自体がありませんでした。

そこで、両方の VPC の「詳細」タブを見比べてみました。

手作業で作った VPC は DNS ホスト名が「無効」

ウィザードで作った VPC は DNS ホスト名が「有効」

DNS ホスト名の設定が違っていました。

調べてみると、デフォルト VPC 以外では DNS ホスト名が既定で無効、DNS 解決が既定で有効とのことでした。

そして、パブリック DNS 名（ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com のような名前）が割り当てられるには、DNS ホスト名と DNS 解決の両方が有効である必要があります。今回手作業で作った VPC は DNS 解決だけが有効だったので、DNS ホスト名を有効にすれば両方そろう、という状態でした。

つまりウィザードは、私が設定画面すら見ていない項目を、裏で有効にしてくれていたようです。

違い2：ルートテーブルを新しく作っていた

手作業のとき、私は VPC 作成時に自動でできたメインルートテーブルに 0.0.0.0/0 のルートを追加しました。

一方、ウィザードで作った VPC を見ると、ルートテーブルが2つありました。先ほどプレビューとリソースマップで数が食い違っていたのは、これが理由です。

「メイン」が「いいえ」になっており、サブネットが明示的に関連付けられている

• メインルートテーブル（VPC 作成時に自動でできるもの。名前は付いていない）
• -rtb-public という名前の新しいルートテーブル

そして 0.0.0.0/0 → インターネットゲートウェイ のルートは、新しく作った方に入っていました。「メイン」の欄は「いいえ」になっており、サブネットが明示的に関連付けられています。

先ほど書いたとおり、メインルートテーブルは、明示的に関連付けられていないサブネットにも適用されます。ということは、ここにインターネット向けのルートを入れておくと、あとから別のサブネットを作ったときにも、そのルートが効いてくることになりそうです。

一方ウィザードは、メインルートテーブルには手を加えず、専用のルートテーブルを作っていました。初心者の自分には、こちらの方が、どのサブネットにどのルートが効いているのか分かりやすいと感じました。

自分のやり方でも通信自体はできましたが、ウィザードの作り方の方が丁寧だな、と思った部分です。

違い3：「パブリックサブネット」なのにパブリック IP は自動割り当てされない

これが一番意外でした。

私は、ウィザードで作られるサブネットは「パブリックサブネット」と呼ばれているのだから、手作業のときに自分で有効にした「パブリック IPv4 アドレスの自動割り当て」も、当然オンになっているだろうと予想していました。

ところが、実際に見てみると違いました。

「パブリック IPv4 アドレスを自動割り当て」は「いいえ」だった

「パブリック IPv4 アドレスを自動割り当て」は「いいえ」でした。

つまり、このサブネットに EC2 インスタンスを起動しても、起動時に明示的に指定しない限り、パブリック IP は付きません。

ここで、そもそも「パブリックサブネット」とは何かを調べ直すことになりました。公式ドキュメントによると、パブリックサブネットとはルートテーブルにインターネットゲートウェイへのルートがあるサブネットを指すようです。そこに置いたリソースにパブリック IP を割り当てるかどうかは、また別の設定でした。

「パブリックサブネットに置けば自動的にインターネットから見える」と思い込んでいたので、ここは認識を改める必要がありました。

なお、サブネットの CIDR は 10.1.0.0/20 が割り当てられていました。今回はウィザードの自動選択をそのまま使ったためです。ウィザードでも、サブネットの CIDR やアベイラビリティーゾーンはカスタマイズできます。

手作業とウィザードの対応表

最後に、手作業でやったことをウィザードと並べてみます。

私が手作業で実施したのは、VPC・サブネット・インターネットゲートウェイ・ルートテーブルの設定と、パブリック IPv4 アドレスの自動割り当てでした。それがウィザードでは1つの画面に畳まれていたことになります。

一方、DNS ホスト名の有効化は実施していません。手作業では設定画面すら出てこなかったため、存在を知らないまま進めていました。

一方で、ウィザードの対象外となる設定もあります。

• パブリック IP の自動割り当て
• EC2 インスタンスの作成
• 通信を許可するためのセキュリティグループの設定

ウィザードが作成するのは「ネットワークの土台」までで、その上に配置するリソースや通信の設定は、用途に応じて個別に構成する形でした。

リソースの削除

検証が終わったので削除します。今回の構成をマネジメントコンソールから削除する場合、事前に個別に消す必要があったのは EC2 インスタンスだけでした。そのあと VPC を削除すると、サブネット・ルートテーブル・インターネットゲートウェイ・ネットワーク ACL・セキュリティグループなどもまとめて削除されます。

ただし、NAT ゲートウェイやロードバランサー、インターフェイス型 VPC エンドポイントなどを作成している場合は、それらを先に削除する必要があります。

削除の順番は次の通りです。

1. EC2 インスタンスを終了する（Terminated になるまで待つ）
2. VPC を削除する（手作業版とウィザード版の2つ）

EC2 インスタンスはサブネットの中にあり、ネットワークインターフェイスを通じて VPC に繋がっています。そのためインスタンスが生きているうちは VPC を削除できません。内側から外側へ消していく形になります。

なお、デフォルトのホスト管理設定は VPC に属する設定ではないため、VPC を削除しても元には戻りません。検証のために自分で有効化した場合は、必要に応じて元の状態に戻してください。今回はもともと有効だったため、変更していません。

削除後は、mmurakami-test- で始まるリソースが残っていないかコンソールで確認しました。あわせて、EC2 の「ボリューム」に Available 状態のボリュームが残っていないかも見ています。接続されていない状態でも課金対象になるためです。

まとめ

ウィザードを使わずに手作業で VPC を組み立て、ウィザードと比べてみました。分かったことをまとめます。

• VPC を作った直後のルートテーブルには local のルートしかなく、外に出る経路は自分で用意する必要がある
• インターネットゲートウェイは、作成とアタッチが別の操作である
• パブリック IP の自動割り当ては、EC2 インスタンスの起動時にのみ参照される
• ウィザードは、DNS ホスト名を裏で有効にしてくれていた
• ウィザードは、メインルートテーブルには手を加えず、専用のルートテーブルを作っていた
• 「パブリックサブネット」とはルートテーブルにインターネットゲートウェイへのルートがあるサブネットのことで、パブリック IP が自動で付くという意味ではない
• Session Manager を使えば、セキュリティグループのインバウンドを1つも開けずに EC2 インスタンスへ接続できる

ウィザードは便利ですが、中で何が起きているかを一度自分の手でなぞってみると、リソース同士のつながりが見えてきました。特に「パブリックサブネット」の意味を勘違いしていたことに気づけたのは、手作業と比べたからこそでした。

次は、プライベートサブネットを足した構成にも挑戦してみたいです。

この記事が、同じところでつまずいている方の参考になれば嬉しいです。

参考リンク

• Amazon VPC とは - Amazon Virtual Private Cloud
• VPC のルートテーブル - Amazon Virtual Private Cloud
• VPC の DNS 属性の表示と更新 - Amazon Virtual Private Cloud
• インターネットゲートウェイを使用してインターネットに接続する - Amazon Virtual Private Cloud
• パブリック IPv4 アドレス - Amazon Virtual Private Cloud
• AWS Systems Manager Session Manager - AWS Systems Manager
• Systems Manager のデフォルトのホスト管理設定 - AWS Systems Manager

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました