

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Network Load Balancer
<a name="network-load-balancers"></a>

Network Load Balancer は、クライアントにとって単一の通信先として機能します。クライアントは Network Load Balancer にリクエストを送信し、Network Load Balancer は 1 つ以上のアベイラビリティーゾーンにあるターゲット (EC2 インスタンスなど) にそれらのリクエストを送信します。

Network Load Balancer を設定するには、[ターゲットグループ](load-balancer-target-groups.md)を作成し、ターゲットグループにターゲットを登録します。有効な各アベイラビリティーゾーンに少なくとも 1 つの登録済みターゲットがあるようにする場合、Network Load Balancer が最も効果的です。さらに、[リスナー](load-balancer-listeners.md)を作成してクライアントからの接続リクエストがないかチェックし、リクエストをクライアントからターゲットグループ内のターゲットにルーティングします。

Network Load Balancer は、VPC ピアリング、 AWS マネージド VPN Direct Connect、およびサードパーティー VPN ソリューションを介したクライアントからの接続をサポートします。

**Topics**
+ [ロードバランサーの状態](#load-balancer-state)
+ [IP アドレスタイプ](#ip-address-type)
+ [接続のアイドルタイムアウト](#connection-idle-timeout)
+ [ロードバランサーの属性](#load-balancer-attributes)
+ [クロスゾーンロードバランサー](#cross-zone-load-balancing)
+ [DNS 名](#dns-name)
+ [ロードバランサーのゾーンヘルス](#load-balancer-zonal-health)
+ [ロードバランサーの作成](create-network-load-balancer.md)
+ [アベイラビリティーゾーンの更新](availability-zones.md)
+ [IP アドレスタイプを更新する](load-balancer-ip-address-type.md)
+ [ロードバランサー属性を編集する](edit-load-balancer-attributes.md)
+ [セキュリティグループを更新する](load-balancer-security-groups.md)
+ [ロードバランサーにタグを付ける](load-balancer-tags.md)
+ [ロードバランサーの削除](load-balancer-delete.md)
+ [リソースマップを表示する](view-resource-map.md)
+ [CloudWatch ログ](load-balancer-cloudwatch-logs.md)
+ [ゾーンシフト](zonal-shift.md)
+ [LCU 予約](capacity-unit-reservation.md)

## ロードバランサーの状態
<a name="load-balancer-state"></a>

Network Load Balancer の状態は次のいずれかです。

`provisioning`  
Network Load Balancer はセットアップ中です。

`active`  
Network Load Balancer は完全にセットアップされており、トラフィックをルーティングする準備ができています。

`failed`  
Network Load Balancer をセットアップできませんでした。

## IP アドレスタイプ
<a name="ip-address-type"></a>

クライアントが Network Load Balancer で使用できる IP アドレスのタイプを設定できます。

Network Load Balancer は次の IP アドレスタイプをサポートしています。

**`ipv4`**  
クライアントは IPv4 アドレス (192.0.2.1 など) を使用して接続する必要があります。

**`dualstack`**  
クライアントは、IPv4 アドレス (192.0.2.1 など) と IPv6 アドレス (例えば、2001:0db8:85a3:0:0:8a2e:0370:7334) の両方を使用して Network Load Balancer に接続できます。

**考慮事項**
+ Network Load Balancer は、ターゲットグループの IP アドレスのタイプに基づいてターゲットと通信します。
+ UDP IPv6 リスナーの送信元 IP 保存をサポートするには、**[IPv6 ソース NAT の プレフィックスを有効化]** がオンになっていることを確認します。
+ Network Load Balancer のデュアルスタックモードを有効にすると、Elastic Load Balancing が Network Load Balancer の AAAA DNS レコードを提供します。IPv4 アドレスを使用して Network Load Balancer と通信するクライアントは、A DNS レコードを解決します。IPv6 アドレスを使用して Network Load Balancer と通信するクライアントは、AAAA DNS レコードを解決します。
+ インターネットゲートウェイを経由する内部デュアルスタック Network Load Balancer へのアクセスがブロックされ、意図しないインターネットアクセスを防止します。ただし、これにより他のインターネットアクセス (ピアリング、Transit Gateway AWS Direct Connect、 など) が妨げられることはありません Site-to-Site VPN。

詳細については、「[Network Load Balancer の IP アドレスタイプを更新する](load-balancer-ip-address-type.md)」を参照してください。

## 接続のアイドルタイムアウト
<a name="connection-idle-timeout"></a>

クライアントが Network Load Balancer を通じて行う TCP リクエストごとに、その接続の状態が追跡されます。アイドルタイムアウトよりも長い時間、クライアントからもターゲットからもその接続経由でデータが送信されない場合、接続は追跡されなくなります。アイドルタイムアウト期間の経過後にクライアントまたはターゲットがデータを送信した場合、クライアントは接続が無効になったことを示す TCP RST パケットを受信します。

TCP フローのデフォルトのアイドルタイムアウト値は 350 秒ですが、60～6,000 秒の任意の値に更新できます。クライアントまたはターゲットは TCP キープアライブパケットを使用して、アイドルタイムアウトを再開できます。TLS 接続を維持するために送信されるキープアライブパケットには、データまたはペイロードを含めることはできません。

TLS リスナーの接続アイドルタイムアウトは 350 秒であり、変更できません。TLS リスナーがクライアントまたはターゲットのいずれかから TCP キープアライブパケットを受信すると、ロードバランサーは TCP キープアライブパケットを生成し、20 秒ごとにフロントエンド接続とバックエンド接続の両方に送信します。この動作を変更することはできません。

UDP はコネクションレスですが、ロードバランサーは送信元と宛先のIPアドレスとポートに基づいて UDP フロー状態を維持します。これにより、同じフローに属するパケットが一貫して同じターゲットに一貫して同じターゲットに送信されます。アイドルタイムアウト期間が経過した後、ロードバランサーは着信 UDP パケットを新しいフローとみなし、それを新しいターゲットにルーティングします。Elastic Load Balancing は、UDP フローのアイドルタイムアウト値を 120 秒に設定します。これは変更できません。

EC2 インスタンスは、リターンパスを確立するために、30 秒以内に新しいリクエストに応答する必要があります。

詳細については、「[アイドルタイムアウトを更新する](update-idle-timeout.md)」を参照してください。

## ロードバランサーの属性
<a name="load-balancer-attributes"></a>

Network Load Balancer は、属性を編集することで設定できます。詳細については、「[ロードバランサー属性を編集する](edit-load-balancer-attributes.md)」を参照してください。

Network Load Balancer のロードバランサー属性を以下に示します。

`access_logs.s3.enabled`  
Amazon S3 に保存されたアクセスログが有効かどうかを示します。デフォルトは `false` です。

`access_logs.s3.bucket`  
アクセスログの Amazon S3 バケットの名前。この属性は、アクセスログが有効になっている場合は必須です。詳細については、「[バケットの要件](enable-access-logs.md#access-logging-bucket-requirements)」を参照してください。

`access_logs.s3.prefix`  
Amazon S3 バケットの場所のプレフィックス。

`deletion_protection.enabled`  
[削除保護](edit-load-balancer-attributes.md#deletion-protection)が有効化されているかどうかを示します。デフォルトは `false` です。

`ipv6.deny_all_igw_traffic`  
Network Load Balancer へのインターネットゲートウェイ (IGW) アクセスをブロックし、インターネットゲートウェイを経由した内部 Network Load Balancer への意図しないアクセスを防止します。インターネット向け Network Load Balancer では `false`、内部 Network Load Balancer では `true` に設定されます。この属性は、IGW 以外のインターネットアクセス (ピアリング、Transit Gateway、 AWS Direct Connect、 など) を妨げません Site-to-Site VPN。

`load_balancing.cross_zone.enabled`  
[クロスゾーン負荷分散](#cross-zone-load-balancing)が有効かどうかを示します。デフォルトは `false` です。

`dns_record.client_routing_policy`  
Network Load Balancer のアベイラビリティーゾーン間でトラフィックがどのように分散されるかを示します。指定できる値は、ゾーンアフィニティが 100% の `availability_zone_affinity`、ゾーンアフィニティが 85% の `partial_availability_zone_affinity`、ゾーンアフィニティが 0% の `any_availability_zone` です。

`secondary_ips.auto_assigned.per_subnet`  
設定する[セカンダリ IP アドレス](edit-load-balancer-attributes.md#secondary-ip-addresses)の数。ターゲットを追加できない場合は、これを使用してポート割り当てエラーを解決します。有効な範囲は 0～7 です。デフォルトは 0 です。この値を設定した後で、減らすことはできません。

`zonal_shift.config.enabled`  
[ゾーンシフト](zonal-shift.md)が有効になっているかどうかを示します。デフォルトは `false` です。

## クロスゾーンロードバランサー
<a name="cross-zone-load-balancing"></a>

デフォルトでは、各 Network Load Balancer ノードは、アベイラビリティーゾーン内の登録済みターゲット間でのみトラフィックを分散します。クロスゾーン負荷分散をオンにすると、各 Network Load Balancer ノードは、有効なすべてのアベイラビリティーゾーンの登録済みターゲットにトラフィックを分散します。ターゲットグループレベルでクロスゾーンロードバランサーを有効にすることもできます。詳細については、「*Elastic Load Balancing ユーザーガイド*」の「[ターゲットグループに対するクロスゾーン負荷分散](edit-target-group-attributes.md#target-group-cross-zone)」および「[クロスゾーンロードバランシング](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing)」を参照してください。

## DNS 名
<a name="dns-name"></a>

各 Network Load Balancer は、{{name}}-{{id}}.elb.{{region}}.amazonaws.com の構文でデフォルトのドメインネームシステム (DNS) 名を受け取ります。例えば、my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com です。

覚えやすい DNS 名を使用する場合は、カスタムドメイン名を作成し、Network Load Balancer の DNS 名に関連付けることができます。このカスタムドメイン名を使用してクライアントがリクエストを生成すると、DNS サーバーが Network Load Balancer の DNS 名に解決します。

最初に、認定ドメイン名レジストラにドメイン名を登録します。次に、ドメインレジストラなどの DNS サービスを使用して、Network Load Balancer にリクエストをルーティングするための DNS レコードを作成します。詳細については、DNS サービスのドキュメントを参照してください。例えば、DNS サービスとして Amazon Route 53 を使用する場合は、Network Load Balancer をポイントするエイリアスレコードを作成します。詳細については、*Amazon Route 53 デベロッパーガイド*の[ ELB ロードバランサーへのトラフィックのルーティング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html)を参照してください。

Network Load Balancer には、有効なアベイラビリティーゾーンごとに 1 つの IP アドレスがあります。これらは Network Load Balancer ノードの IP アドレスです。Network Load Balancer の DNS 名はこれらのアドレスに解決されます。例えば、Network Load Balancer のカスタムドメイン名が `example.networkloadbalancer.com` であるとします。以下の **dig** または **nslookup** コマンドを使用して、Network Load Balancer ノードの IP アドレスを調べます。

**Linux または Mac**

```
$ dig +short {{example.networkloadbalancer.com}}
```

**Windows**

```
C:\> nslookup {{example.networkloadbalancer.com}}
```

Network Load Balancer には、Network Load Balancer ノードの DNS レコードがあります。次の構文で DNS 名を使用して、Network Load Balancer ノードの IP アドレスを調べることができます: {{az}}.{{name}}-{{id}}.elb.{{region}}.amazonaws.com。

**Linux または Mac**

```
$ dig +short {{us-east-2b.my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com}}
```

**Windows**

```
C:\> nslookup {{us-east-2b.my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com}}
```

## ロードバランサーのゾーンヘルス
<a name="load-balancer-zonal-health"></a>

Network Load Balancer には、Route 53 に有効な各アベイラビリティーゾーンのゾーン DNS レコードと IP アドレスがあります。Network Load Balancer が特定のアベイラビリティーゾーンのゾーンヘルスチェックに合格しなかった場合、その DNS レコードは Route 53 から削除されます。ロードバランサーのゾーンヘルスは Amazon CloudWatch メトリクス `ZonalHealthStatus` を使用してモニタリングされるため、フェイルアウェイの原因となるイベントに関する詳細なインサイトが得られ、アプリケーションの可用性を最適化するための予防策を講じることができます。詳細については、「[Network Load Balancer メトリクス](load-balancer-cloudwatch-metrics.md#load-balancer-metrics-nlb)」を参照してください。

Network Load Balancer は、さまざまな理由でゾーンヘルスチェックに合格せず、異常になる可能性があります。ゾーンヘルスチェックに合格しなかったことによって引き起こされる異常な Network Load Balancer の原因として一般的なものを、以下に示します。

**以下の原因が考えられますので、確認してください。**
+ ロードバランサーに正常なターゲットがない
+ 正常なターゲットの数が、設定された最小値未満である
+ ゾーンシフトまたはゾーン自動シフトが進行中
+ 問題が検出されたため、トラフィックが自動的に正常なゾーンに移行中