AWSセキュリティグループの設定方法とは？インバウンド・アウトバウンドの違いとよくある間違いを解説

AWSのEC2を構築したものの、「外部から接続できない」「セキュリティグループの設定手順がよくわからない」と悩んでいませんか。セキュリティグループは、AWS上の仮想サーバーを守る非常に大切なファイアウォール機能です。しかし、「インバウンド」と「アウトバウンド」の違いや、適切なIP制限ルールを知らないまま設定すると、意図しない接続エラーや深刻なセキュリティリスクを引き起こす原因になります。本記事では、AWSセキュリティグループの基礎知識からコンソールでの具体的な設定手順、よくある設定ミスとその解決法まで分かりやすく解説します。正しく安全なルール設定をマスターし、安心してインフラ構築を進めましょう。

AWSのセキュリティグループとは？役割と基本の仕組み

セキュリティグループの概要と「仮想ファイアウォール」としての役割

AWSのセキュリティグループは、EC2インスタンスなどのリソースに対する通信を制御する仮想ファイアウォール機能です。ネットワークの入り口と出口で通過できる通信を監視し、指定した条件に合致するアクセスのみを通します。

身近な例で考えると、マンションのオートロックシステムに似ています。建物（AWSネットワーク）全体ではなく、各部屋（個々のEC2インスタンス）の玄関前に警備員が立ち、許可証を持っている訪問者だけを通すような仕組みです。正確にはEC2インスタンスにアタッチされた「ネットワークインターフェース（ENI）」単位で動作し、インスタンスごとに細かなアクセス制御を行えます。

新規作成したデフォルトの状態では、外部からの進入を試みる通信（インバウンド）はすべて拒否されます。一方で、内部から外部へ向かう通信（アウトバウンド）は全許可に設定されているのが特徴です。必要な通信だけを明示的に「許可」するルールを追加しなければ、外部からの接続は一切届きません。

インバウンドルールとアウトバウンドルールの違い

セキュリティグループにおける通信制御は、「インバウンド」と「アウトバウンド」という2つの方向で独立して設定します。

・インバウンド（入ってくる通信）：外部からEC2インスタンスへ向かうトラフィック
・アウトバウンド（出ていく通信）：EC2インスタンスから外部へ向かうトラフィック

例えばWebサーバーを運用する場合、一般のユーザーがWebサイトを閲覧するために送るリクエストは「インバウンド通信」に該当します。このアクセスを許可するには、インバウンドルールにWeb通信用の設定が必要です。

対して、サーバー自体がOSのアップデート用パッチを取得したり、外部の決済API等へデータを送信したりする動作は「アウトバウンド通信」となります。どちらの向きの通信制御であるかを明確に意識してルールを整理することが重要と言えるでしょう。

知っておくべき「ステートフル」機能の特徴

セキュリティグループの最も大きな技術的特徴は、「ステートフル」である点です。ステートフルとは、通信の状態（ステート）を自動的に記憶・管理する仕組みを指します。

インバウンドルールで許可されたアクセスであれば、その応答（戻りの通信）はアウトバウンドルールの設定に関わらず自動的に許可されます。Webサイトへのリクエストを受け取った際、そのレスポンスを返すためのアウトバウンドルールを別途設ける必要はありません。

AWSには似た機能としてサブネット単位で動作する「ネットワークACL（NACL）」が存在しますが、こちらは「ステートレス」な仕様です。ステートレスでは行きと帰りの両方で明示的な許可ルールが必要になるため、両者の挙動の違いをしっかり押さえておきましょう。

AWSマネジメントコンソールでのセキュリティグループ基本設定手順

ステップ1：セキュリティグループの新規作成と基本情報の入力

AWSマネジメントコンソールでセキュリティグループを作成する際は、VPCダッシュボードから操作を行います。画面左側のナビゲーションペインから「セキュリティグループ」を選択し、「セキュリティグループを作成」をクリックしてください。

画面が切り替わったら、基本情報として「セキュリティグループ名」「説明（Description）」「VPC」を入力します。名前や説明欄には、後から参照した際に役割をひと目で識別できる命名規則を取り入れるようおすすめします。例えば「web-prod-sg」のように、環境と目的を明記しておくと運用上のトラブルを未然に防げるでしょう。VPCはリソースを配置する対象のネットワークを確実に指定することが重要です。

ステップ2：インバウンドルールの追加とポート番号・ソースの設定

基本情報の入力に続いて、必要なアクセスを許可するためのインバウンドルールを設定します。「インバウンドルール」のセクションにある「ルールを追加」ボタンをクリックし、通信の種類や制限範囲を個別に指定していきましょう。

設定時には、タイプ（プロトコル）、ポート範囲、ソース（接続元）の3項目を正しく選択する必要があります。ウェブサーバーやリモート接続で頻繁に使用される代表的な設定値を以下の表にまとめました。

用途	タイプ	プロトコル	ポート範囲	ソースの設定例
Web接続（HTTP）	HTTP	TCP	80	Custom / 0.0.0.0/0
暗号化Web接続（HTTPS）	HTTPS	TCP	443	Custom / 0.0.0.0/0
Linuxリモート接続	SSH	TCP	22	My IP（管理者IP）
Windowsリモート接続	RDP	TCP	3389	My IP（管理者IP）

不必要なポートを開放すると攻撃の標的になりやすいため、用途に応じた最小限のルールに留める意識が不可欠と言えます。

ステップ3：アウトバウンドルールの確認と変更

インバウンドルールの設定が終わったら、アウトバウンドルールの状態を確認しましょう。セキュリティグループの新規作成時には、デフォルトで「すべてのトラフィック（0.0.0.0/0）」を外部へ許可するルールが適用されています。

一般的なWebサーバーやアプリケーションサーバーの運用であれば、このデフォルト設定のままで運用しても問題ありません。インスタンスから外部のAPIへ接続したりセキュリティパッチをダウンロードしたりする通信がスムーズに行えるためです。

ただし、金融システムや機密データを扱う環境など厳格なセキュリティが求められる場合は、宛先IPやポートを限定するカスタマイズを検討してみてください。用途に合わせた制御を行うことで、万が一のマルウェア感染時における外部への情報流出リスクを低減できます。

セキュリティグループ設定でよくある間違いとセキュリティリスク

「0.0.0.0/0」を全許可することの危険性と「マイIP」指定の重要性

ネットワーク設定で最も回避すべきミスは、アクセス制御の送信元（ソース）に CIDR 表記の「0.0.0.0/0」を安易に指定してしまう状況です。0.0.0.0/0 という記述は、インターネット上のあらゆる IP アドレスからの接続を許可することを意味します。

特に SSH（22番）や RDP（3389番）といったサーバー管理用ポートを 0.0.0.0/0 に設定すると、世界中の無差別ポートスキャンやブルートフォース攻撃（総当たり攻撃）に晒されるリスクが高まります。意図しない不正アクセスやマルウェア感染を引き起こす原因になりかねません。

安全な運用を実現するためには、管理者のアクセス元を限定する「マイIP」機能や、特定の IP アドレス（例：xxx.xxx.xxx.xxx/32）の指定が有効です。AWS マネジメントコンソールのソース選択で「マイIP」を選ぶと、現在接続しているパブリック IP のみが自動でセットされ、関係者以外の不要なアクセスを遮断できます。

ポート番号の誤設定による接続不可エラー

セキュリティグループの設定で頻発するのが、必要なポートの開放漏れや誤指定による通信障害です。

例えば、Web サーバーを立ち上げたにも関わらず、インバウンドルールに HTTP（80番）や HTTPS（443番）が含まれていない場合、外部ブラウザからのアクセスはタイムアウトエラーになります。「カスタム TCP」を選択して独自のポート番号を指定する際にも、想定と異なる数字を入力してしまうトラブルが少なくありません。

接続トラブルが起きた際は、稼働しているアプリケーションが使用する通信プロトコルと、セキュリティグループのポート範囲が合致しているか確認してみてください。不要なポートを開けず、必要なポートだけを開ける適切な管理が求められます。

ソース指定で「他のセキュリティグループID」を活用していない

IP アドレスによる直接制限だけでなく、他のセキュリティグループ ID（sg-xxxxxxxx）をソースとして指定できる仕組みの活用も重要です。

Web サーバーとデータベース（DB）サーバーで構成されるシステムを例に考えてみましょう。DB サーバー側のセキュリティグループで、Web サーバー用のセキュリティグループ ID からのアクセスのみを許可する設定を行います。こうすることで、Web サーバー層を経由しない直接の DB アクセスを完全に防ぐ多層防御が成立するわけです。

この手法を用いれば、オートスケーリング等で Web サーバーの IP アドレスが動的に変わる環境でも、ルールを都度書き換える必要がありません。IP の変更に影響されない柔軟かつ強固な運用体制を構築できる点も大きなメリットと言えるでしょう。

AWSで「接続できない」時の初心者向けトラブルシューティング

セキュリティグループ設定のチェックリスト

設定を見直してもEC2インスタンスへ接続できない場合、まずはセキュリティグループの記述に問題がないか順番に点検しましょう。エラーの多くは基本的な設定ミスによって発生します。

トラブル時に確認すべき基本的なチェックポイントは以下の通りです。

・正しいセキュリティグループが対象のEC2にアタッチされているか
・許可したポート番号と通信プロトコル（TCP/UDP等）に相違はないか
・ソースIPアドレスの記述に誤りがないか（自身のパブリックIP変更を含む）

特に自宅やオフィスのルーターが再起動すると、プロバイダから割り当てられるパブリックIPアドレスが変わるケースがあります。昨日まで接続できていたにもかかわらず急にアクセスできなくなった際は、現在のIPアドレスを調べた上でセキュリティグループのソースを更新してみてください。

また、セキュリティグループ以外のネットワーク要因が影響している可能性も視野に入ります。ルートテーブルでインターネットゲートウェイへのルートが設定されているか、あるいはサブネット単位のネットワークACLで通信が遮断されていないかもあわせて確認すると原因特定がスムーズになります。

まとめ

AWSのセキュリティグループは、EC2インスタンスなどのリソースを守る重要な仮想ファイアウォールです。

運用の要となるのは、「インバウンド」と「アウトバウンド」の通信方向を正しく理解し、応答通信が自動許可される「ステートフル」の特性を把握することと言えます。これらの基本原理を理解しておくことで、無駄なルールの重複や設定ミスを大幅に減らせるでしょう。

また、設定時は「0.0.0.0/0」による全開放を避け、管理者自身の「マイIP」や「セキュリティグループID」を活用した最小制限を徹底してください。アクセスを制限すべき通信と許可すべき通信を明確に分ける姿勢が、安全なクラウド環境の構築に繋がります。

正しい設定手順とトラブルシューティングのポイントを押さえ、安全かつスムーズなAWS運用を進めていきましょう。