TerraformでAWS NAT Gatewayを完全攻略！インスタンスとの使い分けと設定

TerraformによるAWS NAT Gateway構築の全体像と最適ルート

NAT Gatewayの基本とTerraform活用のメリット

AWS NAT Gatewayは、プライベートサブネット内のリソースがインターネットや他のAWSサービスへ安全にアウトバウンド通信を行うための、AWSが提供するフルマネージドサービスです。本番環境での利用が強く推奨される理由は、その高い可用性（99.99%）と、スケーリング、パッチ適用といった運用管理の手間が一切不要である点にあります。これにより、インフラ担当者はより本質的な開発業務に集中できます。

このNAT Gatewayの構築と管理にTerraformを活用することで、インフラ設定をコードとして定義し、バージョン管理システム（Gitなど）で管理することが可能になります。これにより、インフラの再現性が保証され、変更履歴の追跡が容易になり、チーム間での協調作業もスムーズに進められます。コードとしてインフラを扱うことで、ヒューマンエラーのリスクを低減し、デプロイの信頼性を飛躍的に向上させることが期待できます。

Terraformを使用する最大のメリットは、インフラの「あるべき状態」をコードで定義し、その状態への移行を自動化できる点です。手動での設定では見落としがちな依存関係や複雑な設定も、コードで明示的に記述することでミスを防ぎ、将来的な変更や拡張にも柔軟に対応できるようになります。

高可用性を実現するNAT Gatewayの設計原則

AWS環境で高可用性を確保するNAT Gatewayの設計では、AWSのベストプラクティスに従い、各アベイラビリティゾーン（AZ）に個別のNAT Gatewayを配置することが基本です。この設計により、特定のAZに障害が発生した場合でも、他のAZのNAT Gatewayを通じて通信経路を確保できます。各NAT Gatewayは、必ずパブリックサブネットに配置し、専用のElastic IPアドレスを割り当てる必要があります。

重要なのは、プライベートサブネットからのデフォルトルート（`0.0.0.0/0`）を、そのプライベートサブネットと同一AZに存在するNAT Gatewayに向けることです。このルーティング戦略を徹底することで、NAT Gatewayと異なるAZにあるリソースとの通信で発生する「Cross-AZデータ転送料金」を回避し、コストを最適化できます。具体的には、`ap-northeast-1a`のプライベートサブネットは`ap-northeast-1a`のNAT Gatewayへ、`ap-northeast-1c`のプライベートサブネットは`ap-northeast-1c`のNAT Gatewayへとルーティングを設定します。これにより、インフラの堅牢性とコスト効率の両立が図られます。

この多AZ構成はTerraformで簡単に実現でき、コードでAZごとのNAT Gateway、Elastic IP、ルートテーブルを定義することで、手動設定の複雑さを解消し、一貫性のあるインフラを迅速にプロビジョニングすることが可能です。

コスト効率とセキュリティを考慮したルーティング戦略

NAT Gatewayは、その優れた機能性と共に、「稼働時間料金」と「データ処理料金」が発生します。特に大規模なデータ転送が発生する場合、このデータ処理料金が予想以上に高額になることがあります（東京リージョンでは、稼働時間料金0.062 USD/時間、データ処理料金0.062 USD/GB）。そのため、コスト最適化を考慮したルーティング戦略が不可欠です。

コスト削減と通信の高速化を実現する最も効果的な方法は、Amazon S3やAmazon DynamoDBといったAWSの主要サービスへのアクセスに、NAT Gatewayを経由せずVPCエンドポイントを利用することです。特にゲートウェイ型VPCエンドポイントは無料で利用できるため、積極的に導入を検討すべきです。TerraformでVPCエンドポイントをプロビジョニングし、ルートテーブルを適切に設定することで、特定のAWSサービスへのトラフィックをVPCエンドポイントへ、それ以外のインターネット向けトラフィックをNAT Gatewayへ向けるルーティングを実現できます。

このルーティング戦略は、不要なデータ処理コストを削減するだけでなく、AWS内部ネットワークを介した安全で高速な通信を可能にし、セキュリティの向上にも寄与します。多層防御の観点からも、サブネットごとのセキュリティグループやネットワークACL（NACL）と組み合わせることで、より堅牢なセキュリティ体制を構築することが重要です。

出典：Amazon VPC NAT Gateway ドキュメント、Amazon VPC の料金

AWS NAT GatewayをTerraformで構築する詳細ステップ

VPCとサブネットのTerraform定義

NAT Gatewayを構築する最初のステップは、その土台となるVPCとサブネットをTerraformで定義することです。まず、`aws_vpc`リソースを使用してVPCを作成し、IPアドレス範囲（CIDRブロック）を指定します。例えば、`10.0.0.0/16`のような範囲を設定します。次に、`aws_subnet`リソースを複数定義し、パブリックサブネットとプライベートサブネットを作成します。パブリックサブネットはインターネットゲートウェイに関連付けられ、外部からの直接アクセスが可能なようにします。一方、プライベートサブネットはNAT Gateway経由でのみインターネットアクセスを許可するように設計します。

各サブネットには、そのAZを示すタグや、用途を明確にするタグ（例: `Name = “my-app-public-subnet-1a”`）を付与することで、管理が容易になります。特に、NAT Gatewayを配置するパブリックサブネットは、適切なルーティングとEIPの割り当てを考慮して設計することが重要です。この段階でVPCとサブネットの定義が適切でないと、後続のNAT Gatewayの構築やルーティング設定に影響が出るため、慎重な設計が求められます。

また、高可用性の観点から、複数のAZにまたがるサブネットを定義し、それぞれのAZにNAT Gatewayを配置できるように準備しておくことがベストプラクティスです。これにより、単一AZ障害時の影響を最小限に抑えることができます。

NAT GatewayとElastic IPのTerraformコード

VPCとサブネットの準備が整ったら、次にNAT GatewayとそのEIPをTerraformでプロビジョニングします。まず、`aws_eip`リソースを使って、NAT Gatewayに割り当てるための専用のElastic IPアドレスを一つ以上作成します。このEIPは、NAT Gatewayがインターネットと通信する際のエントリポイントとなります。Elastic IPは、リソースに関連付けられていなくても課金される場合があるため、不要になった場合は必ず解放するようにしましょう。

次に、`aws_nat_gateway`リソースを定義し、先ほど作成したElastic IPの`allocation_id`を`elastic_ip_allocation_id`属性に指定して関連付けます。NAT Gatewayは必ずパブリックサブネット内に配置する必要があるため、`subnet_id`には適切なパブリックサブネットのIDを指定します。例えば、`ap-northeast-1a`のNAT Gatewayは`ap-northeast-1a`のパブリックサブネットに配置します。

複数AZに対応する場合は、各AZのパブリックサブネットに対して個別の`aws_eip`リソースと`aws_nat_gateway`リソースを定義します。これにより、各AZに独立したNAT Gatewayが構築され、高可用性が確保されます。Terraformのループ機能などを使えば、このような繰り返し処理も効率的に記述できます。

ルートテーブルとルーティング設定の自動化

NAT Gatewayをプロビジョニングした後、最も重要なステップは、プライベートサブネットからのインターネット通信がNAT Gatewayを経由するようにルーティング設定を行うことです。まず、`aws_route_table`リソースを使って、各プライベートサブネット用のルートテーブルを作成します。このルートテーブルには、インターネットへのデフォルトルート（`0.0.0.0/0`）を定義し、そのターゲットとしてNAT Gatewayの`nat_gateway_id`を指定します。

重要なのは、各プライベートサブネットのルートテーブルが、そのサブネットと同一AZに存在するNAT Gatewayを指すように設定することです。例えば、`ap-northeast-1a`のプライベートサブネット用ルートテーブルは、`ap-northeast-1a`に構築されたNAT Gatewayをターゲットにします。この設定により、AZ間のデータ転送料金を回避し、コストを最適化できます。

最後に、`aws_route_table_association`リソースを使用して、作成したルートテーブルを対応する各プライベートサブネットに関連付けます。これにより、プライベートサブネット内のEC2インスタンスなどのリソースは、自動的にNAT Gatewayを経由してアウトバウンド通信を行うようになります。もしS3やDynamoDBなどAWSサービスへのアクセスにVPCエンドポイントを利用する場合は、別途VPCエンドポイントへのルートをルートテーブルに追加する必要があります。

NAT Instanceとの比較とセキュリティ設定の具体例

NAT GatewayとNAT Instanceの機能とコスト比較

AWSでプライベートサブネットからインターネットへのアウトバウンド通信を可能にする方法として、NAT GatewayとNAT Instanceの二つの選択肢があります。NAT GatewayはAWSが提供するフルマネージドサービスであり、高い可用性（99.99%）と広帯域幅を特徴とし、運用管理の手間が一切不要です。本番環境での利用が圧倒的に推奨されるのは、その安定性とスケーラビリティ、そして障害発生時の自動復旧能力にあります。

一方、NAT InstanceはEC2インスタンスを用いてユーザー自身がNATの機能を構築する方式です。これにより、EC2インスタンスの費用のみで運用できるため、特定の要件や厳格なコスト制約がある開発・検証環境では検討の余地があります。しかし、OSのパッチ適用、スケーリング、冗長化（Auto Scaling Groupなどによる）といった運用管理は全てユーザーの責任となり、運用負荷が大幅に増大します。また、NAT Gatewayと比較して可用性や帯域幅がインスタンスタイプに依存するため、大規模な本番環境には不向きです。

コスト面では、NAT Gatewayは「稼働時間料金」（東京リージョンで0.062 USD/時間）と「データ処理料金」（東京リージョンで0.062 USD/GB）が発生します。NAT InstanceはEC2インスタンスの費用のみですが、運用工数や障害対応のリスク、そして見えないコスト（人件費など）を考慮すると、本番環境においてはNAT Gatewayが結果的にコストパフォーマンスに優れるケースがほとんどです。

NAT GatewayにおけるセキュリティグループとNACL設定

NAT Gateway自体にはセキュリティグループを直接アタッチすることはできません。そのため、NAT Gatewayを経由する通信のセキュリティは、その前後のリソース（プライベートサブネット内のEC2インスタンスなど）にアタッチされたセキュリティグループと、サブネットレベルで機能するネットワークACL（NACL）によって実現します。

プライベートサブネット内のインスタンスにアタッチするセキュリティグループは、アウトバウンドルールで必要なポート（例: HTTP/Sの80, 443）をインターネット（`0.0.0.0/0`）へ許可し、インバウンドルールは極めて厳しく制限することが基本です。通常、内部からの通信への応答のみを許可するように設定します。

一方、NACLはサブネットレベルのステートレスなフィルタリング機能を提供し、より広範囲なセキュリティ層として機能します。パブリックサブネットにアタッチするNACLでは、NAT Gatewayに割り当てられたElastic IPからのインバウンド（応答トラフィック）を許可し、他の不必要な通信はブロックするルールを設定します。プライベートサブネットのNACLは、アウトバウンドでインターネットへの通信を許可し、インバウンドではNAT Gatewayからの応答を許可するよう設定します。セキュリティグループとNACLを組み合わせることで、多層防御を実現し、より堅牢なセキュリティ体制を構築できます。

NAT Instance利用時の追加セキュリティ設定

NAT Instanceを選択した場合、EC2インスタンスとしてのセキュリティ対策が必須となり、NAT Gatewayよりも多くの運用責任と設定が必要になります。NAT Instanceにアタッチするセキュリティグループは、プライベートサブネットからのアウトバウンドトラフィックと、インターネットへのアウトバウンドを許可するルールを設定します。また、SSHアクセスを制限するため、厳格なインバウンドルールを設定し、管理用IPアドレスからのアクセスのみを許可することが重要です。

さらに、NAT Instanceでは、EC2インスタンスが自身のIPアドレス以外からのトラフィックもルーティングできるようにするため、「送信元/送信先の変更チェック（Source/Destination Check）」を無効化する設定が必須です。この設定は、AWSマネジメントコンソールやTerraformの`aws_instance`リソースで`source_dest_check = false`を指定することで行います。

OSレベルでは、`iptables`などのファイアウォール設定を行い、不要なポートの開放を防ぎます。ユーザーがEC2インスタンスを管理するため、OSの定期的なパッチ適用、脆弱性診断、ログ監視なども運用フローに組み込む必要があります。これらの追加作業は運用負荷を大幅に増大させるため、NAT Instanceの採用は慎重に検討すべきでしょう。

出典：Amazon Virtual Private Cloud – NAT ゲートウェイ、AWS Well-Architected フレームワーク

TerraformでNAT Gatewayを管理する際の注意点と落とし穴

コスト増大を招くNGルーティングとVPCエンドポイントの活用

NAT Gatewayのコストは「稼働時間」と「データ処理量」の両方で発生するため、不適切なルーティング設定は予想外の高額請求につながる可能性があります。特に陥りやすい落とし穴の一つが、Amazon S3やAmazon DynamoDBといったAWSサービスへの通信が、NAT Gatewayを経由してしまうケースです。これらのAWSサービスへの通信は、AWSの内部ネットワークを通じて直接行うことが可能であり、NAT Gatewayを経由させる必要はありません。

このコスト増大を回避するための最も効果的な解決策は、VPCエンドポイント（特にゲートウェイ型は無料）を積極的に利用することです。Terraformでは`aws_vpc_endpoint`リソースを用いて、ターゲットとなるAWSサービスへのエンドポイントをプロビジョニングし、ルートテーブルにそのエンドポイントへのルートを追加します。これにより、対象のAWSサービスへのトラフィックはNAT Gatewayを迂回し、VPCエンドポイント経由で直接通信するようになります。

この設定を行うことで、NAT Gatewayのデータ処理量を大幅に削減し、コストを最適化できます。ルーティング設定を見直す際は、`terraform plan`コマンドでルートテーブルの変更内容を十分に確認し、AWSサービスへのトラフィックが適切にVPCエンドポイントに向いていることを確認することが重要です。

Cross-AZ通信による追加料金とその回避策

NAT Gatewayを管理する上で注意すべきもう一つの落とし穴は、Cross-AZ（AZ間）通信による追加料金です。NAT Gatewayと異なるアベイラビリティゾーン（AZ）にあるリソースが通信を行うと、AWSのAZ間データ転送料金が発生し、これが運用コストを増加させる要因となります。例えば、`ap-northeast-1a`のプライベートサブネットにあるインスタンスが、誤って`ap-northeast-1c`のNAT Gatewayを経由してインターネットにアクセスすると、AZ間データ転送料金が発生します。

この問題を回避するためには、設計段階で「同一AZ内のNAT Gateway」へルーティングする構成を徹底することが極めて重要です。Terraformでルートテーブルを定義する際、各プライベートサブネットに割り当てるルートテーブルは、必ずそのプライベートサブネットと同じAZに配置されたNAT Gatewayをデフォルトルート（`0.0.0.0/0`）のターゲットとして指定するように注意してください。

具体的には、`aws_route_table`リソースと`aws_route_table_association`リソースを使用して、AZごとにルーティングを厳密に分離します。この厳密なルーティング設定により、不要なAZ間データ転送料金を効果的に削減し、コストパフォーマンスの高いインフラ運用を実現できます。Terraformコードのレビュー時に、このAZ間ルーティングが正しく設定されているかを確認する習慣をつけましょう。

Terraformによる変更管理と状態管理のベストプラクティス

TerraformでNAT Gatewayのような重要なインフラリソースを管理する際には、Terraformの状態ファイル（`terraform.tfstate`）の適切な管理が不可欠です。状態ファイルは、Terraformが管理するリソースの現在の状態を記録しており、これが破損したり競合したりすると、予期せぬインフラの変更や障害を引き起こす可能性があります。チームでの共同作業やCI/CDパイプラインを組む場合、ローカルに状態ファイルを置くことは避けるべきです。

ベストプラクティスとして、S3バケットをリモートバックエンドとして利用し、DynamoDBによる状態ロックを組み合わせて使用することを強く推奨します。これにより、状態ファイルの破損や、複数のユーザーが同時に`terraform apply`を実行することによる競合を防ぐことができます。Terraformの`backend “s3″`ブロックでこの設定を行います。

また、`terraform plan`コマンドを常に実行し、変更内容を事前に確認する習慣を徹底することが重要です。これにより、意図しないリソースの作成、変更、削除を防ぎ、安定したインフラ運用に貢献します。NAT Gatewayのリソースを削除する際は、関連するElastic IPも忘れずに解放することで、不要な課金が発生しないように注意しましょう。

出典：Amazon VPC の料金、AWS Well-Architected フレームワーク

【ケース】予期せぬ変更による通信停止からの復旧と学び

（架空のケース）ルーティング変更が引き起こした通信障害

ある日、架空の企業「クラウドテック株式会社」のシステム担当者が、TerraformでNAT Gatewayのルーティング設定を最適化しようとしました。彼は、既存のルートテーブルにVPCエンドポイントへのルートを追加する変更を計画していましたが、その過程で誤ってプライベートサブネットのデフォルトルート（`0.0.0.0/0`）を削除してしまい、`terraform apply`を実行してしまいました。

この変更により、数分後にはプライベートサブネット内のEC2インスタンスからインターネットへのアクセスが完全に遮断され、そのインスタンスで稼働していたウェブアプリケーションが外部APIとの連携ができなくなりました。当初、担当者は変更の範囲が小さいと考えていたため、`terraform plan`の出力結果を十分に確認していませんでした。数時間後、ユーザーからの「サービスが利用できない」という問い合わせや、監視システムからの外部通信エラーアラートにより、大規模な通信障害が発生していることが判明しました。これにより、クラウドテック株式会社のサービスは一時的に利用できなくなり、緊急での対応が求められる状況に陥りました。

このケースは、Terraformによるインフラ変更の事前検証の重要性と、`terraform plan`コマンドによる変更内容の詳細確認がいかに不可欠であるかを浮き彫りにしています。

障害発生時の迅速な特定と復旧手順

通信障害が発生した場合、まず疑うべきはVPCのルートテーブル設定です。クラウドテック株式会社のケースでは、担当者はまずAWSマネジメントコンソールにログインし、問題が発生しているプライベートサブネットに紐づくルートテーブルを確認しました。そこで、本来存在すべきデフォルトルート（`0.0.0.0/0`）が欠落していることを発見しました。

迅速な復旧のためには、まずTerraformのバージョン管理システム（Gitなど）から、障害発生前の正しい状態のTerraformコードを特定することが重要です。該当のルートテーブル定義を確認し、欠落していたデフォルトルート（NAT Gatewayをターゲットとする）を追加する修正を行いました。その後、再度`terraform plan`で変更内容が意図通りであることを確認し、`terraform apply`を実行して、正しいルーティング設定をデプロイしました。

もしTerraformでの即時復旧が難しい緊急事態であれば、一時的にAWSマネジメントコンソールから手動でルートを追加し、通信を回復させることも選択肢の一つです。しかし、手動での変更はTerraformの状態ファイルとの乖離（ドリフト）を招くため、必ずその後Terraformコードを修正し、`terraform plan`/`apply`でインフラの状態とコードを一致させる作業を行う必要があります。

再発防止策とTerraform運用改善のための学び

クラウドテック株式会社は、この経験から以下の重要な教訓を得て、再発防止策を策定しました。

• コードレビューの義務化: 全てのTerraformコード変更は、`terraform plan`の出力結果を含め、複数人による厳格なレビュープロセスを経ることを義務付けました。特に、ルートテーブルのような基幹インフラへの変更は、より慎重な確認体制を敷きました。
• ステージング環境での検証: 本番環境へのデプロイ前に、実際のトラフィックに近い条件でステージング環境で十分に検証を行うフローを確立しました。これにより、設定変更による影響を事前に把握できるようになりました。
• 監視体制の強化: NAT Gatewayのメトリクス（例: `BytesOutToSource`、`PacketsDropCount`）や、プライベートサブネットからのインターネットアクセス状況を継続的に監視するツールを導入しました。これにより、異常を早期に検知し、迅速な対応が可能となりました。
• Terraform状態ファイルの厳格な管理: S3バケットとDynamoDBによるリモートバックエンドと状態ロックを徹底し、偶発的な状態ファイルの変更や競合を防ぐ仕組みを強化しました。

この一連の取り組みにより、インフラ変更におけるリスク管理が強化され、より堅牢なデプロイパイプラインの構築が進められました。インフラの変更は常にサービス停止のリスクを伴うため、これらのベストプラクティスを組織全体で共有し、徹底することが不可欠です。

出典：AWS Well-Architected フレームワーク