AWS Wavelength zone内のサブネット上に、chronyを使ったNTPサーバーを立ててみました。
AWS Wavelengthとは
AWS Wavelengthとは、簡潔に表現すると、EC2を利用したコンピューティング環境をモバイルキャリア網（日本ではKDDI）に直結する形で構築することができるサービスとなります。
ヒント
WavelengthゾーンにEC2のインスタンスを立てる場合ですが、インスタンス・タイプなど、いろいろな限定がありますので、東京リージョンとすべて同じというわけではありません。
下の図で説明しますと、AWS Wavelength Zoneは、キャリアネットワーク（日本ではKDDI）の雲の一部に設置されるようなイメージになります。実際のAWS Wavelength Zone（東京）の物理的な場所は、KDDIのネットワークセンター内になりますので、ちょうど、キャリアネットワークの中にAWSの出張所がある感じですね！
Wavelengthゾーンにサーバーを立てるとどうなるか？
WavelengthゾーンにWindows Serverを立てて、そのWindows Serverへリモートデスクトップで接続してみますと、そのデスクトップ上でブラウザを使ってGoogle、Yahooなどの通常のWebサービスにアクセスすることができます。
ただし、その逆については制限があり、例えば、PCからWavelengthゾーン上のWebサーバーへアクセスしようとするケースでは、そのPCがauまたはUQのSIMを使って通信を行っている場合のみ可能となります。（au/UQのスマホによるテザリング、または、au/UQのSIMを使っているモバイルルーターなど。もちろん、au/UQのSIMを使っているスマホのブラウザでアクセスすることも可能です。）
また、次に出てきますが、Wavelengthゾーン上のサーバーとインターネット上のサーバーがUDPを使って通信をする場合、仕様上、Carrier Gateway（AWS WavelengthとKDDIモバイル網の接続ポイントにあるルーター）がパケットを通さないので、通信できません。
問題点
AWS Wavelength zone内に普通にEC2インスタンスを立ててchronyをインストールしても、WavelengthはUDPを通さないので、外部のNTPサーバーにアクセスして時間情報を取得することができません。
補足
下記のAWSのマニュアルにある通り、Wavelength上のEC2インスタンスとKDDIのモバイルネットワークを利用している端末はUDPで通信できるのですが、外部のNTPサーバーがauで通信しているわけがない（当然固定回線ですね！）ので、結局、このケースでは「通信できない」となります。
下記は、AWS Wavelengthのマニュアルからの抜粋です。
解決策
仕方がないので、下記の2つの方法を試してみることとしました。
1. 同じVPC内の東京リージョン側に同様のNTPサーバーを立てて、それを参照する
2. Amazon Time Sync Serviceを利用する
それでは、下記の構成図のような形で設定していきます。
東京リージョン（Public Subnet）のinstanceへchronyをインストール
Ctrl+Alt+Tでターミナルを開いて、コマンドでchronyをインストールします。
sudo apt install chrony
次に、/etc/chrony/chrony.confをエディターで開いて、chronyのコンフィグファイルを編集します。
sudo nano /etc/chrony/chrony.conf
そうすると下記のような画面が開きますので、デフォルトで入っているサーバーを消して、下記の画面のような感じで、サーバーを追加しましょう。
ちなみに、169.254.169.123は、Amazon Time Sync Serviceのアドレス、ntp.nict.jpは情報通信研究機構が運営する時刻サーバーのドメインとなります。（それ以外は適当に選びました。）
また、最後の行にWavelength上のサーバー(10.50.50.234)で稼働しているchronyから参照できるように、下記のような設定を1行追加します。
allow 10.50.50.234
もし、複数のサーバーからのアクセスを許可したい場合は、複数の行にして、それぞれ記入するか、または、CIDRフォーマット（例えば、10.50.50.0/24）で記述します。
allow 10.50.50.0/24
ここで一度、chronyサービスをリスタートしましょう。
sudo systemctl restart chrony.service
chronyを有効にするためのサーバーの設定変更
さらに、上記のallow 10.50.50.234の設定はあくまでもchronyの話なので、サーバーのセキュリティグループも同時に設定変更する必要があります。
Wavelength側のchrony(10.50.50.234) => 東京リージョン側のchrony(10.50.10.252)という形のアクセスになりますので、東京リージョン側のEC2インスタンスにおけるセキュリティグループのインバウンドルールの設定において、すべてのトラフィック（all traffic, all protocol）について10.50.50.234を許可しましょう。
EC2 > セキュリティグループの設定 > 該当するセキュリティグループにおいて、インバウンドルールを編集します。
ルールを1行追加して、typeでall trafficを選択、Sourceは10.50.50.234を入力
Wavelength Subnet上のinstanceへchronyをインストール
Wavelength上のインスタンスに接続するためには、通常は、踏み台サーバー（Jump Box）を立てて、それを経由してアクセスします。Jump Boxを使った接続方法については、Public Subnet上にあるJump BoxからPrivate Subnet上にあるサーバーにアクセスする方法と全く同じですので、その部分については省略させていただきます。
ちなみに、auの携帯を持っている方であれば、Jump Boxなしで、au携帯のテザリングで直接接続することもできます。
その場合、Internet Gatewayは通らず、Wavelength側のCarrier Gatewayを通ってサーバーにアクセスする形となりますが、Wavelength上のサーバーのセキュリティグループを編集して、RDPでauが使っているIPアドレスレンジを受け付ける設定を入れましょう。
サーバーに接続できたら、先ほどと同様に、chronyをインストールしましょう。
sudo apt install chrony
次に、/etc/chrony/chrony.confをエディターで開いて、chronyのコンフィグファイルを編集します。
sudo nano /etc/chrony/chrony.conf
そうすると、また下記のような画面が開きますので、デフォルトで入っているサーバーを消して、こちらも下記の画面のような感じで、サーバーを追加しましょう。
169.254.169.123はAmazon Time Sync ServiceのIPアドレス、10.50.10.252は、東京リージョン側のchronyが稼働しているサーバーのアドレスとなります。
この10.50.10.252を入れることで、chronyが自動的に東京リージョン側のchrony（NTPサーバー）へアクセスするようになります！
設定が終わりましたので、一度、chronyサービスをリスタートしましょう。
sudo systemctl restart chrony.service
chronyが稼働しているかどうか、サービスのステータスを見てみましょう。
sudo systemctl status chrony
東京リージョン側のchrony(NTP Server)の稼働状況を確認
chronyc sourcesコマンドによって、情報ソース毎の状況を確認できます。-vをつけると、説明が付きます。
上から6番目の星印が付いているサーバーが現在同期しているサーバーであり、調整されたオフセットが百万分の98秒であると表示しています。
Stratumは、時間ソースサーバーを階層化していて、Startum 0が原子時計に直結している時間サーバー、Stratum 1はStratum 0の時間サーバーに同期していて、Stratum 0の次に正確な時間を供給するサーバーとなります。
chronyc sources -v
chronyc sourcestatsは、chronyc sourcesによって表示されない詳細な統計情報を表示するコマンドです。
chronyc sourcestats -v
また、chronyc trackingコマンドによって、現時点でのトラッキング情報（選択している時間サーバーをベースとした時間情報の追跡状況）を表示します。
こちらで表示している内容では、システムタイムがNTPタイムに対して百万分の6.77秒遅れていると言っています。
chronyc tracking
さらに、chronyc clientsコマンドによって、このサーバー（東京リージョン側のchrony）へアクセスしているクライアントの情報が得られます。
ip-10-50-50-234.ap-north...は、Wavelength側のサーバー（10.50.50.234）のDNSネームになりますので、このサーバー（10.50.10.252）へアクセスしていることがわかります！
chronyc clients
Wavelength側のchronyの稼働状況を確認
利用するコマンドは同じですが、下記のようなステータスが確認できます。
時間ソースがAmazon Time Sync Serviceと東京リージョンに建てたNTPサーバー（chrony）の2つとなります。
いずれの調整後のオフセット値も1ミリ秒以下の数値（百万分の884など）となっており、悪くないのでは？！と思っていますが、いかがでしょうか。。
chronyc sources -v
chronyc sourcestats -v
トラッキング情報を見ると、System timeのところで、NTPタイムと比較して百万分の154秒（1万分の1.54秒）早いとのこと。
chronyc tracking
Amazon Time Sync Serviceについて
こうしてみると、Linux系、FreeBSD系、MacOSであれば、すべてchronyをインストールできるので、AWSの内部では、片っ端からchronyを入れて、単に、configファイルに、下記のサーバーの記述を入れてしまえば、まあまあの精度が得られるということでしょうか。
※ ただし、この記事では、Amazon Time Sync Serviceに固定されてしまっては面白くないので、下記のサーバーの記述からpreferは外しています。
server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4
参考情報