ネットワーク ACL を使用してサブネットへのトラフィックを制御する - Amazon Virtual Private Cloud

ネットワーク ACL を使用してサブネットへのトラフィックを制御する

ネットワークアクセスコントロールリスト (ACL) は、サブネットレベルで特定のインバウンドまたはアウトバウンドのトラフィックを許可または拒否します。VPC のデフォルトのネットワーク ACL を使用するか、セキュリティグループと同様のルールを使用して VPC のカスタムネットワーク ACL を作成し、セキュリティの追加レイヤーを VPC に追加できます。

ネットワーク ACL は追加料金なしで使用できます。

次の図は、2 つのサブネットを持つ VPC を示しています。各サブネットにはネットワーク ACL があります。トラフィックが (ピアリングされた VPC、VPN 接続、インターネットなどから) VPC に入ると、ルーターはこのトラフィックを宛先に送信します。ネットワーク ACL A は、サブネット 1 を宛先とするトラフィックのうち、サブネット 1 への送信を許可するトラフィックと、サブネット 1 以外を宛先とするトラフィックのうち、サブネット 1 からの送信を許可するトラフィックを決定します。同様に、ネットワーク ACL B は、どのトラフィックがサブネット 2 に出入りできるかを決定します。


      2 つのサブネットと各サブネットのネットワーク ACL を持つ VPC。

セキュリティグループとネットワーク ACL の違いについては、「セキュリティグループとネットワーク ACL を比較する」を参照してください。

ネットワーク ACL の基本

ネットワーク ACL について知っておく必要がある基本的な情報を以下に示します。

  • VPC には、変更可能なデフォルトのネットワーク ACL が自動的に設定されます。デフォルトでは、すべてのインバウンドおよびアウトバウンドの IPv4 トラフィックと、IPv6 トラフィック (該当する場合) が許可されます。

  • カスタムネットワーク ACL を作成して、それをサブネットに関連付けることで、サブネットレベルで特定のインバウンドトラフィックまたはアウトバウンドトラフィックを許可または拒否することができます。

  • VPC 内の各サブネットにネットワーク ACL を関連付ける必要があります。ネットワーク ACL に明示的にサブネットを関連付けない場合、サブネットはデフォルトのネットワーク ACL に自動的に関連付けられます。

  • ネットワーク ACL を複数のサブネットに関連付けることができます。ただし、サブネットは一度に 1 つのネットワーク ACL にのみ関連付けることができます。サブネットとネットワーク ACL を関連付けると、以前の関連付けは削除されます。

  • ネットワーク ACL には、インバウンドルールとアウトバウンドルールがあります。各ルールでは、トラフィックを許可または拒否できます。各ルールには 1 から 32,766 までの番号が設定されます。トラフィックを許可するか拒否するかを決定する際は、最も低い番号のルールから順にルールを評価します トラフィックがルールに一致すると、そのルールが適用され、追加のルールは評価されません。まずは増分 (例えば 10 または 100 の増分) でルールを作成することをお勧めします。こうすると、必要になったときに後で新しいルールを挿入できます。

  • ネットワーク ACL ルールは、トラフィックがサブネット内でルーティングされるときではなく、サブネットに出入りするときに評価されます。

  • NACL はステートレスです。つまり、以前に送受信されたトラフィックに関する情報は保存されません。例えば、サブネットへの特定のインバウンドトラフィックを許可する NACL ルールを作成しても、そのトラフィックへの応答は自動的には許可されません。これは、セキュリティグループの仕組みとは対照的です。セキュリティグループはステートフルです。つまり、以前に送受信されたトラフィックに関する情報が保存されます。例えば、セキュリティグループが EC2 インスタンスへのインバウンドトラフィックを許可している場合、アウトバウンドセキュリティグループのルールにかかわらず、レスポンスは自動的に許可されます。

  • ネットワーク ACL では、Route 53 Resolver (VPC+2 IP アドレスまたは AmazonProvidedDNS とも呼ばれます) で送受信される DNS リクエストをブロックすることはできません。Route 53 Resolver 経由の DNS リクエストをフィルターするために、「Amazon Route 53 デベロッパーガイド」にある「Route 53 Resolver DNS Firewall」を有効にすることができます。

  • ネットワーク ACL では、インスタンスメタデータサービス (IMDS) へのトラフィックをブロックすることはできません。IMDS へのアクセスを管理するには、「Amazon EC2 ユーザーガイド」の「インスタンスメタデータオプションの設定」を参照してください。

  • ネットワーク ACL では、以下で送受信されるトラフィックはフィルターされません。

    • Amazon ドメインネームサービス (DNS)

    • Amazon Dynamic Host Configuration Protocol (DHCP)

    • Amazon EC2 インスタンスメタデータ。

    • Amazon ECS タスクメタデータエンドポイント

    • Windows インスタンスのライセンスアクティベーション

    • Amazon Time Sync Service

    • デフォルトの VPC ルーターによる予約済み IP アドレス

  • VPC あたりのネットワーク ACL の数とネットワーク ACL あたりのルールの数には、クォータ (制限とも呼ばれます) があります。詳細については、「Amazon VPC クォータ」を参照してください。

ネットワーク ACL ルール

デフォルトのネットワーク ACL に対してルールの追加または削除を行うことができます。また、VPC に合わせて追加のネットワーク ACL を作成することができます。ネットワーク ACL に対してルールの追加または削除を行うと、変更内容は、その ACL に関連付けられているサブネットに自動的に適用されます。

次に、ネットワーク ACL ルールの一部を示します。

  • ルール番号。ルールは、最も低い番号のルールから評価されます。ルールがトラフィックに一致すると、それと相反するより高い数値のルールの有無にかかわらず、すぐに適用されます。

  • タイプ。トラフィックのタイプ(SSH など)。また、すべてのトラフィックまたはカスタム範囲を指定することもできます。

  • プロトコル。標準のプロトコル番号を持つ任意のプロトコルを指定できます。詳細については、「プロトコル番号」を参照してください。プロトコルとして ICMP を指定する場合、任意またはすべての ICMP タイプとコードを指定できます。

  • ポート範囲。トラフィックのリスニングポートまたはポート範囲。たとえば、HTTP トラフィックの場合は 80 です。

  • ソース: [インバウンドルールのみ] トラフィックの送信元 (CIDR 範囲)。

  • 送信先。[アウトバウンドルールのみ] トラフィックの送信先 (CIDR 範囲)。

  • 許可/拒否。指定されたトラフィックを許可する拒否するかを指定します。

コマンドラインツールまたは Amazon EC2 API を使用してルールを追加すると、CIDR 範囲は自動的に正規形式に変更されます。たとえば、CIDR 範囲に 100.68.0.18/18 を指定すると、100.68.0.0/18 の CIDR 範囲を持つルールが作成されます。

デフォルトのネットワーク ACL

デフォルトのネットワーク ACL は、すべてのトラフィックが、関連するサブネットを出入りすることを許可するように設定されます。各ネットワーク ACL には、ルール番号がアスタリスク (*) のルールも含まれます。このルールによって、パケットが他のいずれの番号のルールとも一致しない場合は、確実に拒否されます。このルールを変更または削除することはできません。

IPv4 のみをサポートする VPC のデフォルトネットワーク ACL の例を以下に示します。

インバウンド
ルール番号 タイプ プロトコル ポート範囲 送信元 許可/拒否

100

すべての IPv4 トラフィック

すべて

すべて

0.0.0.0/0

許可

*

すべての IPv4 トラフィック

すべて

すべて

0.0.0.0/0

DENY

アウトバウンド
ルール番号 タイプ プロトコル ポート範囲 送信先 許可/拒否

100

すべての IPv4 トラフィック

すべて

すべて

0.0.0.0/0

許可

*

すべての IPv4 トラフィック

すべて

すべて

0.0.0.0/0

DENY

IPv6 CIDR ブロックを持つ VPC を作成するか、IPv6 CIDR ブロックを既存の VPC と関連付ける場合は、すべての IPv6 トラフィックがサブネット間を流れるようにするルールが自動的に追加されます。また、ルール番号がアスタリスクのルールが追加されます。このルールにより、パケットが他のいずれのルールとも一致しない場合は、確実に拒否されます。このルールを変更または削除することはできません。IPv4 または IPv6 をサポートする VPC のデフォルトネットワーク ACL の例を以下に示します。

注記

デフォルトのネットワーク ACL のインバウンドルールを変更した場合は、IPv6 ブロックを VPC と関連付けても、インバウンド IPv6 トラフィックを許可する ALLOW ルールが自動的に追加されることはありません。同様に、アウトバウンドルールを変更した場合、アウトバウンド IPv6 トラフィックを許可する ALLOW ルールが自動的に追加されることはありません。

インバウンド
ルール番号 タイプ プロトコル ポート範囲 送信元 許可/拒否

100

すべての IPv4 トラフィック

すべて

すべて

0.0.0.0/0

許可

101

すべての IPv6 トラフィック

すべて

すべて

::/0

許可

*

すべてのトラフィック

すべて

すべて

0.0.0.0/0

DENY

*

すべての IPv6 トラフィック

すべて

すべて

::/0

拒否

アウトバウンド
ルール番号 タイプ プロトコル ポート範囲 送信先 許可/拒否

100

すべてのトラフィック

すべて

すべて

0.0.0.0/0

許可

101

すべての IPv6 トラフィック

すべて

すべて

::/0

許可

*

すべてのトラフィック

すべて

すべて

0.0.0.0/0

DENY

*

すべての IPv6 トラフィック

すべて

すべて

::/0

拒否

カスタムネットワーク ACL

IPv4 のみをサポートする VPC のカスタムネットワーク ACL の例を以下に示します。この ACL には、HTTP と HTTPS のインバウンドトラフィック (100 と 110) を許可するルールが含まれます。そのインバウンドトラフィックに対する応答を可能にするアウトバウンドルール (140) があります (一時ポート 32768~65535 が対象)。適切な一時ポートの範囲を選択する方法については、「一時ポート」を参照してください。

ネットワーク ACL には、SSH および RDP からサブネットに対するトラフィックを許可するインバウンドルールも含まれます。アウトバウンドルール 120 を使用すると、サブネットから応答を送信できます。

ネットワーク ACL には、サブネットからの HTTP および HTTPS のアウトバウンドトラフィックを許可するアウトバウンドルール (100 および 110) があります。そのアウトバウンドトラフィックに対する応答を可能にするインバウンドルール (140) があります (一時ポート 32768~65535 が対象)。

各ネットワーク ACL には、ルール番号がアスタリスクのデフォルトルールが含まれます。このルールによって、パケットが他のいずれのルールとも一致しない場合は、確実に拒否されます。このルールを変更または削除することはできません。

インバウンド
ルール番号 タイプ プロトコル ポート範囲 送信元 許可/拒否 コメント

100

HTTP

TCP

80

0.0.0.0/0

許可

任意の IPv4 アドレスからのインバウンド HTTP トラフィックを許可します。

110

HTTPS

TCP

443

0.0.0.0/0

許可

任意の IPv4 アドレスからのインバウンド HTTPS トラフィックを許可します。

120

SSH

TCP

22

192.0.2.0/24

許可

(インターネットゲートウェイを介した)ホームネットワークのパブリック IPv4 アドレスの範囲からのインバウンド SSH トラフィックを許可します。

130

RDP

TCP

3389

192.0.2.0/24

許可

(インターネットゲートウェイを介した)ホームネットワークのパブリック IPv4 アドレスの範囲からウェブサーバーに対するインバウンド RDP トラフィックを許可します。

140

カスタム TCP

TCP

32768-65535

0.0.0.0/0

許可

(送信元がサブネットであるリクエストに対する)インターネットからのインバウンドリターン IPv4 トラフィックを許可します。

この範囲は一例に過ぎません。

*

すべてのトラフィック

すべて

すべて

0.0.0.0/0

DENY

前のルールでまだ処理されていないすべてのインバウンド IPv4 トラフィックを拒否します (変更不可)。

アウトバウンド
ルール番号 タイプ プロトコル ポート範囲 送信先 許可/拒否 コメント

100

HTTP

TCP

80

0.0.0.0/0

許可

サブネットからインターネットへのアウトバウンド IPv4 HTTP トラフィックを許可します。

110

HTTPS

TCP

443

0.0.0.0/0

許可

サブネットからインターネットへのアウトバウンド IPv4 HTTPS トラフィックを許可します。

120 SSH

TCP

1024-65535

192.0.2.0/24

許可

(インターネットゲートウェイを介した) ホームネットワークのパブリック IPv4 アドレス範囲からのアウトバウンドリターン SSH トラフィックを許可します。

140

カスタム TCP

TCP

32768-65535

0.0.0.0/0

許可

インターネット上のクライアントに対するアウトバウンド IPv4 応答を許可します(例: サブネット内のウェブサーバーを訪問するユーザーに対するウェブページの提供)。

この範囲は一例に過ぎません。

*

すべてのトラフィック

すべて

すべて

0.0.0.0/0

DENY

前のルールでまだ処理されていないすべてのアウトバウンド IPv4 トラフィックを拒否します (変更不可)。

パケットがサブネットに送信されると、サブネットが関連付けられている ACL のインバウンドルールと照合して評価されます(ルールリストの一番上から順に一番下まで評価されます)。パケットが HTTPS ポート (443) あての場合の評価方法は次のとおりです。パケットは最初に評価されるルール (ルール 100) と一致しません。また、2 番目のルール (110) とは一致します。このルールでは、サブネットに送信されるパケットを許可します。パケットの宛先がポート 139 (NetBIOS) である場合は、いずれのルールとも一致せず、最終的に * ルールによってパケットが拒否されます。

正当に幅広い範囲のポートを開く必要があり、その範囲内の特定のポートは拒否する場合は、拒否ルールを追加します。このとき、テーブル内で、幅広い範囲のポートトラフィックを許可するルールよりも先に拒否ルールを配置します。

ユースケースに応じて、許可 ルールを追加します。たとえば、DNS 解決のためにポート 53 でアウトバウンド TCP および UDP アクセスを許可するルールを追加できます。追加するすべてのルールにおいて、応答トラフィックを許可する該当のインバウンドルールまたはアウトバウンドルールがあることを確認します。

IPv6 CIDR ブロックに関連付けられた VPC のカスタムネットワーク ACL の例を以下に示します。このネットワーク ACL には、すべての IPv6 HTTP および HTTPS トラフィックのルールが含まれます。この場合、IPv4 トラフィックの既存のルールの間に新しいルールが挿入されました。IPv4 ルールの後に、ルールを大きい数のルールとして追加することもできます。IPv4 トラフィックと IPv6 トラフィックは異なります。したがって、IPv4 トラフィックのルールはいずれも IPv6 トラフィックに適用することはできません。

インバウンド
ルール番号 タイプ プロトコル ポート範囲 送信元 許可/拒否 コメント

100

HTTP

TCP

80

0.0.0.0/0

許可

任意の IPv4 アドレスからのインバウンド HTTP トラフィックを許可します。

105

HTTP

TCP

80

::/0

許可

任意の IPv6 アドレスからのインバウンド HTTP トラフィックを許可します。

110

HTTPS

TCP

443

0.0.0.0/0

許可

任意の IPv4 アドレスからのインバウンド HTTPS トラフィックを許可します。

115

HTTPS

TCP

443

::/0

許可

任意の IPv6 アドレスからのインバウンド HTTPS トラフィックを許可します。

120

SSH

TCP

22

192.0.2.0/24

許可

(インターネットゲートウェイを介した)ホームネットワークのパブリック IPv4 アドレスの範囲からのインバウンド SSH トラフィックを許可します。

130

RDP

TCP

3389

192.0.2.0/24

許可

(インターネットゲートウェイを介した)ホームネットワークのパブリック IPv4 アドレスの範囲からウェブサーバーに対するインバウンド RDP トラフィックを許可します。

140

カスタム TCP

TCP

32768-65535

0.0.0.0/0

許可

(送信元がサブネットであるリクエストに対する)インターネットからのインバウンドリターン IPv4 トラフィックを許可します。

この範囲は一例に過ぎません。

145

カスタム TCP TCP 32768-65535 ::/0 許可

(送信元がサブネットであるリクエストに対する)インターネットからのインバウンドリターン IPv6 トラフィックを許可します。

この範囲は一例に過ぎません。

*

すべてのトラフィック

すべて

すべて

0.0.0.0/0

DENY

前のルールでまだ処理されていないすべてのインバウンド IPv4 トラフィックを拒否します (変更不可)。

*

すべてのトラフィック

すべて

すべて

::/0

拒否

前のルールでまだ処理されていないすべてのインバウンド IPv6 トラフィックを拒否します (変更不可)。

アウトバウンド
ルール番号 タイプ プロトコル ポート範囲 送信先 許可/拒否 コメント

100

HTTP

TCP

80

0.0.0.0/0

許可

サブネットからインターネットへのアウトバウンド IPv4 HTTP トラフィックを許可します。

105

HTTP

TCP

80

::/0

許可

サブネットからインターネットへのアウトバウンド IPv6 HTTP トラフィックを許可します。

110

HTTPS

TCP

443

0.0.0.0/0

許可

サブネットからインターネットへのアウトバウンド IPv4 HTTPS トラフィックを許可します。

115

HTTPS

TCP

443

::/0

許可

サブネットからインターネットへのアウトバウンド IPv6 HTTPS トラフィックを許可します。

140

カスタム TCP

TCP

32768-65535

0.0.0.0/0

許可

インターネット上のクライアントに対するアウトバウンド IPv4 応答を許可します(例: サブネット内のウェブサーバーを訪問するユーザーに対するウェブページの提供)。

この範囲は一例に過ぎません。

145

カスタム TCP

TCP

32768-65535

::/0

許可

インターネット上のクライアントに対するアウトバウンド IPv6 応答を許可します(例: サブネット内のウェブサーバーを訪問するユーザーに対するウェブページの提供)。

この範囲は一例に過ぎません。

*

すべてのトラフィック

すべて

すべて

0.0.0.0/0

DENY

前のルールでまだ処理されていないすべてのアウトバウンド IPv4 トラフィックを拒否します (変更不可)。

*

すべてのトラフィック

すべて

すべて

::/0

拒否

前のルールでまだ処理されていないすべてのアウトバウンド IPv6 トラフィックを拒否します (変更不可)。

カスタムネットワーク ACL およびその他の AWS のサービス

カスタムネットワーク ACL を作成する場合は、他の AWS のサービスを使用して作成したリソースにどのように影響するか注意してください。

Elastic Load Balancing では、バックエンドインスタンスのサブネットに、ソースが 0.0.0.0/0 であるかサブネットの CIDR のいずれかであるすべてのトラフィックに追加した拒否ルールを適用するネットワーク ACL がある場合、ロードバランサーはインスタンスのヘルスチェックを実行できません。ロードバランサーとバックエンドインスタンスに推奨されるネットワーク ACL ルールに関する詳細については、Classic Load Balancer のユーザーガイドの「VPC のロードバランサーのネットワーク ACL」を参照してください。

一時ポート

前のセクションでは、ネットワーク ACL の例に 32768~65535 という一時ポートの範囲を使用しています。ただし、使用または通信しているクライアントの種類によっては、ネットワーク ACL に別の範囲を使用してもかまいません。

リクエストを開始するクライアントは、一時ポートの範囲を選択します。範囲は、クライアントのオペレーティングシステムによって変わります。

  • 多くの Linux カーネル (Amazon Linux カーネルを含む) は、ポート 32768~61000 を使用します。

  • Elastic Load Balancing からのリクエストは、ポート 1024-65535 を使用します。

  • Windows Server 2003 を介する Windows オペレーティングシステムは、ポート 1025~5000 を使用します。

  • Windows Server 2008 以降のバージョンでは、ポート 49152~65535 を使用します。

  • NAT ゲートウェイはポート 1024~65535 を使用します。

  • AWS Lambda 関数は、ポート 1024-65535 を使用します。

たとえば、インターネット上の Windows 10 クライアントから、お客様の VPC のウェブサーバーにリクエストが送信される場合、ネットワーク ACL には、ポート 49152 ~ 65535 宛てのトラフィックを可能にするアウトバウンドルールを用意する必要があります。

VPC 内のインスタンスが、リクエストを開始するクライアントの場合、ネットワーク ACL には、インスタンス (Amazon Linux、Windows Server 2008 など) の種類に固有の一時ポートあてのトラフィックを可能にするインバウンドルールを用意する必要があります。

実際に、VPC 内のパブリックに面したインスタンスに対して、トラフィックを開始することができる多様なクライアントを対象にするには、一時ポート 1024~65535 を開くことができます。ただし、その範囲内で悪意のあるポートのトラフィックを拒否するルールを ACL を追加することもできます。このとき、テーブル内で、幅広い範囲の一時ポートを開く許可ルールよりも先に拒否ルールを配置します。

パス MTU 検出

2 つのデバイス間のパス MTU を判断するために、パス MTU 検出が使用されます。パス MTU は、送信側ホストと受信側ホスト間のパスでサポートされている最大のパケットサイズです。

IPv4 の場合、ホストがパスに沿って送信するパケットが、受信側ホストの MTU、あるいはデバイスの MTU よりも大きな場合、受信側ホストまたはデバイスはそのパケットをドロップし、次のような ICMP メッセージ Destination Unreachable: Fragmentation Needed and Don't Fragment was Set (タイプ 3、コード 4) を返します。このメッセージは送信側ホストに対し、ペイロードを複数の小さなパケットに分割し再送信することを指示します。

IPv6 プロトコルは、ネットワークのフラグメンテーションをサポートしていません。ホストがパスに沿って送信するパケットが、受信側ホストの MTU、あるいはデバイスの MTU よりも大きな場合、受信側ホストまたはデバイスはそのパケットをドロップし、次のような ICMP メッセージ ICMPv6 Packet Too Big (PTB) (タイプ 2) を返します。このメッセージは送信側ホストに対し、ペイロードを複数の小さなパケットに分割し再送信することを指示します。

サブネット内のホスト間の最大送信単位 (MTU) が異なる場合、またはインスタンスがインターネット経由でピアと通信する場合、インバウンドとアウトバウンドの両方に、以下のネットワーク ACL ルールを追加する必要があります。これにより、パス MTU 検出が正しく機能し、パケット損失を防ぐことができます。タイプに [Custom ICMP Rule] を選択し、ポート範囲(タイプ 3、コード 4)に [送信先に到達できません]、[fragmentation required, and DF flag set (フラグメンテーションが必要、および DF フラグを設定)] を選択します。トレースルートを使用する場合は、次のルールも追加します。[カスタム ICMP ルール] (タイプ)、[時間超過]、[TTL 伝送期限切れ] (ポート範囲: タイプ 11、コード 0) を選択します。詳細については、Linux インスタンス用 Amazon EC2 ユーザーガイドの「EC2 インスタンスのネットワーク最大送信単位 (MTU)」を参照してください。

ネットワーク ACL の動作

以下のタスクでは、Amazon VPC コンソールを使用してネットワーク ACL を操作する方法を示しています。

ネットワーク ACL の関連付けの確認

Amazon VPC コンソールを使用して、サブネットに関連付けられているネットワーク ACL を確認することができます。ネットワーク ACL を複数のサブネットに関連付けて、ネットワーク ACL に関連付けられているサブネットを確認することもできます。

サブネットと関連付けられているネットワーク ACL を確認するには
  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインで [Subnets] を選択し、サブネットを選択します。

    サブネットに関連付けられているネットワーク ACL は、ネットワーク ACL のルールと共に [Network ACL] タブに表示されます。

ネットワーク ACL に関連付けられたサブネットを決定するには
  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインの [Network ACLs] を選択します。[Associated With] 列には、各ネットワーク ACL に関連付けられているサブネットの数が表示されます。

  3. ネットワーク ACL を選択します。

  4. 詳細ペインで [Subnet Associations (サブネットの関連付け)] を選択して、ネットワーク ACL に関連付けられているサブネットを表示します。

ネットワーク ACL の作成

VPC のカスタムネットワーク ACL を作成できます。デフォルトでは、作成するネットワーク ACL により、ルールを追加するまですべてのインバウンドおよびアウトバウンドトラフィックがブロックされ、明示的に関連付けるまではサブネットと関連付けられません。

ネットワーク ACL を作成するには
  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインの [Network ACLs] を選択します。

  3. [Create Network ACL] を選択します。

  4. [Create Network ACL (ネットワーク ACL の作成)] ダイアログボックスで、オプションでネットワーク ACL に名前を付けて、[VPC] リストから VPC の ID を選択します。続いて、[Yes, Create (はい、作成します)] を選択します。

ルールの追加と削除

ACL のルールの追加または削除を行うと、その ACL に関連付けられたすべてのサブネットに変更が反映されます。サブネット内のインスタンスを終了して再起動する必要はありません。変更は短期間で有効になります。

重要

ルールを同時に追加したり削除したりする場合は、十分に注意してください。ネットワーク ACL ルールは、VPC に出入りできるネットワークトラフィックのタイプを定義します。インバウンドルールまたはアウトバウンドルールを削除し、Amazon VPC クォータ で許可されている数より多くのエントリを追加した場合、削除対象として選択されたエントリは削除されますが、新しいエントリは追加されません。これにより、予期しない接続の問題が発生し、意図せずに VPC とのアクセスが妨げられる可能性があります。

Amazon EC2 API またはコマンドラインツールを使用している場合は、ルールを変更できません。ルールの追加と削除のみを行うことができます。Amazon VPC コンソールを使用している場合は、既存のルールのエントリを変更できます。コンソールは既存のルールを削除し、新しいルールを追加します。ACL のルールの順序を変更する必要がある場合は、新しいルール番号を指定した新しいルールを追加してから、元のルールを削除します。

ルールをネットワーク ACL に追加するには
  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインの [Network ACLs] を選択します。

  3. 詳細ペインで、追加する必要があるルールの種類に応じて、[Inbound Rules] タブまたは [Outbound Rules] タブを選択し、[Edit] を選択します。

  4. [Rule #] にルール番号 (100 など) を入力します。ネットワーク ACL にすでに使用されているルール番号は使用できません。ルールは、最も低い番号から順に処理されます。

    ルール番号は、連続番号 (101、102、103 など) を使用せずに、間を空けておくことをお勧めします (100、200、300 など)。こうすることで、既存のルールに番号を振り直さなくても、新しいルールを簡単に追加できるようになります。

  5. [Type] リストからルールを選択します。たとえば、HTTP のルールを追加するには、[HTTP] を選択します。すべての TCP トラフィックを許可するルールを追加するには、[All TCP] を選択します。これらのオプションの一部 (HTTP など) については、ポートが自動入力されます。表示されていないプロトコルを使用するには、[Custom Protocol Rule] を選択します。

  6. (オプション) カスタムプロトコルルールを作成する場合は、[Protocol] リストからプロトコルの番号または名前を選択します。詳細については、「プロトコル番号の IANA リスト」を参照してください。

  7. (オプション)選択したプロトコルにポート番号が必要な場合、ポート番号またはハイフンで区切ったポート番号の範囲(49152-65535 など)を入力します。

  8. インバウンドルールかアウトバウンドルールかに応じて、[Source] または [Destination] フィールドに、ルールを適用する CIDR の範囲を入力します。

  9. [Allow/Deny] リストから、指定したトラフィックを許可するには [ALLOW]、指定したトラフィックを拒否するには [DENY] を選択します。

  10. (オプション) 別のルールを追加するには、[Add another rule] を選択し、必要に応じてステップ 4~9 を繰り返します。

  11. 完了したら、[Save ] を選択します。

ネットワーク ACL からルールを削除するには
  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインで [Network ACLs] を選択してから、ネットワーク ACL を選択します。

  3. 詳細ペインで、[Inbound Rules] タブまたは [Outbound Rules] タブを選択してから、[Edit] を選択します。削除するルールの [Remove] を選択し、[Save] を選択します。

サブネットとネットワーク ACL の関連付け

ネットワーク ACL のルールを特定のサブネットに適用するには、サブネットをネットワーク ACL と関連付ける必要があります。ネットワーク ACL を複数のサブネットに関連付けることができます。ただし、サブネットに関連付けることができるネットワーク ACL は 1 つだけです。特定の ACL に関連付けられていないサブネットは、デフォルトでデフォルトのネットワーク ACL と関連付けられます。

サブネットをネットワーク ACL と関連付けるには
  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインで [Network ACLs] を選択してから、ネットワーク ACL を選択します。

  3. 詳細ペインの [Subnet Associations] タブで、[Edit] を選択します。ネットワーク ACL に関連付けるサブネットの [Associate] チェックボックスをオンにしてから、[Save] を選択します。

ネットワーク ACL とサブネットの関連付けの解除

サブネットからカスタムネットワーク ACL の関連付けを解除できます。サブネットがカスタムネットワーク ACL から関連付けが解除されると、そのサブネットはデフォルトのネットワーク ACL に自動的に関連付けられます。

サブネットとネットワーク ACL の関連付けを解除するには
  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインで [Network ACLs] を選択してから、ネットワーク ACL を選択します。

  3. 詳細ペインの [Subnet Associations] タブを選択します。

  4. [Edit] を選択して、サブネットの [Associate] チェックボックスをオフにします。[Save] を選択します。

サブネットのネットワーク ACL の変更

サブネットに関連付けられているネットワーク ACL を変更できます。例えば、サブネットを作成すると、初期状態で、そのサブネットにはデフォルトのネットワーク ACL が関連付けられます。このサブネットには、作成したカスタムネットワーク ACL を関連付けることができます。

サブネットのネットワーク ACL を変更した後、サブネット内のインスタンスを終了して再起動する必要はありません。変更は短期間で有効になります。

サブネットのネットワーク ACL の関連付けを変更するには
  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインで [Subnets] を選択し、サブネットを選択します。

  3. [Network ACL] タブを選択し、[Edit] を選択します。

  4. [Change to (変更する)] リストからサブネットを関連付けるネットワーク ACL を選択して、[Save (保存)] を選択します。

ネットワーク ACL を削除する

ネットワーク ACL に関連付けられているサブネットがない場合にのみ、そのネットワーク ACL を削除できます。デフォルトのネットワーク ACL は削除できません。

ネットワーク ACL を削除するには
  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインの [Network ACLs] を選択します。

  3. ネットワーク ACL を選択し、[Delete] を選択します。

  4. 確認ダイアログボックスで、[Yes, Delete] を選択します。

API とコマンドの概要

このページで説明しているタスクは、コマンドラインまたは API を使用して実行できます。コマンドラインインターフェイスの詳細および利用できる API の一覧については、「Amazon EC2 の使用」を参照してください。

VPC のネットワーク ACL を作成する
1 つまたは複数のネットワーク ACL について説明する
ルールをネットワーク ACL に追加する
ネットワーク ACL からルールを削除する
ネットワーク ACL の既存のルールを置換する
ネットワーク ACL の関連付けを置換する
ネットワーク ACL を削除する

例: サブネットのインスタンスへのアクセス制御

この例では、サブネットのインスタンスは相互に通信でき、信頼されたリモートコンピュータからアクセス可能です。リモートコンピュータは、ローカルネットワーク内のコンピュータであるか、別のサブネットまたは VPC 内のインスタンスである可能性があります。これを使用して、インスタンスに接続し、管理タスクを実行します。セキュリティグループルールとネットワーク ACL ルールでは、リモートコンピュータの IP アドレス (172.31.1.2/32) からのアクセスを許可します。インターネットまたは他のネットワークからのその他のトラフィックはすべて拒否されます。このシナリオでは、インスタンスのセキュリティグループまたはセキュリティグループルールを変更し、防衛のバックアップレイヤーとしてネットワーク ACL を持つことができます。


          セキュリティグループと NACL の使用

インスタンスに関連付けるセキュリティグループの例を次に示します。セキュリティグループはステートフルです。したがって、インバウンドトラフィックへの応答を許可するルールは必要ありません。

インバウンド
プロトコルのタイプ プロトコル ポート範囲 送信元 コメント
すべてのトラフィック すべて すべて sg-1234567890abcdef0 このセキュリティグループに関連付けられたすべてのインスタンスは相互に通信できます。
SSH TCP 22 172.31.1.2/32 リモートコンピュータからのインバウンド SSH アクセスを許可します。
アウトバウンド
プロトコルタイプ プロトコル ポート範囲 送信先 コメント
すべてのトラフィック すべて すべて sg-1234567890abcdef0 このセキュリティグループに関連付けられたすべてのインスタンスは相互に通信できます。

次に、インスタンスのサブネットに関連付けるネットワーク ACL の例を示します。ネットワーク ACL ルールは、サブネット内のすべてのインスタンスに適用されます。ネットワーク ACL はステートレスです。したがって、インバウンドトラフィックへの応答を許可するルールが必要です。

インバウンド
ルール番号 タイプ プロトコル ポート範囲 送信元 許可/拒否 コメント
100 SSH TCP 22 172.31.1.2/32 許可 リモートコンピュータからのインバウンドトラフィックを許可します。
* すべてのトラフィック すべて すべて 0.0.0.0/0 拒否 他のすべてのインバウンドトラフィックを拒否します。
アウトバウンド
ルール番号 タイプ プロトコル ポート範囲 送信先 許可/拒否 コメント
100 カスタム TCP TCP 1024-65535 172.31.1.2/32 許可 リモートコンピュータに対するアウトバウンド応答を許可します。
* すべてのトラフィック すべて すべて 0.0.0.0/0 拒否 他のすべてのアウトバウンドトラフィックを拒否します。

誤ってセキュリティグループルールを過度に制限の低いものにした場合、この例ではネットワーク ACL ルールは指定した IP アドレスからのアクセスのみを許可し続けます。例えば、次のセキュリティグループには、任意の IP アドレスからのインバウンド SSH アクセスを許可するルールが含まれています。ただし、ネットワーク ACL を使用するサブネット内のインスタンスに、このセキュリティグループを関連付けると、ネットワーク ACL ルールによってサブネットへの他のインバウンドトラフィックが拒否されるため、そのインスタンスにアクセスできるのは、サブネット内およびリモートコンピュータ内の他のインスタンスのみです。

インバウンド
タイプ プロトコル ポート範囲 送信元 コメント
すべてのトラフィック すべて すべて sg-1234567890abcdef0 このセキュリティグループに関連付けられたすべてのインスタンスは相互に通信できます。
SSH TCP 22 0.0.0.0/0 すべての IP アドレスからの SSH アクセスを許可します。
アウトバウンド
タイプ プロトコル ポート範囲 送信先 コメント
すべてのトラフィック すべて すべて 0.0.0.0/0 すべてのアウトバウンドトラフィックを許可します。

到達可能性に関する問題のトラブルシューティング

Reachability Analyzer は静的な設定分析ツールです。Reachability Analyzer を使用して、VPC 内の 2 つのリソース間のネットワーク到達可能性を分析およびデバッグできます。Reachability Analyzer は、これらのリソースに到達可能な場合は、リソース間にある仮想パスのホップバイホップの詳細を生成し、そうでない場合はブロッキングコンポーネントを識別します。例えば、欠落した、または誤って設定されたネットワーク ACL のルールを特定できます。

詳細については、「Reachability Analyzer Guide」(到達可能性アナライザーガイド) を参照してください。