「VPCを作ってEC2を立てることはできた。でも、これだけで実務と言えるのだろうか？」
そう感じ始めているあなたへ。
クラウドの世界でも、オンプレミス同様に守るべき場所と見せる場所を厳格に分けることが、プロのインフラエンジニアへの第一歩です。
かつて私がデータセンターで物理ケーブルを色分けし、物理的なセグメントを分けていたあの感覚を、AWSでは「ルートテーブル」や「NATゲートウェイ」という論理設定で実現します。
この記事では、外部から隔離された安全地帯を作る方法から、そこから安全に外の世界へアクセスする高度なテクニックまでを、初心者にも分かりやすい「ズームイン方式」の図解とともに解説します。
「VPCなど」のウィザード機能を使って一括構築
AWSのアップデートにより、今では「VPCなど」というウィザードを選択するだけで、複雑なネットワークリソースを紐付けた状態で一括作成できるようになりました。しかし、ただボタンを押すだけでは「実務レベル」とは言えません。
まず、名前タグにプロジェクト名を入力し、IPv4 CIDR ブロックを確認します。
ここでのポイントは、画面右側の「プレビュー」を常に意識することです。設定を変更するたびにリソースの繋がりが視覚化されるため、インフラの完成図を脳内に描きながら進めることができます。
次にサブネットの設定ですが、
今回は高可用性（マルチAZ）とセキュリティを両立させるため、以下で設定します。
- アベイラビリティゾーン（AZ）：2
- パブリックサブネット：2
- プライベートサブネット：2
サブネット CIDR ブロックをカスタマイズを開き、手動で値を書き換えます。
- パブリック：10.0.1.0/24 / 10.0.2.0/24
- プライベート：10.0.10.0/24 / 10.0.20.0/24
「NAT ゲートウェイ」を「1 AZ 内（Zonal）」で有効にし、「VPC エンドポイント」を「S3 ゲートウェイ」に設定します。プレビュー画面を確認し、プライベートサブネットからNAT GWやS3へと線が伸びていれば準備完了です。
「VPCを作成」をクリックすれば実務の標準に近い強固なインフラ基盤が完成します。
外部からの侵入を物理的に遮断するプライベートサブネット
一括構築で作成されたサブネットのうち、末尾に「private」と付いたものが今回の主役です。なぜ、これらが「プライベート」と呼ばれるのか、その本質を紐解いていきましょう。
オンプレミスでのセグメント分けの概念をクラウドの論理構成にそのまま持ち込む
オンプレミスでは、重要なサーバーを保護するために物理的な隔離を行ってきました。
外部セグメントと内部セグメントでLANケーブルの色を変えたり、物理的なスイッチを分けたりして、パケットが物理的に届かない「手触り感のあるセキュリティ」を作っていたはずです。
AWSにおいても、その考え方は全く同じです。ただ、ケーブルを引き抜く代わりに、サブネットという論理的な枠組みを使って、外部からの直接的なアクセスを遮断します。
「インターネットに公開する必要がないものは、最初から道を作らない」という設計思想は、クラウド時代でも変わらぬ鉄則です。
インターネットゲートウェイへの経路をルートテーブルから外してサブネットを完全に独立させる
では、具体的に何がサブネットを「プライベート」にしているのでしょうか？
その答えは「ルートテーブル」にあります。
パブリックサブネットのルートテーブルには、宛先 0.0.0.0/0（すべての通信）に対してインターネットゲートウェイ（IGW）が設定されています。一方で、プライベートサブネットのルートテーブルには、このIGWへの出口が存在しません。
物理的にLANケーブルが繋がっていないのと同じ状態を、ルートテーブルの設定一つで作り出しているのです。この「出口がない」という事実こそが、外部からの不正アクセスを物理的に不可能にする最強の防御壁となります。
隔離状態を維持しながら外部へパッチを拾いに行くNATゲートウェイ
プライベートサブネットで「鉄壁の守り」を固めたのは良いですが、一つ大きな問題に直面します。それは、サーバー自身が外の世界に全くアクセスできなくなることです。
プライベートサブネット内のサーバーが外部と通信できずアップデートに困る状況を解決する
オンプレミスでも、インターネットから遮断されたセグメントにあるサーバーは、OSのパッチ当てや最新ソフトのインストール（yumやaptなど）ができず、運用で苦労することがありました。
安全のために閉じ込めたいが、メンテナンスのために通信はしたいという矛盾。このジレンマを解決するのが、NATゲートウェイという「一方通行の出口」です。
パブリックサブネットに配置されたNATゲートウェイが一方通行の通信を実現する
NATゲートウェイは、必ずパブリックサブネットに配置します。
ここが混乱しやすいポイントですが、外の世界（インターネット）と通信するためには、NAT自身が「公道」に出ている必要があるからです。
仕組みはシンプルです。プライベートサブネット内のサーバーが「外の情報を取ってきて」とリクエストを投げると、パブリック側にいるNATゲートウェイが代わりにインターネットへ繋ぎ、結果を持ち帰ってくれます。
しかし、外から直接このNATゲートウェイを通ってサーバーに侵入することはできません。 この「中からは出られるが、外からは入れない」という一方通行の特性が、隔離状態を維持したままの安全な運用を可能にします。
NATゲートウェイは時間課金が発生するため検証終了後に即削除する
これこそが現場のリアルとも言えます。
NATゲートウェイは、AWSのリソースの中でも維持費が高い部類に入ります（1時間あたり約$0.062 ＋ データ処理料金）。
「作成したまま1ヶ月放置してしまった……」となると、個人環境では数千円の痛い出費になります。実務では常時稼働が当たり前ですが、検証環境では「使い終わったら即削除」が鉄則です。
セキュリティグループとネットワークACLの二重の壁
AWSのネットワークセキュリティは、性格の異なる2つのガードマンによって守られています。この「二重の壁」の仕組みを正しく理解することが、堅牢なインフラを構築する鍵となります。
インスタンス単位の通信をステートフルに制御するセキュリティグループ
セキュリティグループ（SG）は、EC2インスタンスのすぐ隣に立つ「気の利くガードマン」です。最大の特徴は、ステートフルであること。
オンプレミスのファイアウォール設定で苦労した戻りの通信（アウトバウンド）をわざわざ許可する必要はありません。
SGは「一度通した相手なら、帰り道も自動的に通してくれる」というスマートな挙動をします。基本のアクセス制御は、このSGで行うのがAWS運用のセオリーです。
サブネット全体の検問所として機能するネットワークACL
一方、ネットワークACL（NACL）は、サブネットの境界線に立つ厳格な検問所です。こちらはステートレス、つまり「行き」を許可しても「帰り」を自動では通してくれません。
「行き」の許可ルールを書いたら、必ずペアで「帰り」の許可ルールも書かなければ通信が成立しないのです。
この手間があるため、NACLは日常的な運用には向きませんが、サブネット全体に対して特定のIPを完全に拒絶（ブラックリスト）したい時など、最後の手法として強力な威力を発揮します。
ネットワークACLの特性をオンプレFWと比較した考え方
オンプレミスのルーターやレイヤー3スイッチで設定していたACL（アクセスコントロールリスト）の感覚に最も近いのが、このネットワークACLです。
物理環境では一度設定したらあまり変えない、ネットワークの入り口での一括制御が一般的でしたが、AWSではSGが非常に優秀なため、NACLはデフォルトですべて許可の状態にしておく構成も少なくありません。
オンプレミスの入り口でガチガチに固めるという常識を一度捨てて、インスタンスごとに細かく守るというクラウドの作法に頭を切り替えるのが、VPCマスターへの近道です。
インターネットを介さずにAWSサービスへ直結するVPCエンドポイント
VPCの保護を極めると、AWSサービス同士の通信ですら、インターネットという公道に出したくないという境地に達します。これを実現するのが、VPC内からAWSサービスへ直接つなぐ「専用通路」であるVPCエンドポイントです。
S3やDynamoDBへのアクセスに外部ネットワークを通さない裏道
プライベートサブネットからS3などのサービスを利用する際、通常はNATゲートウェイを経由してインターネット経由でアクセスします。しかし、VPCエンドポイント（ゲートウェイ型）を使えば、VPCの外に出ることなく直接サービスへアクセス可能です。
例えるなら、一度ビルの外に出て公道を通り、隣にある倉庫（S3）へ行くのではなく、ビルの廊下から直接倉庫へと続く地下通路を作るようなものです。
外部ネットワークを一切通らないため、セキュリティが向上するのはもちろん、NATゲートウェイのデータ処理料金を節約できるという実務上の大きなメリットがあります。
ゲートウェイ型とインターフェース型の違い
VPCエンドポイントには、大きく分けて「ゲートウェイ型」と「インターフェース型」の2種類が存在します。
- ゲートウェイ型： S3とDynamoDBのみで利用可能。利用料金は無料で、ルートテーブルに「裏道の行き先（プレフィックスリスト）」を書き込む方式です。
- インターフェース型： その他の多くのサービス（EC2 API、SSM、Kinesisなど）で使用できます。こちらは時間単位の利用料金が発生し、サブネット内に専用の入り口（ENI）を作る方式です。
ここでも「コスト意識」が重要です。
S3へのアクセスであれば無料のゲートウェイ型を選択するのが定石ですが、その他のサービスをプライベート環境から使いたい場合は、料金を考慮した設計が求められます。
何でもエンドポイントを作るのではなく、セキュリティ要件と予算のバランスを見極めるのが、プロのインフラエンジニアの仕事です。
まとめ
今回学んだのは、単なる操作手順ではなく、守るための論理設計です。
- プライベートサブネット： ルートテーブルからIGWを外し、物理的な隔離を再現する。
- NATゲートウェイ： 「中からは出られるが外からは入れない」一方通行の安全を作る。
- 二重の壁： ステートフルなSGとステートレスなNACLで、インフラの守りを盤石にする。
- VPCエンドポイント： インターネットを通らない「専用の裏道」でセキュリティを極める。
大切なのは「なぜこの設定が必要か」を自分の言葉で論理的に語れることです。その理解こそが、エンジニアとしての確固たる自信と市場価値に直結します。
