Zenn
🐈

AWS学びなおし(+TF)_NAT

2025/03/05に公開
AWS
tech

AWSのNAT (Network Address Translation) は、主にプライベートサブネットに配置されたEC2インスタンスなどが、インターネットへのアウトバウンド接続を確立するために使用されるサービスです。

NATの基本的な役割:

  • プライベートサブネットからのアウトバウンドインターネット接続: プライベートサブネット内のインスタンスは、パブリックIPアドレスを持たないため、通常はインターネットに直接アクセスできません。NATを使用することで、プライベートIPアドレスをNATのパブリックIPアドレスに変換し、インターネットへのアクセスを可能にします。
  • インターネットからのインバウンド接続の拒否: NATはアウトバウンド接続を許可する一方で、インターネットからのインバウンド接続はデフォルトで拒否します。これにより、プライベートサブネット内のリソースをインターネットから直接アクセスされるリスクを低減し、セキュリティを向上させることができます。
  • IPアドレスの節約: プライベートサブネットではプライベートIPアドレスを使用するため、グローバルで利用可能なパブリックIPアドレスの消費を抑えることができます。

NATの種類:

AWSには主に2種類のNATが存在します。

  1. NAT Gateway (マネージド):

    • AWSがマネージドサービスとして提供するNATです。
    • 高可用性、高スループットで、可用性ゾーン内で冗長化されています。
    • 設定や管理が容易で、運用負荷が低いのが特徴です。
    • 料金は、時間単位の料金とデータ処理量に基づいて課金されます。
    • 推奨されるNATであり、特別な理由がない限りNAT Gatewayを選択するのが一般的です。

  2. NAT Instance (セルフマネージド):

    • ユーザー自身がEC2インスタンスをNATとして構成するものです。
    • 柔軟性が高く、カスタマイズ性に優れます（例：プロキシ機能の追加など）。
    • 自身で可用性、パフォーマンス、セキュリティを考慮した設計・構築・運用が必要です。
    • NAT Gatewayと比較して、運用負荷が高くなります。
    • 料金は、EC2インスタンスの料金とデータ転送料金に基づいて課金されます。
    • 特定の要件がある場合や、コストを極限まで抑えたい場合などに検討されます。

NAT Gateway と NAT Instance の比較:

特徴 NAT Gateway NAT Instance
管理 AWSマネージド ユーザー管理
可用性 高可用性 (AZ内で冗長化) 自身でHA構成が必要
スループット 高スループット インスタンスタイプに依存
設定 簡単 比較的複雑
運用負荷 低い 高い
コスト データ処理量課金 + 時間課金 EC2インスタンス料金 + データ転送料金
推奨 推奨 特定の要件がある場合

ユースケース:

  • ソフトウェアアップデート: プライベートサブネット内のLinux/Windowsインスタンスが、インターネット上のアップデートサーバからOSやミドルウェアのアップデートをダウンロードする。
  • パッケージインストール: yum, apt-get, pip などを使用して、インターネット上のリポジトリからパッケージをインストールする。
  • ログの外部送信: プライベートサブネット内のアプリケーションログを、CloudWatch Logsやサードパーティのログ管理サービスに送信する。
  • API連携: プライベートサブネット内のアプリケーションが、外部のAPIエンドポイント (例: 外部決済API, 天気情報API) と通信する。
  • 踏み台サーバ経由でのアクセス: プライベートサブネット内のリソースに、踏み台サーバ (SSH/Bastion) 経由でアクセスする際、踏み台サーバからプライベートリソースへのアクセスはプライベートIPアドレスで行い、踏み台サーバ自体がNAT Gateway/Instance経由でインターネットにアクセスする。

【実務レベルの内容と重要事項】

実務におけるNAT Gatewayの重要事項:

  • 可用性ゾーン (AZ) 冗長化: NAT GatewayはAZ内で冗長化されていますが、AZ障害が発生した場合、そのAZ内のNAT Gatewayは利用できなくなります。複数のAZにまたがる構成 (Multi-AZ構成) を採用することで、AZ障害時にも可用性を維持できます。
  • ルートテーブルの設定: プライベートサブネットのルートテーブルで、インターネット宛 (0.0.0.0/0) のトラフィックをNAT Gatewayに向ける必要があります。ルートテーブルの設定ミスは、インターネット接続障害の最も一般的な原因の一つです。
  • セキュリティグループ: NAT Gateway自体にはセキュリティグループを設定できませんが、NAT Gatewayを経由するインスタンスのセキュリティグループ (アウトバウンドルール) を適切に設定する必要があります。アウトバウンドルールで必要なポート (例: 443/HTTPS, 80/HTTP) を許可する必要があります。
  • ネットワークACL: サブネットに関連付けられたネットワークACL (アウトバウンドルール) も、NAT Gatewayを経由するトラフィックを許可する必要があります。ステートフルなセキュリティグループ と異なり、ネットワークACLはステートレスであるため、インバウンド/アウトバウンド両方のルールを適切に設定する必要があります。
  • SNATポートの枯渇: 大量のアウトバウンド接続を短時間に確立する場合、NAT GatewayのSNAT (Source Network Address Translation) ポートが枯渇する可能性があります。一般的にはNAT Gatewayのスケールアウトにより自動的に緩和されますが、極端なケースではアプリケーション側の接続数を調整するなどの対策が必要になる場合があります。(通常は意識する必要は低い)
  • 料金最適化: NAT Gatewayはデータ処理量課金があるため、不要なアウトバウンドトラフィックを削減することでコストを最適化できます。例えば、S3やDynamoDBなどAWSサービスへのアクセスは、VPCエンドポイント経由にすることで、NAT Gatewayを経由せず、データ処理量課金を回避できます。
  • 障害時の切り分け: インターネット接続に問題が発生した場合、以下の点を確認します。
    • ルートテーブル: プライベートサブネットのルートテーブル設定が正しいか。
    • セキュリティグループ: インスタンスのアウトバウンドセキュリティグループ設定が正しいか。
    • ネットワークACL: サブネットのネットワークACL (アウトバウンド) 設定が正しいか。
    • NAT Gatewayの状態: AWSコンソールでNAT Gatewayの状態が正常か確認する。
    • CloudWatch メトリクス: NAT Gatewayの PacketsDroppedCount メトリクスなどでパケットロスが発生していないか確認する。

実務におけるNAT Instanceの重要事項:

  • 高可用性構成: NAT Instanceを本番環境で使用する場合は、Auto ScalingグループとElastic IPアドレス を組み合わせてHA構成を構築する必要があります。フェイルオーバー時の切り替え時間や、ヘルスチェックの設定などを適切に行う必要があります。
  • パフォーマンス: NAT Instanceのパフォーマンスは、EC2インスタンスのタイプに依存します。ネットワークパフォーマンスの高いインスタンスタイプ (例: m5.large, c5.xlarge) を選択し、必要に応じてスケールアップ/スケールアウトを検討する必要があります。
  • セキュリティ強化: NAT InstanceはEC2インスタンスであるため、OSやミドルウェアのセキュリティアップデート を定期的に行う必要があります。また、セキュリティグループやネットワークACLを適切に設定し、不要なポートを閉じることが重要です。
  • ルーティング設定の複雑さ: NAT InstanceをHA構成にする場合、ルーティング設定が複雑になる場合があります。フェイルオーバー時のルートテーブルの切り替えなどを自動化する必要があります。
  • 運用負荷の高さ: NAT Instanceは自身で運用する必要があるため、パッチ適用、監視、障害対応 など運用負荷が高くなります。

NAT Gateway と NAT Instance の選択:

  • 特別な理由がない限り、NAT Gateway を選択 するのが推奨されます。
  • NAT Instance は、以下のようなケースで検討 されることがあります。
    • コストを極限まで抑えたい場合: NAT Instance は、EC2の無料利用枠を活用したり、スポットインスタンスを使用することで、NAT Gatewayよりもコストを抑えられる可能性があります。ただし、運用負荷とのトレードオフを考慮する必要があります。
    • 高度なカスタマイズが必要な場合: NAT Instance は、ユーザー自身がOSやミドルウェアを自由に構成できるため、プロキシ機能やパケットフィルタリング機能などを追加したい場合に適しています。
    • 学習目的や検証環境: NAT Instance は、NATの仕組みを理解するための学習目的や、検証環境などで一時的に使用する場合には有効です。

【実務でどの程度使用されるのか】

NAT は、AWS環境において非常に 広く使用される 基本的なネットワークコンポーネント です。

実務での利用頻度:

  • ほぼ全てのVPC環境 で使用されます。
  • 特にセキュリティを重視するシステム では、プライベートサブネット構成が推奨されるため、NATは必須となります。
  • パブリックサブネットのみで構成されたシステムは、セキュリティリスクが高く、実務環境ではほとんど見られません (例外的に、ALBやWAFなど、インターネットからのアクセスを直接受ける必要があるコンポーネントはパブリックサブネットに配置されます)。
  • NAT Gateway が圧倒的に多く使用 されています。
  • NAT Instance は、特定の要件がある場合に限定的に使用 されます。

NAT なし構成 (インターネットゲートウェイ (IGW) のみ):

  • プライベートサブネットにNATを設置せず、インターネットゲートウェイ (IGW) のみを使用する構成も技術的には可能ですが、セキュリティ上のリスクが非常に高い ため、実務環境では絶対に避けるべき です。
  • この構成では、プライベートサブネット内のインスタンスがパブリックIPアドレスを持つ必要があり、インターネットから直接アクセス可能になってしまいます。
  • セキュリティグループやネットワークACLでインバウンドを厳しく制限しても、設定ミスや脆弱性により、外部からの不正アクセスを許してしまうリスクがあります。

まとめ:

実務においては、NAT (特にNAT Gateway) は、AWS環境を安全かつ効率的に運用するための 不可欠なコンポーネント です。クラウドエンジニアとして、NATの仕組み、設定、トラブルシューティングについて深く理解しておくことは非常に重要です。

【terraformのコードで記述する場合の基本的内容と実務レベルの内容】

terraformのコードで記述する場合の基本的内容 (NAT Gateway):

基本的なNAT GatewayのTerraformコードは以下のようになります。

resource "aws_eip" "nat_gateway" {
  vpc = true
  tags = {
    Name = "nat-gateway-eip"
  }
}

resource "aws_nat_gateway" "nat_gateway" {
  allocation_id = aws_eip.nat_gateway.id
  subnet_id     = aws_subnet.public_subnet.id # パブリックサブネットを指定
  tags = {
    Name = "nat-gateway"
  }

  # depends_on = [aws_internet_gateway.igw] # IGWへの依存関係 (明示的に書かなくても暗黙的に依存関係は作成される)
}

resource "aws_route_table" "private_subnet" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.nat_gateway.id # NAT Gateway を指定
  }

  tags = {
    Name = "private-subnet-route-table"
  }
}

resource "aws_route_table_association" "private_subnet" {
  subnet_id      = aws_subnet.private_subnet.id # プライベートサブネットに関連付け
  route_table_id = aws_route_table.private_subnet.id
}

コードの説明:

  1. aws_eip "nat_gateway": NAT Gatewayに割り当てるElastic IPアドレス (EIP) を作成します。vpc = true を指定することで、VPC内のEIPとして作成されます。
  2. aws_nat_gateway "nat_gateway": NAT Gatewayリソースを作成します。
    • allocation_id: 作成したEIPのIDを指定します。
    • subnet_id: NAT Gatewayを配置するパブリックサブネットのIDを指定します。NAT Gatewayはパブリックサブネットに配置する必要があります。
    • tags: リソースにタグを付与します (Nameタグは必須ではありませんが、管理のために推奨されます)。
    • depends_on: 明示的に依存関係を書かなくても、Terraformはリソース間の依存関係を暗黙的に推測しますが、必要に応じて depends_on で明示的に依存関係を指定することもできます。 (例: IGWが作成されてからNAT Gatewayを作成したい場合など。しかし、通常はTerraformが適切に依存関係を解決してくれるため、明示的に書く必要性は低い)
  3. aws_route_table "private_subnet": プライベートサブネット用のルートテーブルを作成します。
    • vpc_id: VPC IDを指定します。
    • route: ルートを追加します。
      • cidr_block = "0.0.0.0/0": インターネット宛 (全ての宛先) のトラフィックを指定します。
      • nat_gateway_id = aws_nat_gateway.nat_gateway.id: インターネット宛のトラフィックをNAT Gatewayにルーティングするように指定します。
    • tags: リソースにタグを付与します。
  4. aws_route_table_association "private_subnet": 作成したルートテーブルをプライベートサブネットに関連付けます。
    • subnet_id: プライベートサブネットのIDを指定します。
    • route_table_id: 作成したルートテーブルのIDを指定します。

実務レベルの内容 (NAT Gateway):

実務レベルでは、上記の基本的なコードに加えて、以下の点を考慮する必要があります。

  • 変数 (variable) の使用: VPC ID、サブネットID、AZ名、タグ名などを変数として定義し、コードの再利用性と可読性を向上させます。
  • モジュール (module) の使用: NAT Gatewayの作成処理をモジュール化することで、コードの再利用性と保守性を高めます。
  • 複数AZへの展開: 可用性を考慮して、複数のAZにNAT Gatewayをデプロイ する構成が推奨されます。count メタ引数や for_each 構文を使用して、複数AZにNAT Gatewayを効率的に作成できます。
  • タグ (tags) の適切な設定: リソースに適切なタグを設定することで、リソースの管理、コスト分析、自動化処理などを容易にすることができます。
  • depends_on の適切な使用: リソース間の依存関係を明示的に記述することで、Terraformの実行順序を制御し、予期せぬエラーを回避できます。特に複雑な構成の場合、depends_on の適切な使用が重要になります。
  • 出力 (output) の定義: 作成したリソースの情報 (例: NAT Gateway ID, EIPアドレス) を出力として定義することで、他のTerraformモジュールや外部システムから参照しやすくすることができます。

実務レベルのTerraformコード例 (複数AZ対応):

variable "vpc_id" {
  type = string
  description = "VPC ID"
}

variable "public_subnet_ids" {
  type = list(string)
  description = "パブリックサブネット IDs (AZごとに一つ)"
}

variable "private_subnet_ids" {
  type = list(string)
  description = "プライベートサブネット IDs (AZごと)"
}

variable "azs" {
  type = list(string)
  description = "Availability Zones"
}

resource "aws_eip" "nat_gateway" {
  count = length(var.azs) # AZの数だけEIPを作成
  vpc   = true
  tags = {
    Name = "nat-gateway-eip-${var.azs[count.index]}"
  }
}

resource "aws_nat_gateway" "nat_gateway" {
  count         = length(var.azs) # AZの数だけNAT Gatewayを作成
  allocation_id = aws_eip.nat_gateway[count.index].id
  subnet_id     = var.public_subnet_ids[count.index] # AZに対応するパブリックサブネット
  tags = {
    Name = "nat-gateway-${var.azs[count.index]}"
  }
}

resource "aws_route_table" "private_subnet" {
  for_each = toset(var.private_subnet_ids) # プライベートサブネットごとにルートテーブルを作成
  vpc_id   = var.vpc_id

  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.nat_gateway[index(var.private_subnet_ids, each.key)].id # 対応するAZのNAT Gateway
  }

  tags = {
    Name = "private-subnet-route-table-${each.key}"
  }
}

resource "aws_route_table_association" "private_subnet" {
  for_each       = toset(var.private_subnet_ids) # プライベートサブネットごとにルートテーブルを関連付け
  subnet_id      = each.key
  route_table_id = aws_route_table.private_subnet[each.key].id
}

output "nat_gateway_ids" {
  value = aws_nat_gateway.nat_gateway[*].id
  description = "NAT Gateway IDs"
}

output "nat_gateway_eip_addresses" {
  value = aws_eip.nat_gateway[*].public_ip
  description = "NAT Gateway EIP Addresses"
}

コードの説明 (実務レベル例):

  • 変数定義: variable ブロックを使用して、VPC ID、サブネットIDリスト、AZリストなどを変数として定義しています。
  • count と for_each の使用: count メタ引数と for_each 構文を使用して、複数AZにNAT GatewayとEIPを効率的に作成しています。
  • AZ対応: count.index や each.key を使用して、各リソースをAZごとに関連付けています。
  • 出力定義: output ブロックを使用して、NAT Gateway ID と EIPアドレスを出力しています。

まとめ:

TerraformでNAT Gatewayを記述する場合、基本的にはシンプルなコードで作成できますが、実務レベルでは、可用性、再利用性、可読性、保守性 を考慮したコードを書くことが重要です。変数、モジュール、複数AZ対応、タグ、depends_on、出力などを適切に活用することで、より堅牢で運用しやすいインフラ基盤を構築できます。

Discussion