AWS上にDHCPサーバーを構築することになったあなたへ

インフラチームがお届けするブログリレーです！既に公開されている記事もありますので、こちらから他のメンバーの投稿もぜひチェックしてみてください！

はじめに

AWS 上では Amazon DHCP Server というサービスが裏側で動作しています。これは VPC 内のリソースに対して DHCP 機能（IP 払い出し、DNS / NTP サーバー情報配布など）を提供するサービスで、 VPC を作成すると勝手に利用できるフルマネージドなサービスです。

引用：https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/DHCPOptionSetConcepts.html

さらに、 DHCP オプションセットをユーザー自身で作成することで、払い出す DNS サーバーや NTP サーバーの情報などをカスタマイズすることが可能です。

しかしこれらの機能は、VPC 内部のリソースに対する IP 払い出しを想定した機能です。従来のオンプレミス環境のように、複数の拠点にある端末へ IP を払い出す DHCP サーバーとは少し用途が異なります。

そのため、オンプレミスの DHCP サーバーを AWS へ移行したい場合には、自ら DHCP サーバーを構築しなければならない場合が出てきます。
この記事では AWS 上で DHCP サーバーを構築する際の設計方針をご紹介します。

本記事は、あくまでも私の経験と知識に基づいて情報収集した結果の記事です。
「こういう方法もあるよ！」など意見があればフィードバックしていただけると嬉しいです！

設計における考慮ポイント

今回は、AWS 上で DHCP サーバーを構築し AWS 外の複数の拠点にある端末へ IP 払い出しを行う場合を想定します。

商用利用を考える場合、主に以下の2点を考えておく必要があると考えます。

• DHCP サーバーとしての機能を提供するための可用性
• DHCP サーバーと拠点 or 端末をつなぐネットワークの可用性

なお、実際にはセキュリティやバックアップ、ログ設計など、他に考慮すべき非機能が多数あります。
ただ、この記事では DHCP サーバーとしての機能に影響を及ぼすであろう非機能に焦点を当てます。

DHCP サーバーとしての機能を提供するための可用性

サーバーの可用性を確保するためには、どのように冗長化構成を組むか検討する必要があります。
特に、 Active/Active 構成（以下、Act/Act 構成と記載）にするか、Active/Standby 構成（以下、Act/Sby 構成と記載）にするかどうかが設計に影響してきます。

まず Act/Act 構成ですが、これは複数の DHCP サーバーで IP 払い出しの処理を負荷分散するような構成です。
複数の DHCP サーバー間でデータ同期をさせる必要がありますが、リース情報の同期に特に気を付けるべきだと思います。

リース情報とは、どの端末に対してどの IP を払い出したのかを記録しているものです。
環境によっては、このリース情報が短いスパンで書き換わる可能性があります。そのようなユースケースでは、リース情報の更新における整合性が担保されないと IP の重複などが発生してしまいます。

同じ IP アドレスが複数の端末に払い出されてしまってユーザーに直接影響が発生する、なんてこともありえます。

次に Act/Sby 構成ですが、これは通常時はアクティブサーバーが稼働し、障害発生時にスタンバイサーバーへ切り替わる構成です。

通常時は1台のサーバーだけが稼働するのが一般的ですので、Act/Act 構成の場合ほどデータ同期にシビアになる必要はありません。
基本的には、アクティブサーバーとスタンバイサーバーの間のフェイルオーバー設定がちゃんとできていればOKです。

なお、AWS 上ではサーバー間のトラフィックのレイテンシーに考慮する必要があります。
これは AWS 上で独自にクラスターを組む場合にも言えることですが、EC2 間のレイテンシーが許容されず、ハートビートが正しく動作してくれない可能性があります。

例えば、後述するKea DHCPというOSSを使ってAct/Act構成を組む場合では、ハートビート間隔をある程度カスタマイズすることができます。

heartbeat-delay – specifies a duration in milliseconds between sending the last heartbeat (or other command sent to the partner) and the next heartbeat. Heartbeats are sent periodically to gather the status of the partner and to verify whether the partner is still operating. The default value of this parameter is 10000 ms.
max-response-delay – specifies a duration in milliseconds since the last successful communication with the partner, after which the server assumes that communication with the partner is interrupted. This duration should be greater than the heartbeat-delay; typically it should be a multiple of heartbeat-delay. When the server detects that communication is interrupted, it may transition to the partner-down state (when max-unacked-clients is 0) or trigger the failure-detection procedure using the values of the two parameters below. The default value of this parameter is 60000 ms.

（翻訳）
heartbeat-delay – パートナに送信された最後のハートビート(または他のコマンド) を送信してから次のハートビートを送信するまでの期間をミリ秒単位で指定する。ハートビートは、パートナのステータスを収集し、パートナがまだ 動作しているかどうかを確認するために定期的に送信される。このパラメータのデフォルト値は10000msである。
max-response-delay – パートナとの通信が最後に成功してから、サーバーがパートナとの 通信が中断されたと見なすまでの時間をミリ秒単位で指定する。この継続時間は、ハートビート遅延よりも長くする必要がある。通常、ハートビート遅延の倍数にする必要がある。サーバーが通信の中断を検出すると、(max-unacked-clientsが0のときに)パートナーダウン状態に移行するか、以下の2つのパラメータ値を使用して障害検出手順を起動 する。このパラメータのデフォルト値は60000msである。

引用：https://kea.readthedocs.io/en/kea-2.6.2/arm/hooks.html#load-balancing-configuration

必要に応じて PoC などを実施し、問題なく冗長化できることを確認することをお勧めします。

DHCP サーバーと拠点 or 端末をつなぐネットワークの可用性

複数の拠点から AWS 上の DHCP サーバーへアクセスする構成では、ネットワークの可用性を十分に担保しないと多数のユーザーに影響が出てしまいます。

また、各拠点から AWS へのアクセス経路としては Direct Connect やインターネット VPN など、様々な方法が考えられます。

このように、DHCP サーバーを構築する際には接続端末数の多さと接続経路の多様さを意識する必要が出てきます。
このようなネットワークにおける考慮点を補うために、AWS のサービスとしては Cloud WAN や Transit Gateway を活用するのが有効です。

設計方針の具体例

ここからは、前述の考慮ポイントに対する設計方針の具体例をいくつかご紹介します。

サーバー構築の設計方針

大きく分けて、以下の3つのパターンが考えられます

• Windows Server の DHCP サーバー機能を利用する
• Linux 系 OS 上で Kea DHCP のような OSS を利用する
• アプライアンス製品を利用する

それぞれのパターンにはメリット・デメリットがあり、要件に応じた適切に選択する必要があります。
以下にそれぞれの特徴をまとめます。

それぞれのパターンについて、詳しく解説していきます。

Windows Server の DHCP サーバー機能を利用する

Windows Server の機能の一つとして DHCP サーバー機能が提供されています。そのため、Windows Server を利用する場合はほぼ確実にこの機能を利用することになると思います。
https://learn.microsoft.com/ja-jp/windows-server/networking/technologies/dhcp/quickstart-install-configure-dhcp-server?tabs=powershell

さらに、Act/Act 構成と Act/Sby 構成どちらも標準機能として提供されています。
（ドキュメントでは Act/Act 構成のことを「負荷分散モード」、Act/Sby 構成のことを「ホットスタンバイモード」と呼称しています。）
https://learn.microsoft.com/ja-jp/windows-server/networking/technologies/dhcp/dhcp-failover

また、Windows Server の機能を利用しているため Active Directory との相性も良いです。Active Directory を利用している環境では第一候補となる設計方針だと思います。

ただし、Windows Server OS を利用するため Linux 系 OS に比べると、EC2 の利用料は少し高くなります。加えて、Windows Server に馴染みのない場合は導入がためらわれます。

Linux 系 OS 上で Kea DHCP のような OSS を利用する

Linux 系 OS の場合には、OS から提供されている機能を使うのではなく OSS を利用することになるかと思います。
ここでは一例として、Kea DHCP という DHCP サーバーの OSS を取り上げます。

https://www.isc.org/kea/

Kea DHCP は DHCP サーバーの OSS として一般的なものであり、インターネット上に関連記事が複数公開されています。
また、Windows Server と同じように Act/Act 構成と Act/Sby 構成どちらも機能として提供されています。
Act/Act 構成におけるサーバー間でのデータ同期についてはドキュメントで詳しく言及されており、リース情報の整合性を担保できるようになっているとドキュメントに書かれています。

The Kea HA hook library supports three configurations, also known as HA modes: load-balancing, hot-standby, and passive-backup. In the load-balancing mode, two servers respond to DHCP requests. The load-balancing function is implemented as described in RFC 3074, with each server responding to half the received DHCP queries. When one of the servers allocates a lease for a client, it notifies the partner server over the control channel (via the RESTful API), so the partner can save the lease information in its own database. If the communication with the partner is unsuccessful, the DHCP query is dropped and the response is not returned to the DHCP client. If the lease update is successful, the response is returned to the DHCP client by the server which has allocated the lease. By exchanging lease updates, both servers get a copy of all leases allocated by the entire HA setup, and either server can be switched to handle the entire DHCP traffic if its partner becomes unavailable.

（翻訳）
Kea HAフックライブラリは、ロードバランシング、ホットスタンバイ、パッシブバックアップの3つの構成をサポートしています。ロードバランシングモードでは、2台のサーバーがDHCPリクエストに応答します。ロードバランシング機能はRFC3074に記載されているように実装されており、各サーバーは受信したDHCPクエリの半分に応答します。一方のサーバーがクライアントにリースを割り当てると、サーバーは（RESTful APIを経由して）制御チャネル経由でパートナーサーバーに通知し、パートナーは自身のデータベースにリース情報を保存できるようになります。パートナーとの通信が失敗した場合、DHCP クエリは破棄され、DHCP クライアントに応答は返されません。リース更新が成功した場合は、リースを割り当てたサーバーからDHCPクライアントに応答が返されます。DHCPクライアントがDHCPクエリに失敗した場合、DHCPクエリは破棄され、DHCPクライアントに応答は返されません。

引用：https://kea.readthedocs.io/en/kea-2.6.2/arm/hooks.html#supported-configurations

また、Kea DHCP はコンフィグファイルを JSON 形式で書きます。設定をするために多少の学習コストはかかりますが、設定管理をコードで行いたい場合には Windows Server よりも管理がしやすくなります。

https://kea.readthedocs.io/en/kea-2.2.0/arm/config.html

また、Windows Server OS を利用する場合よりも EC2 の利用料を抑えられる点もメリットかと思います。

なお、Kea DHCP と似た OSS に ISC DHCP というものがありますが、こちらは2022年に開発が終了しています！
誤って利用しないように注意しましょう。

https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/9/html/9.4_release_notes/deprecated-functionality-infrastructure-services

アプライアンス製品を利用する

最後に、DHCP サーバーとしての機能に特化したアプライアンス製品を利用するパターンについて紹介します。
このパターンでは、アプライアンスを提供するベンダーや代理店のサポートを受けられたり、アプライアンス製品ならではの機能が利用できる点が大きなメリットです。

また、最近では AWS 上で利用することを想定して各ベンダーが開発をしています。例えば、Infoblox というアプライアンス製品では、AWS 上で Infoblox をデプロイするためのドキュメントが公開されています。

https://docs.infoblox.com/space/NAIG/37585115/About+Infoblox+vNIOS+for+AWS

しかし、このパターンではアプライアンス製品独自の機能や設定・管理方法を習得するための学習コストがかかります。加えて、製品のライセンス費用やサポート費用が高くなる傾向にあります。

とはいえ、大規模かつ非常に高い信頼性が求められるエンタープライズな環境であれば、このパターンが有力候補となります。

ネットワーク構築の設計方針

最後に、DHCP サーバーと端末をつなぐネットワークの設計方針に軽く触れておきます。

前述の通り、Cloud WAN と Transit Gateway を活用することで可用性を担保する必要がありますが、それぞれ適するユースケースが微妙に異なります。

まず Cloud WAN を利用する場合ですが、Cloud WAN を利用することでリージョンを跨いだネットワークを作ることができます。

引用：https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2022_AWS_Cloud_WAN_Part01_1125_v1.pdf （P10）
※上記資料中には「AWS Direct Connect は現在サポートしておりません。」との記載がありますが、2025年5月現在ではサポートされています。
https://aws.amazon.com/jp/about-aws/whats-new/2024/11/aws-cloud-wan-on-premises-connectivity-direct-connect/

そのため、日本全国あるいはグローバルに拠点があり、リージョンをまたいだ接続が必要な場合に最適な選択肢です。
例えば、日本全国の拠点にある端末に対して IP 払い出しをしたい、東京リージョンで大規模障害が発生した場合もサービス継続したい、そのようなユースケースに最適です。

一方、Transit Gateway はリージョナルなサービスです。Transit Gateway を使ってリージョンを跨ぐ必要がある場合には、Transit Gateway 同時でピアリングする必要があります。

引用：https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2022_AWS_Cloud_WAN_Part01_1125_v1.pdf （P8）

Cloud WAN は比較的高額ですので、拠点が東日本もしくは西日本いずれかのみに集中している場合には、Transit Gateway の方が費用対効果を見出しやすいです。

さいごに

クラウドが普及してきている今であっても、本記事で書いたようなオンプレ風の構成はまだまだ残り続けると思います。
ただ、そこを補完してくれるナレッジはまだまだ少ないと感じています。実際、「AWS 上で DHCP サーバーを作る」という切り口での情報がほとんど無く、今回のように自ら情報収集をする必要がありました。

インフラエンジニアである以上、オンプレミスとクラウドの境界に位置するような情報も積極的に発信していきたいなと思います。

この記事が誰かの役に立てば幸いです！