【ITニュース解説】My VPC Journey: Hosting a Website in a Multi-AZ Production Environment

ウェブサイトを本番環境で公開する際、単にサーバーを起動するだけでは不十分だ。ネットワークの設計、ルーティング、ゲートウェイ、そして厳重なセキュリティ制御が、アプリケーションの安定性や安全性を左右する。ここでは、実際にマルチAZ（アベイラビリティゾーン）構成のAWS VPC環境でウェブサイトをホスティングするプロセスを通じて学んだ、クラウドネットワーキングの具体的な手順と概念を解説する。

まず、AWSクラウド上に仮想ネットワーク空間であるVPC (Virtual Private Cloud) を作成する。VPCは、ユーザーが完全に制御できる隔離されたネットワーク環境を提供し、IPアドレス範囲 (CIDR 10.0.0.0/16など) を指定して設定する。このVPC内に、さらに細かいネットワーク区画であるサブネットを複数作成する。ウェブサイトの可用性を高めるため、複数のアベイラビリティゾーン（地理的に離れた独立したデータセンター群）にまたがる形で、パブリックサブネットとプライベートサブネットをそれぞれ2つずつ配置する。例えば、AZ1にパブリックサブネットとプライベートサブネットを一つずつ、AZ2にも同様に一つずつ配置する。これは、あるAZに障害が発生しても、別のAZでサービスを継続できるようにするためだ。

サブネットは初期設定ではインターネットに接続できない「プライベート」な状態にある。インターネットと直接通信が必要なサーバーを配置するパブリックサブネットをインターネットに公開するためには、VPCにインターネットゲートウェイ (IGW) をアタッチする必要がある。IGWはVPCとインターネット間の通信を可能にする出入口の役割を果たす。そして、パブリックサブネット用の「ルートテーブル」を作成し、全てのインターネット宛てのトラフィック (0.0.0.0/0) をIGWへ向かうように設定し、このルートテーブルをパブリックサブネットに関連付ける。さらに、パブリックサブネット内のインスタンスが自動的にパブリックIPアドレスを割り当てられるように設定も必要だ。これにより、パブリックサブネット内のサーバーはインターネットと直接通信できるようになる。安定したサービス運用のためには、変動しない固定のパブリックIPアドレスであるElastic IPを割り当てることが推奨される。

次に、プライベートサブネットに配置するサーバー（例えばデータベースサーバーやアプリケーションサーバーのバックエンド）からはインターネットに出ていく必要があるが、外部からは直接アクセスされたくないという要件がある。このような場合に利用するのがNATゲートウェイだ。NATゲートウェイはパブリックサブネット内に配置する必要があり、ここでも固定のElastic IPを割り当てて安定した接続を確保する。プライベートサブネット用のルートテーブルを作成し、全てのインターネット宛てのトラフィック (0.0.0.0/0) をNATゲートウェイへ向かうように設定し、このルートテーブルをプライベートサブネットに関連付ける。NATゲートウェイは、プライベートなサーバーからのアウトバウンド通信を仲介し、その返りのトラフィックはプライベートなサーバーへ届けるが、外部からプライベートなサーバーへの未承諾のインバウンド接続は遮断する。これにより、プライベートサブネット内のサーバーは安全にインターネットにアクセスできるようになる。

プライベートサブネット内のサーバーにSSH（セキュアシェル）で接続して管理する場合、直接インターネットに公開するのはセキュリティ上のリスクが高い。そこで、踏み台ホスト (Bastion Host) を利用する。踏み台ホストはパブリックサブネットに配置し、インターネットからのSSH接続を許可する唯一の入口として機能させる。この踏み台ホストはセキュリティが強化されたOSイメージ (CIS-hardened AMIなど) を使用し、そのセキュリティグループ（仮想ファイアウォール）では、SSH (tcp/22) のインバウンドアクセスを管理者自身の特定のIPアドレスからのみ許可するように厳しく制限する。踏み台ホストからプライベートインスタンスへのSSH接続は、踏み台ホストのセキュリティグループがプライベートインスタンスのセキュリティグループへのSSH通信を許可することで実現する。この際、SSHのProxyJump機能を使って、踏み台ホストを経由してプライベートインスタンスに安全に接続できる。重要なキーファイルなどの転送にもProxyJumpを伴うSCPコマンドが利用できる。アクセスに使用するSSHキーは厳重に保護し、不要な監視を有効にして不正なアクセス試行を検知することも重要だ。

ウェブサイトのアプリケーションサーバーは、先ほど説明したプライベートサブネット内に配置し、直接インターネットに公開しない。代わりに、Application Load Balancer (ALB) を使用して、外部からのウェブトラフィックをアプリケーションサーバーに振り分ける。ALBは両方のパブリックサブネットにデプロイし、ウェブサイトへのリクエスト（例えばHTTPポート80）を受け付けるように設定する。ALBは受け取ったリクエストを、プライベートサブネット内の複数のアプリケーションサーバーに分散して転送する。この際、ALBとアプリケーションサーバーの間は、アプリケーションサーバーの特定のポート（例えばポート8080）で通信するように設定する。ALBのセキュリティグループはインターネットからのHTTPポート80のアクセスを許可し、アプリケーションサーバーのセキュリティグループはALBのセキュリティグループからのポート8080のアクセスのみを許可するように設定することで、厳密な通信経路を確立する。ALBはアプリケーションサーバーの稼働状況を定期的にチェックするヘルスチェック機能も備えており、異常のあるサーバーを自動的にトラフィックの振り分け対象から外し、健全なサーバーにのみリクエストを送ることで、サービスの継続性を保つ。

ネットワーク内のサーバーは、IPアドレスだけでなく、名前で互いを認識できると管理がしやすくなる。VPCの設定でDNSホスト名とDNS解決を有効にすることで、プライベートインスタンスは ip-10-0-3-5.ec2.internal のような内部DNS名で互いに名前解決できるようになる。さらに、外部からウェブサイトにアクセスするためのカスタムドメイン名（例: example.com）を、AWSのDNSサービスであるRoute 53でALBのDNS名にマッピングすることで、ユーザーは分かりやすいURLでウェブサイトにアクセスできるようになる。

最後に、AWSを使い始めたばかりの時に自動で作成される「デフォルトVPC」については、削除せずにそのまま残しておくことが推奨される。一部のAWSサービスがバックグラウンドでこのデフォルトVPCに依存している場合があるため、不用意に削除すると予期せぬ問題が発生する可能性がある。

このようにして構築された環境は、複数のアベイラビリティゾーンにわたる高可用性、インターネットゲートウェイによる外部からのアクセス管理、NATゲートウェイによるプライベートなサーバーからの安全なインターネットアクセス、踏み台ホストによるセキュアな管理アクセス、ALBによる負荷分散と障害時の自動回復、そして最小権限の原則に基づいたセキュリティグループ設定という、本番環境レベルのセキュリティと安定性を備えている。各コンポーネントが連携し、ウェブサイトは安全かつ安定してユーザーに提供される。