目次
8 章

EC2 と VPC の基礎

クラウドで最も古いコンピューティングとネットワーク、EC2 と VPC。インスタンスタイプと AMI と EBS、そして VPC / サブネット / ルートテーブル / IGW / NAT がどう1枚の図にまとまるか — 運用インフラの最初の骨格を組みます。

1部でアカウントと IAM、コスト、CLI、セキュリティ、CloudWatch まで準備段階を終えたなら、本章からは実際に何かを動かす段階に入ります。2部は AWS 上で最もよく出会うコンポーネント — EC2、VPC、S3、RDS、Route 53、ALB、CloudFront — を運用視点で一本につなぐことが目標です。

その最初の一歩が EC2 と VPC です。クラウドで最も古く、最も基本になる道具です。EC2 は仮想コンピュータ1台であり、VPC はそのコンピュータたちが住むネットワークです。2つは常に一緒に動きます。本章で組む骨格は 第9章 EC2 運用 のセキュリティルールと接続、そして 第11章 RDS のサブネット配置へそのままつながります。

本章では EC2 インスタンス1台を立ち上げるときに裏で一緒に作られるすべての役割 — インスタンスタイプ、AMI、EBS、VPC、サブネット、ルートテーブル、IGW、NAT Gateway — を順に整理します。

全体像 #

EC2 を1台コンソールで立ち上げると、実は裏で次がすべて作られます。

EC2 インスタンス1台のフルスタック
              ┌──────────────────────────────────┐
              │              VPC                 │
              │  10.0.0.0/16                     │
              │                                  │
              │   ┌──────────────────────────┐   │
              │   │   Subnet (Public)        │   │
              │   │   10.0.1.0/24            │   │
              │   │                          │   │
              │   │     ┌────────────┐       │   │
              │   │     │ EC2 インスタンス │       │   │
              │   │     │ AMI = OS    │       │   │
              │   │     │ EBS = ディスク  │       │   │
              │   │     │ ENI = ネットワーク│       │   │
              │   │     └────────────┘       │   │
              │   └──────────┬───────────────┘   │
              │              │                   │
              │              ▼                   │
              │      Route Table                 │
              │              │                   │
              │              ▼                   │
              │      Internet Gateway (IGW)      │
              └──────────────┼───────────────────┘
                          インターネット

この図に登場する役割を順に整理します。

EC2 — 仮想コンピュータ1台 #

EC2 (Elastic Compute Cloud) は AWS の仮想マシンサービスです。コンソールで インスタンス (Instance) と呼ぶ1台を立ち上げると、それが仮想 Linux または Windows コンピュータ1台です。

インスタンスタイプ #

EC2 インスタンスタイプは、名前がそのままスペックです。

インスタンスタイプの形
t3.micro
│  │  └── サイズ (nano / micro / small / medium / large / xlarge / 2xlarge / ...)
│  └───── 世代 (1, 2, 3, 4, 5, 6, 7 ...)
└──────── ファミリー

よく使うファミリーは次のとおりです。

ファミリー別名役割
tBurstable普段は少なく使っていて急に跳ねるワークロード。開発 / サイドプロジェクトの基本
mGeneral purposeCPU / メモリのバランス。一般的な Web サーバー
cCompute optimizedCPU 比重の高い作業 (エンコード、ビルドサーバー)
rMemory optimizedメモリが大きい作業 (Redis、大きなキャッシュ)
i, dStorage optimizedローカル NVMe / HDD が大きい作業 (DB、データパイプライン)
g, pGPU機械学習 / グラフィック

最初はほとんど t3.micro / t3.small / t3.medium で始めます。t ファミリーは CPU クレジットモデルなので、平均使用率が低いときにコスト効率が良いです。運用に入ると m に移すのが一般的です。

t3 vs t3a vs t4g. t3 は Intel、t3a は AMD (約10%安い)、t4g は ARM (Graviton、約20%安くて速い) です。新しいワークロードは互換性を確認したうえで t4g から検討します。

AMI — OS イメージ #

AMI (Amazon Machine Image) はインスタンスを立ち上げるときに使う OS イメージです。「Ubuntu 22.04」または「Amazon Linux 2023」のような OS に、あらかじめインストールされた道具を加えたスナップショットです。

よく使う AMI の種類は次のとおりです。

  • Amazon Linux 2023 — AWS が作り維持する RHEL 系。EC2 上で最も滑らかです。
  • Ubuntu LTS — 最も馴染みのある選択。22.04 / 24.04 です。
  • Debian — Ubuntu より軽いです。
  • Windows Server — ライセンス費用が含まれます。
  • ユーザーが作った AMI — 運用中のインスタンスをスナップショットして作ります(第9章 EC2 運用)。

AMI はリージョン単位です。ソウルリージョンの AMI を東京リージョンでそのまま使うことはできません。AMI コピーコマンドで移せます。

EBS — ディスク #

EBS (Elastic Block Store) は EC2 に付くブロックストレージ、つまり仮想 SSD です。インスタンスを終了しても EBS は生き残る別リソースです。EBS がなければ EC2 は空の缶です。

ボリュームタイプは次のとおりです。

タイプ略称役割
General Purpose SSDgp3デフォルト。コストパフォーマンスが良い
General Purpose SSD (旧)gp2旧デフォルト。新しい作業は gp3
Provisioned IOPS SSDio2 / io2 Block Express高い IOPS が必要な DB
Throughput Optimized HDDst1大きなファイルの順次読み出し (ビッグデータ)
Cold HDDsc1あまり使わないバックアップ

ほとんど gp3 で始めます。gp2 より20%安く、IOPS と Throughput を別々に調整できます。

インスタンスストア (Instance Store) という別の種類もあります。インスタンスに物理的に付いた NVMe で速いですが、インスタンス終了時に消えます。キャッシュや一時用途にだけ使います。

VPC — 仮想ネットワーク #

VPC (Virtual Private Cloud) は AWS の中に作る自分だけのネットワークです。EC2 / RDS / Lambda のようなリソースが生きるプライベート IP 空間です。

CIDR ブロック #

VPC を作るとき最初に決めるのが CIDR ブロック、つまり IP アドレス範囲です。

よく使う VPC CIDR
10.0.0.0/16    # 10.0.0.0 ~ 10.0.255.255 (65,536 個)
172.16.0.0/16  # 172.16.0.0 ~ 172.16.255.255
192.168.0.0/16 # プライベート IP 領域

/16 なら 65,536 個の IP があり、/24 なら 256 個です。最初は /16 で取っておき、その中をサブネットに切って使うのが一般的です。

プライベート IP 領域だけを使います。 RFC 1918 のプライベート領域 (10.0.0.0/8172.16.0.0/12192.168.0.0/16) の中から選ばなければなりません。パブリック IP を VPC CIDR に使うと、その IP のインターネットアクセスが塞がれることがあります。

デフォルト VPC #

新しいアカウントには デフォルト VPC (Default VPC) がリージョンごとにあらかじめ作られています。CIDR 172.31.0.0/16、すべての AZ にパブリックサブネットが1つずつ、IGW も自動で接続されています。

学習やプロトタイプはデフォルト VPC で十分です。運用は新しく作ったカスタム VPC へ進むのが通例です。デフォルト VPC はすべてがインターネットに露出しているため、セキュリティ的に弱いです。VPC 設計をより深く扱うのは 第28章 VPC 深掘り です。

サブネット — VPC の中の区画 #

VPC の中をさらに分けた単位が サブネット (Subnet) です。サブネットは1つの AZ に属します。そのため Multi-AZ 運用のためには、サブネットも複数の AZ に作らなければなりません。

VPC 内のサブネット分割の例
VPC 10.0.0.0/16
├── Public Subnet A   10.0.1.0/24  (AZ a) ── ALB, NAT, Bastion
├── Public Subnet B   10.0.2.0/24  (AZ b)
├── Private Subnet A  10.0.10.0/24 (AZ a) ── EC2 (アプリ)
├── Private Subnet B  10.0.11.0/24 (AZ b)
└── Database Subnet A 10.0.20.0/24 (AZ a) ── RDS
    Database Subnet B 10.0.21.0/24 (AZ b)

サブネットの種類は自分が決めるものではなく、ルートテーブルが決めます。「パブリック」という属性が別にあるのではなく、IGW へ向かうルートがあるサブネットがそのままパブリックです。

Public vs Private サブネット #

Public サブネットPrivate サブネット
インターネット in/out直接可能NAT 経由で out のみ
パブリック IP 自動割り当てオプションを ON にすればそうなる通常 OFF
置くリソースALB, NAT GW, BastionEC2 (アプリ), Lambda
ルーティングIGW へ 0.0.0.0/0NAT GW へ 0.0.0.0/0

運用パターンは、アプリサーバーは Private に、外部公開は ALB が Public で受ける形です。アプリサーバーに直接インターネット IP が付かないので、攻撃面が減ります。

ルートテーブル — どこへ送るか #

ルートテーブル (Route Table) はサブネットのトラフィックがどこへ行くかを定義します。サブネット1つにルートテーブル1つが付きます。

Public サブネットのルートテーブル
| Destination    | Target          |
| -------------- | --------------- |
| 10.0.0.0/16    | local           |  ← VPC の中は常に local
| 0.0.0.0/0      | igw-xxxxxxxx    |  ← それ以外は IGW (インターネット)
Private サブネットのルートテーブル
| Destination    | Target          |
| -------------- | --------------- |
| 10.0.0.0/16    | local           |
| 0.0.0.0/0      | nat-xxxxxxxx    |  ← それ以外は NAT GW

local ルートは自動で追加され、消せません。同じ VPC の中のすべてのサブネットは常に互いに通信できます(ただし SG / NACL が塞ぐことはあります)。

IGW — Internet Gateway #

IGW は VPC とインターネットをつなぐ単方向ゲートウェイです。VPC ごとに1つ付けます(付けなければ完全なプライベート VPC)。

IGW 自体はトラフィックをルーティングしません。ルートテーブルに IGW を target として追加しなければトラフィックは流れません。そのため同じ IGW を使う VPC の中でも、一部のサブネットだけをパブリックにできます。

IGW は無料で、可用性も自動で管理されます。

NAT Gateway — プライベートからインターネットへ #

Private サブネットの EC2 が OS パッチを受けたり外部 API を呼び出したりするにはインターネットアクセスが必要です。しかしインターネットからその EC2 へ入ってきてはいけません。NAT (Network Address Translation) がその役割をします。

NAT Gateway のトラフィックの流れ
[Private EC2] ──out──▶ [NAT GW (Public Subnet)] ──out──▶ [IGW] ──▶ インターネット
                                                ◀ in は不可

NAT GW は Public サブネットに置きます(自分はインターネットに見える必要があり、IGW と通信します)。Private サブネットのルートテーブルが NAT GW を target として指せば、Private のトラフィックが NAT を経てインターネットへ出ます。

NAT GW vs NAT Instance #

昔は NAT を EC2 1台で直接立ち上げました(NAT Instance)。今はマネージドの NAT Gateway をほぼ常に使います。

NAT GatewayNAT Instance (旧)
管理AWS が管理自分
可用性AZ 単位で自動 (Multi-AZ は AZ ごとに置くこと)単一 EC2
帯域幅最大 100 GbpsEC2 サイズに依存
費用時間あたり + GB あたりEC2 費用のみ

NAT GW のコストの落とし穴 #

NAT Gateway は時間あたりとデータ処理 GB あたりの両方で課金されます。トラフィックが多いと意外に大きな費用になります。節約する方法は次のとおりです。

  • AZ ごとに NAT GW を置かず1つだけ置けば費用は減りますが、可用性は下がります(単一 AZ 障害時に他の AZ の Private もインターネットが切れます)。
  • S3 / DynamoDB トラフィックは Gateway VPC Endpoint で NAT を迂回します(無料)。
  • ECR / Secrets Manager のようなサービスも Interface VPC Endpoint で NAT を迂回できます(時間あたり費用はありますが、トラフィック GB 費用はありません)。

VPC Endpoint の種類と設計は 第28章 VPC 深掘り で本格的に扱います。

Security Group vs NACL — ファイアウォール #

VPC のファイアウォールは2層で動きます。詳しい設計は 第9章 EC2 運用 で扱うので、ここでは図だけ見ます。

パケットが EC2 に届くまで
インターネット ──▶ NACL (サブネット単位) ──▶ Security Group (インスタンス単位) ──▶ EC2
Security GroupNACL
適用単位インスタンス (ENI)サブネット
Stateful応答を自動許可そうでない
ルールAllow のみ (Deny なし)Allow + Deny
使用頻度毎日ほぼ触らない

運用ではほぼ SG だけを触り、NACL はデフォルト値のままにします。

EC2 を1台立ち上げる — CLI #

コンソールのクリックの代わりに CLI で1コマンドで立ち上げられます。

EC2 を立ち上げる
aws ec2 run-instances \
  --image-id ami-0f3a440bbcff3d043 \
  --instance-type t3.micro \
  --key-name my-key \
  --security-group-ids sg-0abc1234def567890 \
  --subnet-id subnet-0abc1234def567890 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=my-server}]'

コンソールで行ったすべての選択がフラグ一つ一つに対応します。CLI を一度見れば、コンソールが何を選べと尋ねていたのかが明確になります。CLI / SDK のセットアップは 第4章 AWS CLI と SDK を参照します。

よく出会う落とし穴 #

  • 「なぜ EC2 がインターネットにつながらないのか?」 — 次を順に確認します。(1) パブリック IP が付いているか(サブネットの auto-assign public IP または EIP)、(2) サブネットが Public か(ルートテーブルに 0.0.0.0/0 → igw-... があるか)、(3) SG が outbound を許可しているか、(4) NACL が outbound を許可しているか、(5) OS の中のファイアウォール(ufwiptables)が塞いでいないか。たいてい (1) または (2) で、Private サブネットなら NAT GW の経路を確認します。
  • VPC CIDR を小さく取りすぎる10.0.0.0/24 (256 IP) で始めると、後でサブネットが足りなくなります。VPC CIDR は作った後の変更が難しいです(補助 CIDR の追加は可能)。最初から /16 で余裕を持って取ります。
  • NAT Gateway の費用が請求書に大きく出る — 毎月 NAT GW だけで数十ドルなら、トラフィック量を点検します。S3 / ECR の呼び出しが多いなら VPC Endpoint で NAT を迂回します。
  • キーペア紛失 — SSH 接続のキーペアを失うと、事実上インスタンスを終了した後に再生成しなければなりません。このリスクのため、次第に SSM Session Manager(第9章 EC2 運用)へ移っていく流れです。
  • 誤った AZ に RDS を単独配置 — EC2 は AZ a に、RDS は AZ b にだけ置くと、動作はしますが AZ 間データ転送費用が発生します。同じ AZ に置くか、RDS を Multi-AZ にします。
  • EBS がインスタンスより長く生きる — インスタンス終了時に EBS が自動削除されるか(DeleteOnTermination)を確認します。旧オプションが false だと、終了したインスタンスの EBS だけが残って1か月分課金される事故がよくあります。

練習問題 #

  1. §「VPC 内のサブネット分割の例」の図を見て、自分が作るサービスの VPC CIDR (/16) を1つ決めた後、Public · Private · Database サブネットを各 AZ に2つずつ、計6つに切って IP 範囲を書いてみてください。第25章 Terraform 入門 で、この分割が aws_subnet リソースになります。
  2. 「なぜ EC2 がインターネットにつながらないのか?」の5段階のチェックリストを見ずに書いてみてください。そのうちどの段階がルートテーブルの問題で、どの段階が SG / NACL の問題かを、§「ルートテーブル」と §「Security Group vs NACL」を根拠に分類してみてください。
  3. NAT Gateway の費用を減らす3つの方法を書き、それぞれが可用性 · 無料かどうかの面でどんなトレードオフがあるかを一行ずつメモしておいてください。このメモは 第27章 コスト最適化 で再び活用します。

一行まとめ: EC2 は仮想コンピュータ1台で、インスタンスタイプがスペックを、AMI が OS を、EBS がディスクを決める。VPC はプライベート IP ネットワークで、その中のサブネットはルートテーブルが IGW を指せば Public、NAT を指せば Private になる。IGW は無料だが NAT Gateway は時間あたりと GB あたりの両方で課金されるので VPC Endpoint で迂回する。

次の章 #

本章で EC2 を1台立ち上げる図はつかめました。次の 第9章 EC2 運用 では、その EC2 を安全に扱う日常の道具へ移ります。Security Group ルールの設計、key pair の限界と SSM Session Manager への移行、AMI で骨格を固める方法まで整理します。

X