AWS中級 #1 EC2とVPCの基礎
基礎 7 編 でアカウント / リージョン / IAM / 費用 / CLI / セキュリティ / CloudWatch という 準備段階 が片付いたなら、いよいよ 実際に何かを立ち上げる段階 に入っていきます。中級 7 編は AWS の上で最もよく出会うコンポーネントたち — EC2、VPC、S3、RDS、Route 53、ALB、CloudFront — を運用視点で一本の線に通すのが目的です。
その最初のポジションが EC2 と VPC。クラウドで最も古く、最も基本となる道具です。EC2 は「仮想コンピュータ 1 台」のポジション、VPC は「そのコンピュータたちが住むネットワーク」のポジション — 二つは常にセットで動きます。
全体像 #
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 — 運用中インスタンスをスナップショットして作成 (#2)
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 の中の区画 #
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 自動割り当て | オプションで有効に | 通常は無効 |
| 主な用途 | 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 サブネットに置きます (NAT 自身がインターネットに見えなければ 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 単価なし)
Security Group vs NACL — ファイアウォール #
VPC のファイアウォールは 2 層 で動きます。詳しくは #2 EC2 運用 で扱うので、ここでは絵だけ:
インターネット ──▶ NACL (サブネット単位) ──▶ Security Group (インスタンス単位) ──▶ EC2| Security Group | NACL | |
|---|---|---|
| 適用単位 | インスタンス (ENI) | サブネット |
| Stateful | ✅ (応答自動許可) | ❌ |
| ルール | Allow のみ (Deny なし) | Allow + Deny |
| 触る頻度 | 毎日 | ほぼ触らない |
運用ではほぼ SG だけ触り、NACL はデフォルトのままにします。
EC2 を 1 台立ち上げる — aws 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}]'コンソールで行ったすべての選択が フラグの 1 つひとつに対応 します。CLI を一度眺めると「コンソールが何を選ぶよう尋ねていたのか」がはっきりしてきます。CLI / SDK のセットアップは 基礎 #4 を参照。
よくハマる罠 #
1) 「なぜ EC2 のインターネットが繋がらないの?」 #
チェックリスト:
- パブリック IP が付いているか? (サブネットの「auto-assign public IP」または EIP)
- サブネットが Public か? (ルートテーブルに
0.0.0.0/0 → igw-...があるか) - SG の outbound が許可 か? (デフォルトはすべて許可、自分で閉じた可能性)
- NACL の outbound が許可 か? (デフォルトはすべて許可)
- OS 内のファイアウォール (
ufw、iptables) が塞いでいないか?
たいてい 1) または 2)。Private サブネットなら NAT GW 経路を確認。
2) VPC CIDR を小さく取りすぎた #
10.0.0.0/24 (256 IP) で始めて、後でサブネットが足りなくなる — VPC CIDR は作成後の変更が難しい (補助 CIDR の追加は可能)。最初から /16 で広めに。
3) NAT Gateway 費用が請求書を圧迫 #
毎月 NAT GW だけで数十ドル? トラフィック量を点検。S3 / ECR 呼び出しが多いなら VPC Endpoint で NAT 迂回を検討。
4) 「キーペアをなくしました」 #
EC2 に SSH 接続するキーペアを失うと、事実上インスタンス再作成。このリスクから次第に SSM Session Manager (#2) に移行する流れ — キーそのものが要らなくなります。
5) 違う AZ にだけ RDS #
EC2 は AZ a、RDS は AZ b にしか置かない構成だと — 動作はするが AZ 間データ転送費用 が発生。同じ AZ に揃えるか、RDS を Multi-AZ に (両方に standby)。
6) EBS がインスタンスより長生き #
インスタンス終了時に EBS が自動削除されるか (DeleteOnTermination) を確認。古いオプションが false だと 終了したインスタンスの EBS だけが残って 1 か月分課金 という事故が多発。
まとめ #
今回押さえたこと:
- EC2 = 仮想コンピュータ 1 台。タイプ (
t3.micro等) でスペック決定、AMI で OS、EBS でディスク - AMI はリージョン単位。よく使うのは Amazon Linux 2023 / Ubuntu LTS
- EBS のデフォルトは
gp3。インスタンスストアは揮発性 (キャッシュ用途のみ) - VPC = AWS 内のプライベートネットワーク。CIDR
/16で始め、プライベート IP 領域のみ - サブネット は AZ 1 つに属します。Public / Private は自身の属性ではなく ルートテーブルが決定
- ルートテーブル の
0.0.0.0/0が IGW なら Public、NAT なら Private - IGW = VPC ↔ インターネット。NAT Gateway = Private の outbound のみ許可
- NAT GW は高い — VPC Endpoint で迂回
- ファイアウォールは SG (インスタンス、stateful) + NACL (サブネット、stateless)、ほぼ SG のみ触る
- 罠 — インターネット不通 5 ステップ、VPC CIDR 過小、NAT 費用、キー紛失、AZ 間トラフィック、EBS 残存
次回 — EC2 運用 #
EC2 を 1 台立ち上げる絵は描けました。次はその EC2 を 安全に扱う段階 へ移ります。
#2 EC2 運用 — security group、key pair、SSM では、SG ルールの設計、key pair の限界と SSM Session Manager への移行、AMI の作成まで、運用日常で使う道具を整理します。