週2VPC

2026-08-08（土）VPC（ネットワークの土台）

この記事の目次
  1. このハンズオンで使うAWSサービスと役割
  2. 操作前に知っておくべき設定項目
  3. よくある詰まりポイント・注意点
  4. このハンズオンが対応する試験論点

1. 【このハンズオンで使うAWSサービスと役割】

サービス 役割
Amazon VPC (Virtual Private Cloud) [p.31] AWSクラウド上に論理的に構築する、ユーザー専用の完全に隔離された仮想プライベートネットワーク空間です [p.31]。すべてのリソース（仮想サーバーなど）を配置する絶対的なネットワークの土台となります [p.31, p.33]。
サブネット (Subnet) [p.33] VPCにアサインされたアドレス範囲（CIDR）を、用途やアベイラビリティゾーンに応じてさらに細分化したネットワークセグメント（区画）です [p.33]。
インターネットゲートウェイ (IGW) [p.37-38] VPCの内部リソースと、外部のパブリックインターネットとの間で、双方向のターゲット通信を物理的に確立・橋渡しするための出入り口（ゲートウェイ）です [p.38]。
ルートテーブル (Route Table) [p.35] 各サブネット内のパケットが、次の目的地（ゲートウェイなど）へどのようにルーティング（転送）されるかを規定する「行き先案内表」です [p.35]。
セキュリティグループ (SG) [p.36] EC2インスタンスやELBなどの「インスタンス（仮想NIC：ENI）単位」で機能する、ステートフルな仮想ファイアウォールです [p.36]。不審なインバウンド通信から直接ホストを防御します [p.36]。

2. 【操作前に知っておくべき設定項目】

  • VPCのIPv4 CIDRブロック [p.32]:
    • VPC全体のIPアドレス空間を設定します。本日は標準的なプライベートIPアドレス範囲である 10.0.0.0/16 （計65,536個のアドレス）を使用します [p.32-33]。
  • 各サブネットのCIDR範囲とアベイラビリティゾーン (AZ) [p.33-34]:
    • VPC CIDRの範囲内で重複しないようにアドレスを設定します [p.33-34]。
      • パブリックサブネット: 10.0.1.0/24 （配置：ap-northeast-1a） [p.34]
      • プライベートサブネット: 10.0.2.0/24 （配置：ap-northeast-1c） [p.34]
    • 高可用性を確保するため、それぞれ異なる物理データセンター群である「AZ-a」と「AZ-c」に物理的に分散させて配置します [p.26-27, p.34]。
  • デフォルトルートの設定パラメータ [p.35, p.38]:
    • インターネット全体（外部世界）を表す特別なネットワーク表記 0.0.0.0/0 を宛先に指定し、そのターゲット（ネクストホップ）として、作成したインターネットゲートウェイ igw-xxxxxx をマッピングします [p.38]。
  • セキュリティグループのインバウンドルール（HTTP/SSH許可） [p.36]:
    • Webアクセス用の「HTTP（ポート80）」、および疎通確認・リモートログイン用の「SSH（ポート22）」を許可するようルールを追加指定します [p.36]。

3. 【よくある詰まりポイント・注意点】

  • 詰まりポイント①：「パブリックサブネット」と「プライベートサブネット」を分ける仕組みの勘違い
    • 考え方の本質: AWSには、作成時に「パブリックサブネット」や「プライベートサブネット」という種類の異なるサービスが個別に存在するわけではありません [p.38]。
    • 解決理由: サブネットがパブリックかプライベートかを決定する唯一の境界線は、「 そのサブネットに紐付けられているルートテーブルに、宛先 0.0.0.0/0 をインターネットゲートウェイ（IGW）に向けるルートが明示的に記載されているかどうか 」 です [p.38]。本日の実習では、ルートテーブルの編集時にパブリック側にのみIGWルートを追加することで、物理的なインターネット境界を分離します [p.38]。
  • 詰まりポイント②：ルートテーブルをパブリックに設定しても、起動したEC2がインターネットと疎通できない
    • 原因: サブネット側のルーティングに加えて、そのサブネットにデプロイされたEC2インスタンス自身が 「 パブリックIPアドレス（グローバルIP） 」 を付与されていなければ、双方向のインターネット通信は成り立ちません [p.38]。
    • 対策: サブネットのプロパティ設定で「パブリック IPv4 アドレスの自動割り当ての有効化」にチェックを入れてからEC2を起動するか、起動時に明示的に自動割り当てを「有効」に指定してください。
  • 詰まりポイント③：セキュリティグループの「ステートフル（Stateful）」の特性による動作ミスの防止
    • 考え方の本質: セキュリティグループは「ステートフル」であり、一度インバウンド（入り口）を通過した通信の戻り（応答トラフィック）は、アウトバウンドルールを一切設定していなくても自動的に通過が許可されます [p.36]。
    • 対策: インバウンドルールに「ポート80からすべてのアクセス（0.0.0.0/0）を許可」と記述しておけば、アウトバウンドルールをすべて削除してしまっても、Webサーバーの応答パケットは自動で外に返っていきます。これに対し、後日の学習で登場する「ネットワークACL」はステートレスであるため、行きと戻りの双方のルール追加が必須となります [p.36]。

4. 【このハンズオンが対応する試験論点】

  • 試験論点①：「1つのサブネットは、複数のAZをまたぐことはできない」という絶対原則

    • 試験（SAA-C03）では高可用（マルチAZ）設計が最重要テーマです [p.27, p.34]。しかし、物理的な仕様として 「 1つのサブネットは1つのAZ（単一のデータセンター群）にしか作成できない 」 という制約があります [p.33]。
    • このため、可用性を高めるためには、必ず 「 異なる2つ以上のAZそれぞれに、別々のサブネットをペアで作成し（例：サブネットA in AZ-a、サブネットB in AZ-c）、そこに同一リソースを並列デプロイする 」 というマルチAZマッピングが絶対に必須となる理由を実感できます [p.34]。

  • 試験論点②：ネットワークセキュリティ境界と「プライベートサブネット隔離」の原則

    • インターネット側からの直接の標的型ハッキングや不正侵入を物理的に100%遮断するため、データベース（RDS等）や基幹バックエンドサーバーは、「インターネットゲートウェイへのルートを持たないプライベートサブネット」にのみ配置するのがAWS設計の絶対的な鉄則です [p.38]。
    • 本日のサブネット論理分離ハンズオンを通じて、パブリックサブネットにのみALB（ロードバランサー）や踏み台ホストを配置し、安全にプライベートサブネット内のデータベースを保護する多層防御設計の「なぜ」を深く理解できます [p.36, p.38]。

⚙️ 5分間の確認が完了しました。それでは、いよいよAWS上でインフラ構築のすべての基礎となる「Amazon VPCネットワーク」の構築実習に入りましょう！