カスタムVPC内でEC2インスタンスを安全に起動する方法

デフォルトVPCでAmazon EC2インスタンスを起動するのは迅速ですが、多くの場合、本番環境やステージング環境に必要な制御が不足します。カスタムVPCを使用すると、アドレス範囲を選択し、パブリックサブネットとプライベートサブネットを分割し、インターネットに到達するパスを正確に決定できます。

このガイドでは、実用的な安全なレイアウトを示します。ロードバランサーや踏み台ホスト用のパブリックサブネット、アプリケーションインスタンス用のプライベートサブネット、それらの役割に一致するルートテーブル、そして必要なトラフィックのみを許可するセキュリティグループです。

安全なVPCのコアコンポーネントを理解する

仮想プライベートクラウド（VPC）は、すべての安全なAWSネットワーキングの基盤です。インスタンスを起動する前に、以下のコンポーネントが正しく設定されていることを確認する必要があります。

VPC: ネットワークのメインコンテナであり、プライベートIPアドレス範囲（CIDRブロック）を定義します。
サブネット: VPC内の区分であり、パブリック（直接インターネットアクセスあり）またはプライベート（分離）に分類されます。
インターネットゲートウェイ（IGW）: パブリックサブネット内のリソースがインターネットと通信するために必要です。
ルートテーブル: サブネットからのネットワークトラフィックの転送先を決定するルール。
セキュリティグループ（SG）: インスタンスレベルでインバウンドおよびアウトバウンドトラフィックを制御するステートフルファイアウォール。

ステップ1: カスタムVPCとサブネットの作成

まず、ネットワークエンクロージャを作成し、機能領域に分割します。標準的な設定では、少なくとも1つのパブリックサブネットと1つのプライベートサブネットをお勧めします。

1.1 VPCの作成

VPCを作成する際は、後で接続する可能性のあるオンプレミスネットワーク（AWS VPNやDirect Connectなど）と重複しないプライベートCIDRブロックを選択します。

VPC CIDRの例: 10.0.0.0/16

1.2 サブネットの作成

各サブネットは1つのアベイラビリティーゾーン（AZ）に存在します。本番VPCは通常、少なくとも2つのAZにわたって一致するパブリックサブネットとプライベートサブネットを使用しますが、この例ではus-east-1aに1つのパブリックサブネットと1つのプライベートサブネットを持つ小さなレイアウトにしています。

パブリックサブネット: 10.0.1.0/24（踏み台ホストまたはロードバランサー用）
プライベートサブネット: 10.0.2.0/24（アプリケーションサーバーとデータベース用）

ステップ2: インターネット接続とルーティングの設定

プライベートサブネット内のリソースは、直接インターネットにアクセスできるべきではありません。パブリックサブネット内のリソースは、インターネットゲートウェイ（IGW）を介してインターネットに到達するために正しくルーティングされる必要があります。

2.1 インターネットゲートウェイ（IGW）のアタッチ

AWSコンソールでIGWリソースを作成します。
このIGWを新しく作成したVPCにアタッチします。

2.2 ルートテーブルの設定

ルートテーブルはトラフィックパスを定義します。少なくとも2つ必要です。1つはパブリックサブネット用、もう1つはプライベートサブネット用です。

パブリックルートテーブル

このテーブルは、すべての非ローカルトラフィック（0.0.0.0/0）をアタッチされたインターネットゲートウェイに転送します。

宛先	ターゲット
`10.0.0.0/16`（VPC CIDR）	`local`
`0.0.0.0/0`	`igw-xxxxxxxx`（IGW ID）

このルートテーブルをパブリックサブネット（10.0.1.0/24）に関連付けます。

プライベートルートテーブル

このテーブルは内部通信のみを許可します。重要なのは、IGWを指すルートが存在してはならないことです。

宛先	ターゲット
`10.0.0.0/16`（VPC CIDR）	`local`

このルートテーブルをプライベートサブネット（10.0.2.0/24）に関連付けます。

ベストプラクティス: プライベートサブネット内のリソースがパッチやアップデートをダウンロードする必要がある場合は、パブリックサブネットに配置されたNATゲートウェイを使用する必要があります。プライベートルートテーブルは、0.0.0.0/0トラフィックをIGWではなくNATゲートウェイに転送します。

ステップ3: 厳格なセキュリティグループルールの定義

セキュリティグループ（SG）は、EC2インスタンスの仮想ファイアウォールとして機能します。インスタンスレベルで動作し、ステートフル（戻りトラフィックは自動的に許可されます）です。

安全な設定では、最小権限の原則に従い、必要なインバウンドトラフィックのみを明示的に許可する必要があります。

Webサーバー（プライベートサブネット）のセキュリティグループの例

このEC2インスタンスが、パブリックサブネットにあるアプリケーションロードバランサー（ALB）からのみアクセス可能なアプリケーションサーバーである場合、ルールは非常に制限的であるべきです。

インバウンドルール

タイプ	プロトコル	ポート範囲	送信元
HTTP	TCP	80	ALBのSG ID
HTTPS	TCP	443	ALBのSG ID
SSH	TCP	22	企業ネットワークのIP範囲または踏み台ホストのSG ID

アウトバウンドルール

デフォルトでは、アウトバウンドトラフィックは通常、すべての宛先（0.0.0.0/0）に許可されます。必要に応じて、これをさらに制限できます（例：RDSインスタンスSGへの接続のみを許可する）。

セキュリティのヒント: パブリック向けセキュリティグループで、ポート22（SSH）またはポート3389（RDP）に0.0.0.0/0を割り当てないでください。管理アクセスは常に既知の内部IP範囲に制限してください。

ステップ4: EC2インスタンスの安全な起動

インスタンスを起動する際は、上記で確立した正しいネットワークコンポーネントにマッピングされていることを確認します。

AMIとインスタンスタイプの選択: 目的のAmazonマシンイメージ（AMI）とハードウェア仕様を選択します。
ネットワーク設定: 「インスタンスの詳細の設定」ステップで：
- ネットワーク: カスタムVPCを選択します。
- サブネット: アプリケーションサーバーを起動する場合で、インターネットに直接公開すべきでない場合は、プライベートサブネット（10.0.2.0/24）を選択します。
- パブリックIPの自動割り当て: プライベートサブネットに起動する場合は、無効にします。（パブリックサブネットを選択した場合、踏み台ホストなど直接パブリックアクセスが必要なインスタンスでは有効にできます）。
- セキュリティグループ: ステップ3で設定したセキュリティグループを選択します。
ストレージとキーペア: ストレージを設定し、安全なSSHアクセスのためにキーペアを関連付けます。

プライベートサブネット内のインスタンスへのアクセス

プライベートサブネットにあるインスタンスにはパブリックIPアドレスがないため、パブリックインターネットから直接SSH接続することはできません。次の2つの安全な方法のいずれかを使用する必要があります。

踏み台ホスト（ジャンプボックス）: パブリックサブネットに小さな堅牢なEC2インスタンスを起動します。最初に踏み台ホストにSSH接続し、その後踏み台ホストからプライベートIPアドレスを使用してプライベートインスタンスにSSH接続します。
AWS Systems Manager（SSM）セッションマネージャー: これは推奨される最新の方法です。インスタンスにSSMエージェントがインストールされ、SSM接続を許可する適切なIAMロールがアタッチされている場合、インバウンドSSHルールや踏み台ホストを必要とせずに、AWSコンソールから直接安全なシェルセッションを開始できます。

まとめと次のステップ

カスタムVPC内でEC2インスタンスを保護するには、マクロレベル（VPC、サブネット、ルートテーブル）からミクロレベル（セキュリティグループ）までネットワークセキュリティを階層化します。IPアドレッシングとトラフィックフローを注意深く制御することで：

アプリケーションサーバーが分離されたプライベートサブネットに配置されることを保証します。
必要な場合にのみIGWまたはNATゲートウェイを使用します。
セキュリティグループのイングレスルールを介して最小権限の原則を適用します。

インスタンスを起動したら、AWS CloudTrailとVPCフローログを使用してそのアクティビティを監視し、プライベートネットワークトラフィックへの継続的な可視性を維持することを忘れないでください。