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台コンソールで立ち上げると、実は裏で次がすべて作られます。
┌──────────────────────────────────┐
│ 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 ...)
└──────── ファミリーよく使うファミリーは次のとおりです。
| ファミリー | 別名 | 役割 |
|---|---|---|
t | Burstable | 普段は少なく使っていて急に跳ねるワークロード。開発 / サイドプロジェクトの基本 |
m | General purpose | CPU / メモリのバランス。一般的な Web サーバー |
c | Compute optimized | CPU 比重の高い作業 (エンコード、ビルドサーバー) |
r | Memory optimized | メモリが大きい作業 (Redis、大きなキャッシュ) |
i, d | Storage optimized | ローカル NVMe / HDD が大きい作業 (DB、データパイプライン) |
g, p | GPU | 機械学習 / グラフィック |
最初はほとんど 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 SSD | gp3 | デフォルト。コストパフォーマンスが良い |
| General Purpose SSD (旧) | gp2 | 旧デフォルト。新しい作業は gp3 |
| Provisioned IOPS SSD | io2 / io2 Block Express | 高い IOPS が必要な DB |
| Throughput Optimized HDD | st1 | 大きなファイルの順次読み出し (ビッグデータ) |
| Cold HDD | sc1 | あまり使わないバックアップ |
ほとんど gp3 で始めます。gp2 より20%安く、IOPS と Throughput を別々に調整できます。
インスタンスストア (Instance Store) という別の種類もあります。インスタンスに物理的に付いた NVMe で速いですが、インスタンス終了時に消えます。キャッシュや一時用途にだけ使います。
VPC — 仮想ネットワーク #
VPC (Virtual Private Cloud) は AWS の中に作る自分だけのネットワークです。EC2 / RDS / Lambda のようなリソースが生きるプライベート IP 空間です。
CIDR ブロック #
VPC を作るとき最初に決めるのが CIDR ブロック、つまり IP アドレス範囲です。
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/8、172.16.0.0/12、192.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 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, Bastion | EC2 (アプリ), Lambda |
| ルーティング | IGW へ 0.0.0.0/0 | NAT GW へ 0.0.0.0/0 |
運用パターンは、アプリサーバーは Private に、外部公開は ALB が Public で受ける形です。アプリサーバーに直接インターネット IP が付かないので、攻撃面が減ります。
ルートテーブル — どこへ送るか #
ルートテーブル (Route Table) はサブネットのトラフィックがどこへ行くかを定義します。サブネット1つにルートテーブル1つが付きます。
| Destination | Target |
| -------------- | --------------- |
| 10.0.0.0/16 | local | ← VPC の中は常に local
| 0.0.0.0/0 | igw-xxxxxxxx | ← それ以外は IGW (インターネット)| Destination | Target |
| -------------- | --------------- |
| 10.0.0.0/16 | local |
| 0.0.0.0/0 | nat-xxxxxxxx | ← それ以外は NAT GWlocal ルートは自動で追加され、消せません。同じ 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) がその役割をします。
[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 Gateway | NAT Instance (旧) | |
|---|---|---|
| 管理 | AWS が管理 | 自分 |
| 可用性 | AZ 単位で自動 (Multi-AZ は AZ ごとに置くこと) | 単一 EC2 |
| 帯域幅 | 最大 100 Gbps | EC2 サイズに依存 |
| 費用 | 時間あたり + 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 運用 で扱うので、ここでは図だけ見ます。
インターネット ──▶ NACL (サブネット単位) ──▶ Security Group (インスタンス単位) ──▶ EC2| Security Group | NACL | |
|---|---|---|
| 適用単位 | インスタンス (ENI) | サブネット |
| Stateful | 応答を自動許可 | そうでない |
| ルール | Allow のみ (Deny なし) | Allow + Deny |
| 使用頻度 | 毎日 | ほぼ触らない |
運用ではほぼ SG だけを触り、NACL はデフォルト値のままにします。
EC2 を1台立ち上げる — CLI #
コンソールのクリックの代わりに CLI で1コマンドで立ち上げられます。
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 の中のファイアウォール(ufw、iptables)が塞いでいないか。たいてい (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か月分課金される事故がよくあります。
練習問題 #
- §「VPC 内のサブネット分割の例」の図を見て、自分が作るサービスの VPC CIDR (
/16) を1つ決めた後、Public · Private · Database サブネットを各 AZ に2つずつ、計6つに切って IP 範囲を書いてみてください。第25章 Terraform 入門 で、この分割がaws_subnetリソースになります。 - 「なぜ EC2 がインターネットにつながらないのか?」の5段階のチェックリストを見ずに書いてみてください。そのうちどの段階がルートテーブルの問題で、どの段階が SG / NACL の問題かを、§「ルートテーブル」と §「Security Group vs NACL」を根拠に分類してみてください。
- 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 で骨格を固める方法まで整理します。