Networking & Security

ファイアウォール
デプロイメントモデル完全ガイド

シングルアーム(One-arm)とデュアルアーム(Two-arm)の2つのデプロイメントモデルを、ビル警備のたとえ話で直感的に理解しましょう。

最初に押さえる3つのポイント

1
シングルアームはNIC 1つで「検査だけ」を担当し、NAT処理は別途NATゲートウェイが必要
2
デュアルアームはNIC 2つで「検査+NAT」を両方こなし、NATゲートウェイが不要になりコスト削減できる
3
NATゲートウェイは時間課金+データ処理量課金のため、大規模環境では高額になりやすい
4
デュアルアームを選ぶにはファイアウォールベンダーのNATサポートが前提条件

たとえ話:ビル警備で理解するデプロイメントモデル

オフィスビルの警備体制にたとえてみよう

ファイアウォールのデプロイメントモデルは、オフィスビルの警備体制にそっくりです。 ビルに入ってくる来客(トラフィック)をどうチェックし、どう受付処理するかの違いです。

AWSの概念 ビル警備のたとえ
ファイアウォールアプライアンス 警備員(来客をチェックする人)
NIC(ネットワークインターフェイス) 警備員が配置される出入口の数
トラフィック検査 身分証の確認・手荷物検査
NAT処理 来客用の入館証を発行(内部IDへ変換)
NATゲートウェイ 入館証発行を担当する受付カウンター(別料金)
シングルアーム 1つの出入口に立つ警備員。検査だけ担当し、入館証発行は別の受付へ
デュアルアーム 外用・内用2つの出入口に立つ警備員。検査も入館証発行も一人でこなす

2つのデプロイメントモデル概要

1

シングルアームモード

One-arm Mode
  • NIC は1つだけ構成
  • トラフィック検査のみを担当
  • NAT処理はNATゲートウェイが別途必要
  • 構成がシンプルで導入しやすい
  • NATゲートウェイの追加コストが発生
2

デュアルアームモード

Two-arm Mode
  • NIC は2つ構成(パブリック+プライベート)
  • トラフィック検査+NATの両方を担当
  • NATゲートウェイが不要
  • ベンダーのNAT機能サポートが前提
  • NATゲートウェイ費用を削減できる

シングルアームモード詳細

たとえ話:出入口が1つの警備員

シングルアームは、ビルの1つの出入口だけに立つ警備員です。 来客(トラフィック)が通るたびに身分証を確認しますが、入館証の発行は別の受付カウンター(NATゲートウェイ)にお任せします。

技術的な仕組み

ファイアウォールアプライアンスに単一のENI(Elastic Network Interface)をアタッチします。 トラフィックはルートテーブルによってファイアウォールに転送され、検査後に同じインターフェイスから戻されます。 送信元/宛先のIPアドレス変換(NAT)は行わないため、インターネットへの通信には別途NATゲートウェイを配置する必要があります。

シングルアームモード構成図 インターネット パブリックサブネット ファイアウォール プライベートサブネット インターネット 外部トラフィック Internet Gateway IGW NAT Gateway アドレス変換(別料金) ※追加コストが発生 ファイアウォール NIC: 1つ(検査のみ) NATは行わない EC2 / RDS プライベート リソース トラフィック転送 検査済み 戻りトラフィック → NAT GWへ NAT変換後

デュアルアームモード詳細

たとえ話:2つの出入口を管理する警備員

デュアルアームは、外向き出入口と内向き出入口の2カ所に立つ警備員です。 来客の身分証確認(検査)だけでなく、入館証の発行(NAT処理)も自分で行います。 別の受付カウンター(NATゲートウェイ)が不要なので、人件費(=AWSコスト)が削減できます。

技術的な仕組み

ファイアウォールアプライアンスに2つのENIをアタッチします。 1つ目はパブリックサブネットに、2つ目はプライベートサブネットに接続されます。 トラフィックはプライベート側のENIから入り、ファイアウォールが検査し、送信元NATを実行して、パブリック側のENIからインターネットに出ていきます。 NATゲートウェイを経由しないため、そのぶんコストを大幅に削減できます。

デュアルアームモード構成図 インターネット パブリックサブネット ファイアウォール(2 NIC) プライベートサブネット インターネット 外部トラフィック Internet Gateway IGW NIC 1(パブリック) ENI #1 ファイアウォール 検査 + NAT処理 NATゲートウェイ不要 NIC 2(プライベート) ENI #2 EC2 / RDS プライベート リソース 受信 検査+NAT済み 戻り

比較アーキテクチャ図:シングル vs デュアル

シングルアーム vs デュアルアーム 比較 シングルアームモード Internet IGW Firewall (1 NIC) 検査のみ NAT GW 追加コスト発生 NAT EC2 / RDS 構成シンプル、でもNAT GW費用が追加 NAT GW: 約$0.045/h + $0.045/GB コスト:高い(NAT GW料金が追加) デュアルアームモード Internet IGW Firewall (2 NIC) 検査 + NAT処理 NAT GW不要 EC2 / RDS 構成やや複雑、でもコスト削減効果大 ベンダーのNAT機能サポートが前提 コスト:低い(NAT GW料金が不要)

徹底比較表

比較項目 シングルアーム(One-arm) デュアルアーム(Two-arm)
NIC数 1つ 2つ(パブリック+プライベート)
トラフィック検査 対応 対応
NAT処理 別途NATゲートウェイが必要 アプライアンス自体で処理
構成の複雑さ シンプル やや複雑
NATゲートウェイ 必要(追加コスト) 不要(コスト削減)
ベンダーNATサポート 不要 必要(前提条件)
コスト効率 低い(NAT GW課金あり) 高い(NAT GW不要)
ビルのたとえ 警備員は検査のみ。入館証は別窓口 警備員が検査+入館証発行を兼任

コスト比較

NATゲートウェイは時間単位と処理データ量に基づく二重課金のサービスです。 大規模なトラフィックを処理する環境では、この費用が無視できないレベルになります。

シングルアーム(NAT GW追加時)
月額 $200〜$1,000+
NAT GW: $0.045/時間 + $0.045/GB処理
例: 月500GB処理 → 約 $55(NATだけで)
+ファイアウォールアプライアンス料金
デュアルアーム(NAT GW不要)
NAT GW分を節約
ファイアウォールアプライアンスのみ
NAT機能は追加料金なしで内蔵
大規模環境ほど節約効果が大きい
ビル警備のたとえで理解するコスト

シングルアーム = 警備員(月給あり)+ 別の受付カウンター(入館証発行の外注費が毎月かかる)
デュアルアーム = 警備員(月給あり)のみ。入館証発行も自分でやるので外注費ゼロ

選定フローチャート

ファイアウォールベンダーはNAT機能をサポートしている?
いいえ → 選択肢なし
シングルアームモード

NATゲートウェイを追加配置

はい → 次の質問へ
コスト削減が優先事項?
いいえ(シンプルさ優先)
シングルアームモード

構成のシンプルさを優先

はい(コスト優先)
デュアルアームモード

NAT GW費用を削減

設定例

シングルアーム構成のルートテーブル例

# シングルアーム: プライベートサブネットのルートテーブル
# トラフィックをファイアウォールENIに転送
aws ec2 create-route \
  --route-table-id rtb-private-xxxxx \
  --destination-cidr-block 0.0.0.0/0 \
  --network-interface-id eni-firewall-xxxxx

# NATゲートウェイの作成(シングルアームでは必須)
aws ec2 create-nat-gateway \
  --subnet-id subnet-public-xxxxx \
  --allocation-id eipalloc-xxxxx
Resources:
  NatGateway:
    Type: AWS::EC2::NatGateway
    Properties:
      SubnetId: !Ref PublicSubnet
      AllocationId: !GetAtt EIP.AllocationId

  PrivateRoute:
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref PrivateRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      NetworkInterfaceId: !Ref FirewallENI
# シングルアーム: NATゲートウェイ(必須)
resource "aws_nat_gateway" "main" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public.id
}

# プライベートルート → ファイアウォールENI
resource "aws_route" "private_to_fw" {
  route_table_id         = aws_route_table.private.id
  destination_cidr_block = "0.0.0.0/0"
  network_interface_id   = aws_network_interface.fw.id
}

デュアルアーム構成のルートテーブル例

# デュアルアーム: プライベートサブネットのルートテーブル
# トラフィックをファイアウォールのプライベート側ENIに転送
aws ec2 create-route \
  --route-table-id rtb-private-xxxxx \
  --destination-cidr-block 0.0.0.0/0 \
  --network-interface-id eni-fw-private-xxxxx

# NATゲートウェイは不要!
# ファイアウォールアプライアンスがNATを処理
Resources:
  # NATゲートウェイは不要!
  FirewallPublicENI:
    Type: AWS::EC2::NetworkInterface
    Properties:
      SubnetId: !Ref PublicSubnet
      SourceDestCheck: false

  FirewallPrivateENI:
    Type: AWS::EC2::NetworkInterface
    Properties:
      SubnetId: !Ref PrivateSubnet
      SourceDestCheck: false

  PrivateRoute:
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref PrivateRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      NetworkInterfaceId: !Ref FirewallPrivateENI
# デュアルアーム: NATゲートウェイは不要
# 2つのENIを作成
resource "aws_network_interface" "fw_public" {
  subnet_id         = aws_subnet.public.id
  source_dest_check = false
}

resource "aws_network_interface" "fw_private" {
  subnet_id         = aws_subnet.private.id
  source_dest_check = false
}

# プライベートルート → FWプライベートENI
resource "aws_route" "private_to_fw" {
  route_table_id         = aws_route_table.private.id
  destination_cidr_block = "0.0.0.0/0"
  network_interface_id   = aws_network_interface.fw_private.id
}

ベストプラクティス vs アンチパターン

ベストプラクティス
  • デュアルアーム選択前にベンダーのNATサポートを確認する
  • Source/Dest Check を無効にする(両モード共通で必須)
  • ファイアウォールENIにElastic IPを関連付ける(デュアルアーム時)
  • AZ ごとにファイアウォールを配置して冗長化する
  • Gateway Load Balancer(GWLB)との組み合わせを検討する
  • コスト試算を行い、NAT GWの費用対効果を事前に比較する
アンチパターン
  • ベンダーNATサポート未確認でデュアルアームを選択する
  • Source/Dest Check を有効のままにする
  • 単一AZにのみファイアウォールを配置する
  • NATゲートウェイのコストを見積もらずにシングルアームを選ぶ
  • ルートテーブルの更新漏れ(特にAZ追加時)
  • ファイアウォールの可用性監視を怠る

トラブルシューティング

プライベートリソースからインターネットに接続できない
原因1: Source/Dest Check が無効になっていない → ファイアウォールENIの Source/Dest Check を必ず無効にする
原因2: ルートテーブルがファイアウォールENIを指していない → 0.0.0.0/0 のネクストホップを確認
原因3: (シングルアーム時)NATゲートウェイが未作成 → NATゲートウェイをパブリックサブネットに配置
デュアルアームでNATが動作しない
原因1: ファイアウォールのNAT機能が有効化されていない → ベンダー管理画面でNAT設定を確認
原因2: パブリック側ENIにElastic IPが割り当てられていない → EIPをアタッチする
原因3: パブリックサブネットのルートテーブルにIGWへのルートがない → 0.0.0.0/0 → IGW を追加
非対称ルーティングが発生している
原因: 行きと戻りのパスが異なるルートを通っている → ルートテーブルで行き・戻りの両方がファイアウォールを経由するよう設定する。GWLBを使うと自動的に対称ルーティングが保証される。

試験対策

ANS-C01 / SAP-C02 出題ポイント
頻出 「コスト削減」がキーワードの場合、NATゲートウェイを排除するデュアルアームが正解になりやすい
頻出 サードパーティ ファイアウォールアプライアンスのデプロイ時はSource/Dest Check の無効化が必須
注意 「シンプルな構成」が要求される場合は、シングルアームが適切(NATゲートウェイの追加コストは許容)
注意 Gateway Load Balancer(GWLB)はファイアウォールのスケーリングと可用性を向上させるサービスとして頻出
ひっかけ NATインスタンス vs NATゲートウェイの違いと混同しないこと。デプロイメントモデルの話はアプライアンス配置の話

よくある質問(FAQ)

AWS Network Firewallはマネージドサービスのため、ユーザーがNIC数を選択する概念はありません。NATゲートウェイとの組み合わせで動作し、AWSが内部的にトラフィックのルーティングを管理します。シングルアーム/デュアルアームの選択は、主にサードパーティ製ファイアウォールアプライアンス(Palo Alto、Fortinet、Check Pointなど)をEC2上にデプロイする場合に関係します。
GWLBを使う場合、GWLBエンドポイント経由でトラフィックがファイアウォールに転送されます。GWLBはGENEVEカプセル化を使い、トラフィックを透過的に転送するため、シングルアームに近い構成になりますが、スケーラビリティと可用性が大幅に向上します。NATゲートウェイとの組み合わせが一般的です。
EC2インスタンスのENIに設定される属性で、有効にすると「自分宛て/自分からのトラフィック以外は破棄」されます。ファイアウォールはトラフィックを中継する必要があるため、この機能を無効にしないと他のインスタンス宛てのトラフィックが破棄されてしまいます。NATゲートウェイやロードバランサーでは自動的に無効になっていますが、EC2ベースのアプライアンスでは手動で無効にする必要があります。
主要なファイアウォールベンダーの多くがデュアルアームモードをサポートしています。Palo Alto Networks(VM-Series)、Fortinet(FortiGate)、Check Point(CloudGuard)、Cisco(FTDv)などが代表的です。ただし、各ベンダーのAWS向けデプロイガイドで最新のサポート状況を確認することを推奨します。

用語集

ENI(Elastic Network Interface)
VPC内の仮想ネットワークカード。EC2にアタッチしてネットワーク接続を提供する。
NAT(Network Address Translation)
プライベートIPをパブリックIPに変換する仕組み。インターネット通信に必要。
NATゲートウェイ
AWSマネージドのNATサービス。時間課金+データ処理量課金の二重課金。
Source/Dest Check
ENIの属性。有効時は自分宛て以外のパケットを破棄。FW利用時は無効にする必要あり。
GWLB(Gateway Load Balancer)
サードパーティアプライアンスへの透過的なトラフィック転送とスケーリングを実現するLB。
GENEVE
GWLBが使用するトンネリングプロトコル。元パケットのメタデータを保持したまま転送できる。

チートシート

シングルアーム = NIC 1つ
検査のみ。NAT GW必要。シンプルだが高コスト。
デュアルアーム = NIC 2つ
検査+NAT。NAT GW不要。ベンダーサポート必須。
必ずやること
Source/Dest Check 無効化。ルートテーブル更新。冗長化。
試験の急所
「コスト削減」→ デュアルアーム。「シンプル」→ シングルアーム。

Created by SSuzuki1063

AWS SAP Learning Resources