インターネットゲートウェイとNATゲートウェイを理解する

前回の記事では、セキュリティグループとネットワークACLによるトラフィック制御について解説しました。本記事では、VPCからインターネットへの接続を実現するための重要なコンポーネントである「インターネットゲートウェイ」と「NATゲートウェイ」について詳しく解説します。これらを正しく理解し適切に設定することで、セキュアかつ柔軟なネットワーク構成を構築できます。

VPCにおけるインターネット接続の全体像

VPCは論理的に隔離されたネットワーク空間であり、デフォルトではインターネットと通信できません。インターネットとの接続を実現するには、適切なゲートウェイとルーティングの設定が必要です。

graph TB
    subgraph "インターネット"
        Internet((インターネット))
    end
    
    subgraph "VPC (10.0.0.0/16)"
        IGW[インターネット<br/>ゲートウェイ]
        
        subgraph "パブリックサブネット"
            Web[Webサーバー<br/>パブリックIP付与]
            NAT[NAT<br/>ゲートウェイ]
        end
        
        subgraph "プライベートサブネット"
            App[アプリサーバー<br/>プライベートIPのみ]
            DB[(データベース)]
        end
        
        PubRT[パブリック用<br/>ルートテーブル]
        PriRT[プライベート用<br/>ルートテーブル]
    end
    
    Internet <-->|双方向通信| IGW
    IGW <--> Web
    IGW <--> NAT
    NAT --> App
    
    PubRT -.->|0.0.0.0/0 → IGW| Web
    PubRT -.->|0.0.0.0/0 → IGW| NAT
    PriRT -.->|0.0.0.0/0 → NAT| App

VPCのインターネット接続には、主に2つのパターンがあります。

パターン	用途	使用するゲートウェイ	特徴
パブリックサブネット	インターネットからアクセス可能なリソース	インターネットゲートウェイ	双方向通信が可能
プライベートサブネット	インターネットからはアクセス不可だが、外部への通信は必要	NATゲートウェイ	アウトバウンドのみ可能

インターネットゲートウェイ（IGW）

インターネットゲートウェイ（Internet Gateway、IGW）は、VPCとインターネット間の通信を可能にする水平スケーリング型のゲートウェイです。

インターネットゲートウェイの特徴

インターネットゲートウェイには以下の特徴があります。

特徴	説明
高可用性	AWS側で冗長化されており、単一障害点にならない
帯域幅制限なし	通信帯域幅のボトルネックにならない設計
無料	IGW自体に料金は発生しない
1 VPCに1つ	1つのVPCには1つのIGWのみアタッチ可能
NATの役割	パブリックIPとプライベートIP間のアドレス変換を行う

インターネットゲートウェイの役割

インターネットゲートウェイは、主に2つの役割を担っています。

ルーティングターゲット

VPCのルートテーブルにおいて、インターネット宛てトラフィック（0.0.0.0/0）のターゲットとして機能します。パブリックサブネットのルートテーブルには、IGWへのルートが設定されています。

NATの実行

パブリックIPアドレス（またはElastic IP）を持つインスタンスに対して、ネットワークアドレス変換（NAT）を実行します。インターネットからの通信はパブリックIPアドレスで受信し、インスタンスのプライベートIPアドレスに変換されます。

sequenceDiagram
    participant Internet as インターネット
    participant IGW as インターネットゲートウェイ
    participant EC2 as EC2インスタンス<br/>(プライベートIP: 10.0.1.10<br/>パブリックIP: 54.x.x.x)

    Internet->>IGW: リクエスト (宛先: 54.x.x.x)
    Note over IGW: アドレス変換<br/>54.x.x.x → 10.0.1.10
    IGW->>EC2: リクエスト (宛先: 10.0.1.10)
    EC2->>IGW: レスポンス (送信元: 10.0.1.10)
    Note over IGW: アドレス変換<br/>10.0.1.10 → 54.x.x.x
    IGW->>Internet: レスポンス (送信元: 54.x.x.x)

インターネットゲートウェイでの通信要件

インターネットゲートウェイを経由してインターネットと通信するには、以下の要件をすべて満たす必要があります。

VPCにIGWがアタッチされている
サブネットのルートテーブルにIGWへのルートがある（0.0.0.0/0 → igw-xxxxxxxx）
インスタンスにパブリックIPまたはElastic IPが割り当てられている
セキュリティグループとネットワークACLが通信を許可している

これらの要件を満たすサブネットが「パブリックサブネット」です。

インターネットゲートウェイの作成と設定

AWSマネジメントコンソールからインターネットゲートウェイを作成・設定する手順を説明します。

手順1: インターネットゲートウェイの作成

VPCコンソールで「インターネットゲートウェイ」を選択
「インターネットゲートウェイの作成」をクリック
名前タグを入力して作成

手順2: VPCへのアタッチ

作成したIGWを選択
「アクション」から「VPCにアタッチ」を選択
対象のVPCを選択してアタッチ

手順3: ルートテーブルの設定

パブリックサブネット用のルートテーブルを選択
「ルートを編集」をクリック
以下のルートを追加

宛先	ターゲット
0.0.0.0/0	igw-xxxxxxxx

AWS CLIでの設定例は以下のとおりです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# インターネットゲートウェイの作成
aws ec2 create-internet-gateway \
  --tag-specifications 'ResourceType=internet-gateway,Tags=[{Key=Name,Value=production-igw}]'

# VPCへのアタッチ
aws ec2 attach-internet-gateway \
  --internet-gateway-id igw-xxxxxxxxx \
  --vpc-id vpc-xxxxxxxxx

# ルートテーブルにルートを追加
aws ec2 create-route \
  --route-table-id rtb-xxxxxxxxx \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id igw-xxxxxxxxx

Elastic IP（EIP）

Elastic IP（EIP）は、AWSアカウントに割り当てられる静的なパブリックIPv4アドレスです。インターネットゲートウェイを通じたインターネット通信や、NATゲートウェイの作成に使用します。

Elastic IPの特徴

特徴	説明
静的IPアドレス	インスタンスの停止・起動に関わらず、同じIPアドレスを維持
リージョンスコープ	特定のリージョン内でのみ使用可能
再マッピング可能	障害時に別のインスタンスに素早く付け替え可能
料金体系	使用中は無料、未使用時は課金される

パブリックIPとElastic IPの違い

EC2インスタンスには、起動時に自動割り当てされる「パブリックIP」と、明示的に関連付ける「Elastic IP」の2種類のパブリックIPアドレスがあります。

項目	パブリックIP	Elastic IP
割り当て	インスタンス起動時に自動（設定による）	明示的に取得・関連付け
永続性	インスタンス停止で解放される	明示的に解放するまで保持
再起動後	新しいIPアドレスが割り当てられる	同じIPアドレスを維持
料金	無料（実行中）	未関連付け時は課金
用途	一時的なインターネットアクセス	固定IPが必要なサーバー

Elastic IPの料金

Elastic IPは以下の条件で料金が発生します。

状態	料金
実行中のインスタンスに関連付けられている	無料
インスタンスに関連付けられていない	課金（約$0.005/時間）
停止中のインスタンスに関連付けられている	課金
アカウントで2つ目以降のEIP	課金（関連付けの有無に関わらず）

不要なElastic IPは速やかに解放し、コストを最適化しましょう。

Elastic IPの取得と関連付け

AWS CLIでのElastic IPの操作例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# Elastic IPの割り当て
aws ec2 allocate-address --domain vpc

# 出力例
# {
#     "PublicIp": "54.xxx.xxx.xxx",
#     "AllocationId": "eipalloc-xxxxxxxxx",
#     "Domain": "vpc"
# }

# EC2インスタンスへの関連付け
aws ec2 associate-address \
  --instance-id i-xxxxxxxxx \
  --allocation-id eipalloc-xxxxxxxxx

# Elastic IPの解放（不要になった場合）
aws ec2 release-address --allocation-id eipalloc-xxxxxxxxx

NATゲートウェイ

NATゲートウェイ（Network Address Translation Gateway）は、プライベートサブネット内のリソースがインターネットへ通信する際に使用するマネージドサービスです。インターネット側からプライベートサブネットへの直接アクセスは許可せず、アウトバウンド通信のみを可能にします。

NATゲートウェイの必要性

プライベートサブネットのリソースでも、以下のようなケースでインターネットへのアウトバウンド通信が必要になります。

OSのセキュリティパッチやパッケージのダウンロード
外部APIへのアクセス（決済サービス、通知サービスなど）
AWSサービスのパブリックエンドポイントへのアクセス
ソフトウェアライセンス認証

これらの通信をセキュアに実現するのがNATゲートウェイです。

graph TB
    subgraph "インターネット"
        API[外部API]
        Repo[パッケージ<br/>リポジトリ]
    end
    
    subgraph "VPC"
        IGW[インターネット<br/>ゲートウェイ]
        
        subgraph "パブリックサブネット"
            NAT[NATゲートウェイ<br/>Elastic IP: 54.x.x.x]
        end
        
        subgraph "プライベートサブネット"
            App[アプリサーバー<br/>10.0.11.10]
        end
    end
    
    App -->|ソース: 10.0.11.10| NAT
    NAT -->|ソース: 54.x.x.x| IGW
    IGW --> API
    IGW --> Repo

NATゲートウェイの特徴

特徴	説明
マネージドサービス	AWSが管理・運用、パッチ適用も自動
高可用性	各AZ内で冗長化されている
スケーラブル	最大100 Gbpsまで自動スケーリング
セキュア	インバウンド接続は不可（アウトバウンドのみ）
Elastic IP必須	作成時にElastic IPを関連付ける必要がある

NATゲートウェイの料金

NATゲートウェイは有料サービスです。料金体系を理解しておきましょう。

料金項目	料金（東京リージョン）
時間料金	約$0.062/時間
データ処理料金	約$0.062/GB

例えば、1か月（730時間）稼働し、100 GBのデータを処理した場合のコストは以下のようになります。

時間料金: $0.062 × 730時間 = $45.26
データ処理: $0.062 × 100 GB = $6.20
合計: 約$51.46/月

NATゲートウェイの動作原理

NATゲートウェイは、プライベートサブネットからのトラフィックに対して送信元アドレス変換（SNAT）を行います。

sequenceDiagram
    participant App as アプリサーバー<br/>(10.0.11.10)
    participant NAT as NATゲートウェイ<br/>(EIP: 54.x.x.x)
    participant IGW as インターネット<br/>ゲートウェイ
    participant API as 外部API

    App->>NAT: リクエスト (送信元: 10.0.11.10)
    Note over NAT: SNAT実行<br/>10.0.11.10 → 54.x.x.x
    NAT->>IGW: リクエスト (送信元: 54.x.x.x)
    IGW->>API: リクエスト転送
    API->>IGW: レスポンス (宛先: 54.x.x.x)
    IGW->>NAT: レスポンス転送
    Note over NAT: 逆変換<br/>54.x.x.x → 10.0.11.10
    NAT->>App: レスポンス (宛先: 10.0.11.10)

NATゲートウェイは接続の追跡テーブルを保持しており、レスポンストラフィックを正しいプライベートIPアドレスに返送します。

NATゲートウェイの作成と設定

NATゲートウェイを作成し、プライベートサブネットから使用できるよう設定する手順を説明します。

手順1: Elastic IPの取得

NATゲートウェイにはElastic IPが必須です。事前に取得しておきます。

手順2: NATゲートウェイの作成

VPCコンソールで「NATゲートウェイ」を選択
「NATゲートウェイを作成」をクリック
以下を設定

設定項目	設定値
名前	production-nat-1a
サブネット	パブリックサブネットを選択
接続タイプ	パブリック
Elastic IP	取得済みのEIPを選択

手順3: ルートテーブルの設定

プライベートサブネットのルートテーブルにNATゲートウェイへのルートを追加します。

宛先	ターゲット
0.0.0.0/0	nat-xxxxxxxxx

AWS CLIでの設定例は以下のとおりです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# Elastic IPの割り当て
ALLOCATION_ID=$(aws ec2 allocate-address --domain vpc --query 'AllocationId' --output text)

# NATゲートウェイの作成
aws ec2 create-nat-gateway \
  --subnet-id subnet-xxxxxxxxx \
  --allocation-id $ALLOCATION_ID \
  --tag-specifications 'ResourceType=natgateway,Tags=[{Key=Name,Value=production-nat-1a}]'

# NATゲートウェイの状態確認（availableになるまで待機）
aws ec2 describe-nat-gateways \
  --nat-gateway-ids nat-xxxxxxxxx \
  --query 'NatGateways[0].State'

# プライベートサブネットのルートテーブルにルートを追加
aws ec2 create-route \
  --route-table-id rtb-xxxxxxxxx \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-xxxxxxxxx

NATインスタンスとNATゲートウェイの比較

NATゲートウェイ登場以前は、EC2インスタンスをNATサーバーとして構成する「NATインスタンス」が使用されていました。現在でも特定のユースケースではNATインスタンスが選択される場合があります。

比較項目	NATゲートウェイ	NATインスタンス
可用性	AZ内で冗長化（マネージド）	自分でフェイルオーバー構成が必要
帯域幅	最大100 Gbps	インスタンスタイプに依存
メンテナンス	AWS管理（パッチ適用不要）	自己管理（OS/ソフトウェア更新必要）
セキュリティグループ	関連付け不可	関連付け可能
ポートフォワーディング	不可	可能
コスト	時間+データ処理課金	インスタンス料金のみ
踏み台機能	なし	兼用可能

NATゲートウェイを選ぶべきケース

高可用性・高帯域幅が必要
運用負荷を軽減したい
AWSのベストプラクティスに従いたい

NATインスタンスを検討するケース

極端にコストを抑えたい（低トラフィック環境）
ポートフォワーディングが必要
踏み台サーバーと兼用したい

ルートテーブルの設計

インターネットゲートウェイとNATゲートウェイを適切に機能させるには、ルートテーブルの正しい設計が不可欠です。

パブリックサブネットのルートテーブル

パブリックサブネットでは、インターネット宛てのトラフィックをインターネットゲートウェイに向けます。

宛先	ターゲット	説明
10.0.0.0/16	local	VPC内通信
0.0.0.0/0	igw-xxxxxxxx	インターネット宛て

プライベートサブネットのルートテーブル

プライベートサブネットでは、インターネット宛てのトラフィックをNATゲートウェイに向けます。

宛先	ターゲット	説明
10.0.0.0/16	local	VPC内通信
0.0.0.0/0	nat-xxxxxxxx	インターネット宛て（NAT経由）

ルートテーブル設計の全体像

graph TB
    subgraph "VPC (10.0.0.0/16)"
        IGW[インターネットゲートウェイ]
        
        subgraph "AZ-a"
            subgraph "パブリックサブネット (10.0.1.0/24)"
                NAT1[NAT Gateway]
                Web1[Webサーバー]
            end
            subgraph "プライベートサブネット (10.0.11.0/24)"
                App1[アプリサーバー]
            end
        end
        
        subgraph "AZ-c"
            subgraph "パブリックサブネット (10.0.2.0/24)"
                NAT2[NAT Gateway]
                Web2[Webサーバー]
            end
            subgraph "プライベートサブネット (10.0.12.0/24)"
                App2[アプリサーバー]
            end
        end
        
        PubRT[パブリック用RT<br/>0.0.0.0/0 → IGW]
        PriRT1[プライベート用RT-a<br/>0.0.0.0/0 → NAT1]
        PriRT2[プライベート用RT-c<br/>0.0.0.0/0 → NAT2]
    end
    
    Internet((インターネット)) <--> IGW
    PubRT -.-> Web1
    PubRT -.-> Web2
    PubRT -.-> NAT1
    PubRT -.-> NAT2
    PriRT1 -.-> App1
    PriRT2 -.-> App2

マルチAZ構成でのNATゲートウェイ配置

本番環境では、可用性を高めるためにNATゲートウェイを各AZに配置することが推奨されています。

単一AZ配置の問題点

NATゲートウェイを1つのAZにのみ配置した場合、以下のリスクがあります。

NATゲートウェイのあるAZが障害を起こすと、他のAZのプライベートリソースもインターネットアクセスが不能になる
クロスAZ通信によるデータ転送料金が発生する

graph TB
    subgraph "AZ-a（障害発生）"
        NAT1[NAT Gateway<br/>障害]
        App1[アプリ1<br/>通信不能]
    end
    
    subgraph "AZ-c"
        App2[アプリ2<br/>通信不能]
    end
    
    App1 -.->|X| NAT1
    App2 -.->|X| NAT1

マルチAZ配置のベストプラクティス

各AZにNATゲートウェイを配置し、各AZのプライベートサブネットは同じAZのNATゲートウェイを使用するよう設定します。

graph TB
    subgraph "AZ-a"
        NAT1[NAT Gateway 1]
        App1[アプリ1]
        App1 --> NAT1
    end
    
    subgraph "AZ-c"
        NAT2[NAT Gateway 2]
        App2[アプリ2]
        App2 --> NAT2
    end
    
    NAT1 --> IGW[インターネット<br/>ゲートウェイ]
    NAT2 --> IGW

この構成のメリットは以下のとおりです。

1つのAZに障害が発生しても、他のAZは影響を受けない
クロスAZのデータ転送料金を削減できる
各AZが独立して動作するため、障害の影響範囲を限定できる

コスト最適化の考慮

NATゲートウェイは時間課金されるため、マルチAZ配置はコストが増加します。環境に応じた判断が必要です。

環境	推奨構成	理由
本番環境	各AZに1台ずつ	可用性を最優先
開発/検証環境	1台のみ	コスト削減を優先
低トラフィック環境	1台または検討	費用対効果を検討

VPCエンドポイントとの組み合わせ

プライベートサブネットからAWSサービスへのアクセスには、NATゲートウェイを使用する以外に「VPCエンドポイント」を使用する方法があります。

VPCエンドポイントの種類

種類	対象サービス	仕組み
ゲートウェイエンドポイント	S3、DynamoDB	ルートテーブルにエントリを追加
インターフェイスエンドポイント	その他多数のサービス	ENIを作成しプライベート接続

NATゲートウェイとVPCエンドポイントの使い分け

graph TB
    subgraph "プライベートサブネット"
        App[アプリサーバー]
    end
    
    subgraph "VPCエンドポイント経由"
        S3EP[S3エンドポイント]
        S3[Amazon S3]
    end
    
    subgraph "NATゲートウェイ経由"
        NAT[NAT Gateway]
        ExtAPI[外部API]
    end
    
    App -->|AWS内部ネットワーク<br/>料金削減| S3EP --> S3
    App -->|インターネット経由| NAT --> ExtAPI

S3やDynamoDBなど頻繁にアクセスするAWSサービスにはVPCエンドポイントを使用することで、NATゲートウェイのデータ処理料金を削減できます。

トラブルシューティング

インターネット接続に問題が発生した場合のチェックポイントを紹介します。

パブリックサブネットから接続できない場合

チェック項目	確認方法
IGWがVPCにアタッチされているか	VPCコンソールでIGWの状態を確認
ルートテーブルにIGWへのルートがあるか	`0.0.0.0/0 → igw-xxx`のルートを確認
インスタンスにパブリックIP/EIPがあるか	EC2コンソールでIPアドレスを確認
セキュリティグループが許可しているか	アウトバウンドルールを確認
NACLが許可しているか	インバウンド/アウトバウンド両方を確認

プライベートサブネットから接続できない場合

チェック項目	確認方法
NATゲートウェイが「available」状態か	VPCコンソールでNATの状態を確認
NATがパブリックサブネットにあるか	サブネットの設定を確認
ルートテーブルにNATへのルートがあるか	`0.0.0.0/0 → nat-xxx`のルートを確認
セキュリティグループが許可しているか	アウトバウンドルールを確認
NACLが許可しているか	エフェメラルポートの許可を確認

よくあるミス

NATゲートウェイをプライベートサブネットに作成してしまう

NATゲートウェイはパブリックサブネットに作成する必要があります。プライベートサブネットに作成すると、NATゲートウェイ自体がインターネットに到達できません。

セキュリティグループのアウトバウンドを制限しすぎる

デフォルトではすべてのアウトバウンドが許可されていますが、セキュリティ強化のために制限した場合、必要な通信まで遮断されることがあります。

まとめ

本記事では、VPCのインターネット接続を実現するインターネットゲートウェイとNATゲートウェイについて解説しました。

インターネットゲートウェイはVPCとインターネット間の双方向通信を可能にする
Elastic IPは静的なパブリックIPアドレスを提供し、NATゲートウェイの作成に必須
NATゲートウェイはプライベートサブネットからのアウトバウンド通信を可能にする
本番環境ではNATゲートウェイを各AZに配置して可用性を確保する
ルートテーブルの正しい設定がインターネット接続の鍵となる

これらのコンポーネントを正しく理解し適切に設定することで、セキュアで可用性の高いネットワーク構成を構築できます。

VPCにおけるインターネット接続の全体像#

インターネットゲートウェイ（IGW）#

インターネットゲートウェイの特徴#

インターネットゲートウェイの役割#

インターネットゲートウェイでの通信要件#

インターネットゲートウェイの作成と設定#

Elastic IP（EIP）#

Elastic IPの特徴#

パブリックIPとElastic IPの違い#

Elastic IPの料金#

Elastic IPの取得と関連付け#

NATゲートウェイ#

NATゲートウェイの必要性#

NATゲートウェイの特徴#

NATゲートウェイの料金#

NATゲートウェイの動作原理#

NATゲートウェイの作成と設定#

NATインスタンスとNATゲートウェイの比較#

ルートテーブルの設計#

パブリックサブネットのルートテーブル#

プライベートサブネットのルートテーブル#

ルートテーブル設計の全体像#

マルチAZ構成でのNATゲートウェイ配置#

単一AZ配置の問題点#

マルチAZ配置のベストプラクティス#

コスト最適化の考慮#

VPCエンドポイントとの組み合わせ#

VPCエンドポイントの種類#

NATゲートウェイとVPCエンドポイントの使い分け#

トラブルシューティング#

パブリックサブネットから接続できない場合#

プライベートサブネットから接続できない場合#

よくあるミス#

まとめ#

参考リンク#