カスタムVPC内でEC2インスタンスを安全に起動する方法
Amazon EC2インスタンスをAWSのデフォルトのパブリックネットワークに直接起動するのは迅速ですが、本番環境、ステージング環境、または機密性の高い環境では、不要なリスクを招きます。コンピューティングリソースを保護するには、それらをVirtual Private Cloud (VPC) —AWSクラウド内の論理的に隔離された独自のセクション— 内に隔離する必要があります。このガイドでは、カスタムVPCを設定し、サブネットやルートテーブルなどの必要なネットワークコンポーネントを定義し、厳格なセキュリティグループルールで保護されたEC2インスタンスを安全に起動するための重要な手順を説明します。
VPC設定を習得することは、堅牢でスケーラブルかつセキュアなAWSインフラストラクチャを構築するための基本です。ネットワーク境界を手動で定義することで、トラフィックフロー、IPアドレス指定、および外部接続をきめ細かく制御できるようになり、不正アクセスからアプリケーション環境を大幅に強化できます。
セキュアなVPCの主要コンポーネントを理解する
Virtual Private Cloud (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 サブネットを作成する
サブネットは高可用性のために特定のAvailability Zone (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つ、つまりパブリックサブネット用とプライベートサブネット用が必要です。
パブリックルートテーブル
このテーブルは、すべての非ローカルトラフィック (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インスタンスの仮想ファイアウォールとして機能します。これらはインスタンスレベルで動作し、ステートフルです (戻りトラフィックは自動的に許可されます)。
セキュアな設定のためには、最小権限の原則に従い、必要なインバウンドトラフィックのみを明示的に許可する必要があります。
ウェブサーバーのセキュリティグループの例 (プライベートサブネット)
この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 Machine Image (AMI) とハードウェア仕様を選択します。
- ネットワーク設定: 「インスタンスの詳細設定」ステップで、次のように設定します。
- ネットワーク: カスタムVPCを選択します。
- サブネット: インターネットに直接公開されるべきではないアプリケーションサーバーを起動する場合は、プライベートサブネット (
10.0.2.0/24) を選択します。 - パブリックIPの自動割り当て: プライベートサブネットに起動する場合は、これが無効になっていることを確認します。(パブリックサブネットを選択した場合は、踏み台ホストのように直接パブリックアクセスが必要なインスタンスに対してはこれを有効にすることができます)。
- セキュリティグループ: ステップ3で設定したセキュリティグループを選択します。
- ストレージとキーペア: ストレージを設定し、セキュアなSSHアクセスのためのキーペアを関連付けます。
プライベートサブネット内のインスタンスへのアクセス
プライベートサブネットにあるインスタンスにはパブリックIPアドレスがないため、パブリックインターネットから直接SSH接続することはできません。次の2つのセキュアな方法のいずれかを使用する必要があります。
- 踏み台ホスト (Jump Box): パブリックサブネットに小型で強化されたEC2インスタンスを起動します。まず踏み台ホストにSSH接続し、それから踏み台ホストからプライベートIPアドレスを使用してプライベートインスタンスにSSH接続します。
- AWS Systems Manager (SSM) Session Manager: これは推奨される最新の方法です。インスタンスにSSMエージェントがインストールされ、SSM接続を許可する適切なIAMロールがアタッチされている場合、インバウンドSSHルールや踏み台ホストを必要とせずに、AWSコンソールから直接セキュアなシェルセッションを開始できます。
まとめと次のステップ
カスタムVPC内でEC2インスタンスを保護するには、マクロレベル (VPC、サブネット、ルートテーブル) からミクロレベル (セキュリティグループ) まで、ネットワークセキュリティを多層的に構築する必要があります。IPアドレス指定とトラフィックフローを慎重に制御することで、次のことを実現します。
- アプリケーションサーバーが隔離されたプライベートサブネットに存在することを保証します。
- IGWまたはNATゲートウェイは必要な場合にのみ使用します。
- セキュリティグループのイングルールを介して最小権限の原則を適用します。
インスタンスが起動したら、AWS CloudTrailとVPCフローログを使用してアクティビティを監視し、プライベートネットワークトラフィックの継続的な可視性を維持することを忘れないでください。