この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
CDP（Cloud Design Pattern）ではOnDemand NATパターンをはじめとするインターネットアクセス（アウトバウンド）の解決法が提案されています。しかしながら、イントラネットとクラウドをVPN接続した環境では、一般にPrivate Subnetのデフォルトゲートウェイ（0.0.0.0/0）はプライベートアドレス空間のVPNゲートウェイに設定されているおり、単純にPrivate Subnetのデフォルトゲートウェイ（0.0.0.0/0）をNATインスタンスにルーティングできないケースも存在します。以降、インターネットアクセス（アウトバウンド）の課題に対する解決策・システムアーキテクチャ設計として、以下の４つのパターンを解説します。
インターネットアクセス（アウトバウンド）必要とされる背景
インターネットアクセス（アウトバウンド）は、以下の一般的な要件を鑑みると避けて通ることができません。 ・AWS Cloud EC2、S3などのPublicサービスとの連携 ・OSパッケージのアップデート（yum） ・時刻同期（NTP）
インターネットアクセス（アウトバウンド）が必要とされる構成
Multi-Serverパターンの構成
WebサーバーのフロントにELBを配置したシステム構成ではインターネットアクセス(アウトバウンド)の経路をそもそも持っていません。この場合はPublic Subnetに配置したNATインスタンスを経由するNATパターン/OnDemand NATパターンによる解決が一般的です。
イントラネットとVPCを接続したセキュアな構成
イントラネットとVPCを接続するセキュアな環境では、VPC内の各サーバーが無条件でインターネットへのアクセス（アウトバウンド）を禁止している構成が少なくありません。この場合は、これまでのNATインスタンスを経由する方式は採用できません。
NATインスタンスでは不十分であるか
具体例として、ここでは「AWS Cloud EC2、S3などのPublicサービスとの連携」が要件であると仮定して話を進めます。 Private SubnetのデフォルトゲートウェイがNATインスタンスに設定されており、送信先アドレスがグローバルアドレスでルーティング可能な場合はNATインスタンスを経由する方式でかまいません。一方、Private SubnetのデフォルトGWがVPNゲートウェイにルーティングする場合はProxyインスタンスを経由する方式となります。 ここでネットワーク技術者の方であれば、「Private SubnetのデフォルトゲートウェイがVPNゲートウェイに設定されている場合でも、NATインスタンスにスタティックルーティングすれば問題ないのでは？」という疑問が生じるでしょう。VPCのルーティングテーブルはホスト名ではなくDestinationにCIDRブロックやIDを指定してルーティングを設定します。AWSのPublicサービスはIPアドレスを特定できないのでスタティックルーティングによる解決ができません。
インターネットアクセス(アウトバウンド)のパターン
インターネットアクセス（アウトバウンド）は、NATインスタンス経由する方式とProxyサーバを経由する方式が２通りあり、さらに冗長化する否かに分けられます。
１．NATパターン/OnDemand NATパターン（NATインスタンス）
NATパターンはVPC Wizardの”VPC with Public and Private Subnets”で自動生成される最も代表的なパターンです。Private Subnetに配置した内部サーバーは、Public SubnetのNATインスタンスを経由して、インターネットアクセス（アウトバウンド）するパターンです。
※上記のウィザードで自動生成されるNATインスタンス（ami-vpc-nat-1.0.0-beta.i386-ebs (ami-12d86d13)）は古いのでパッケージのアップデートをお勧めします。
NATパターンの例を以下の図に示します。インバウンドリクエストはELBを経由してWeb serverに対して水平分散します。アウトバウンドリクエストは単一のNATインスタンスを経由してインターネットにアクセスします。Web serverが属するSubnetのルータのデフォルトゲートウェイ（0.0.0.0/0）はインスタンス"NAT1"を指定しています。NAT1のSecurity Groupの補足ですが、Inbound RuleにはWeb serverのSecurity Group（ID）を指定しています。AWSはルーティングやSecurity Groupの設定にCIDRはもちろん、インスタンス（ID）やSecurity Group（ID）を設定することができるので、煩雑なネットワーク設定を論理的に扱いヒューマンエラーを防止する仕組みがあることが特長です。
OnDemand NATパターンはNATインスタンスの常時稼働が不要なケースです。利用時間で課金されるAWSの強みを活かし、OSパッケージのアップデートなどのメンテンス時だけ起動するといった運用によってコスト効率を改善とセキュリティリスクを削減させるパターンです。ネットワークのCDPとして紹介されています。
参考資料： CDP:OnDemand NATパターン Chef：自前NATインスタンスを作ってみた（Amazon Linux 2014.03版）
NATパターン共通にいえることですが、長所はOSやサービスに変更が不要であることで、Publicサービスとの連携やパッケージアップデート等何も変更を加える必要がありません。短所はサブネットのデフォルトゲートウェイがVPNゲートウェイに設定している場合にアウトバンドしたいCIDRブロックが定まらないとルーティングできない点です。
２．High Availability NATパターン（冗長化されたNATインスタンス）
NATインスタンスの常時稼働が必要なケースです。Public SubnetのNAT1インスタンスに障害が発生した場合、スタンバイ状態の同様のNAT2インスタンスにルーティングのターゲットを変更することで透過的にフェイルオーバーするパターンです。CDP2.0候補として紹介されています。
High Availability NATパターンの例を以下の図に示します。インバウンドリクエストはELBを経由してWeb serverに対して水平分散します。障害発生/フェイルオーバー後のアウトバウンドリクエストは、NAT２インスタンスを経由してインターネットにアクセスします。
NATパターンの長所・短所に加えて、長所はフェイルオーバーによる冗長化構成が組めること。短所は障害検知やルーティングの動的切り替えには別途実装が必要であることです。
参考資料： CDP:High Availability NATパターン
３．Forward Proxyパターン（Proxyインスタンス）
Private Subnetに配置したWeb serverは、Public SubnetのProxy server(Squid等)を経由して、インターネットアクセス（アウトバウンド）するパターンです。Private SubnetのデフォルトゲートウェイがVPNゲートウェイに設定している場合もプライベートアドレス空間で外部接続が可能です。
Forward Proxyパターンの例を以下の図に示します。インバウンドリクエストはELBを経由してWeb serverに対して水平分散します。アウトバウンドリクエストは単一のProxyインスタンス(Squid)を経由してインターネットにアクセスします。
Forward Proxyパターン共通にいえることですが、長所は既存のルーティングに変更を加えずにインターネットアクセス（アウトバウンド）に対応できることやProxyサーバによる外部アクセスの制御やアクセスログの取得が可能であることです。短所はOSやサービス毎にProxy設定が必要であることです。なお、OnDemand NATパターンと同様にProxyインスタンスの常時稼働が不要な場合は、OnDemand Forward Proxyパターンとして運用してもかまいません。
参考資料： High Availability Forward Proxyパターンの構築
４．High Availability Forward Proxyパターン（冗長化されたProxyインスタンス）
Proxyインスタンスの常時稼働が必要なケースです。Internal-ELB + Proxyインスタンス + AutoScalingで構成されるProxyインスタンスの内部ロードバランス型の冗長化構成のパターンです。JAWS Days 2014の「AWSクラウドデザインパターン for Enterprise」のトラックで紹介されていました。Public SubnetのProxyインスタンスに障害が発生した場合、AutoScalingのメカニズムで障害検知し、系の切離しを自動化します。
High Availability Forward Proxyパターンの例を以下の図に示します。インバウンドリクエストはELBを経由してWeb serverに対して水平分散します。アウトバウンドリクエストはInternal-ELB(内部ロードバランサー)〜Proxyインスタンス(Squid)を経由してインターネットにアクセスします。
同じ冗長化構成であるHigh Availability NATパターンと比較して、冗長化方式がロードバランス型、障害検知・復旧がAWSが提供するマネジメントサービスを活かして実現されている点が優れています。OSやサービス毎にProxy設定が可能であり、冗長構成が組める予算があれば今回一押しの構成案です。
参考資料： High Availability Forward Proxyパターンの構築
時刻同期の方法
NATサーバはWeb serverが外部のNTPサーバーと直接通信することも可能ですが、Proxyサーバ（Squid）はNTPサービスを代理送信できません。そこで考えられるのはNATインスタンスやProxyインスタンスをNTPサービス（stratum3）動作させ、VPC内のEC2インスタンスのNTPサーバーとして利用する構成です。この構成の長所は同一VPCのNTPサーバーと時刻同期をすることによってVPC内の時刻精度が向上することです。但し、デフォルトのNTP設定は複数のNTPサーバーが設定されていますので、NTPサーバが冗長構成であることが前提となります。
最後に
セキュアにインターネットアクセス（アウトバウンド）を実現するサーバは、WebサーバやRDSなどと比較すると縁の下の力持ち的な存在ですが、AWSの強みを活かし安心・安全なネットワークを構成する上で重要なサーバです。セキュアなシステムではデフォルトGWをインターネットゲートウェイに設定することに警戒感を持たれることは少なくありません。NATインスタンスやProxyインスタンスを利用する方式と冗長化構成についてご紹介しましたが、どちらが優れているという訳ではなくそれぞれの長所・短所があります。上記では単一のアベイラビリティゾーン構成で解説しましたが、実際のネットワーク設計では複数のアベイラビリティゾーン構成で設計してください。