Wavelengthを使ってみて分かったこと

背景

5Gに対応したAWSの機能であるAWS Wavelengthにかねてより注目していたため、デモ開発の中で試しに使ってみた。
Wavelength利用にあたっては以下を参照した。

• AWS Wavelength の開始方法
• 【初心者】AWS Wavelengthを使ってみる

利用してみて得られた知見を次の流れで整理する。

• 疎通確認を通じて分かったこと
• 利用してみて分かったWavelengthの制約（2022年4月時点）

なお、Wavelengthの機能概要や利用手順については上記のリンク先等に説明があるのでこの記事では説明を省略することとする。

疎通確認を通じて分かったこと

Wavelengthの機能概要を押さえるために、デモ開発の前に簡易的なシステムを構築してAWSドキュメント等の情報通りに疎通確認が取れるかを確認した。
疎通確認時のシステム構成、知識不足で設定ミスしてしまった点、その他分かったことを以下にまとめる。

疎通確認時のシステム構成

下の図のように、東京リージョンにVPCを構築し、Wavelength Zone（WLZ）内のEC2でWebアプリケーションを稼働させた。

Webアプリケーションにアクセスできるか、以下の2パターンの疎通確認を行った。（図中の①②に対応）

1. KDDIのスマートフォンからの疎通確認
   • VPCの外からのWLZ内のリソースへのTCPトラフィックはAWSが提携しているキャリア回線（東京リージョンの場合はKDDI回線）からのアクセスのみ許可されているため、KDDIのスマートフォンを利用した疎通確認を試した
2. PCから踏み台サーバを経由した疎通確認
   • VPC内部のリソースからWLZ内のリソースへのトラフィックは制限されていない。そのため、WLZを使ったサブネットと同じVPCでAvailability Zone（AZ）を使ったサブネットを作成、サブネット内に踏み台サーバを立て、PC → 踏み台サーバ → Webアプリケーションという経路での疎通確認を試した

疎通確認は結果的に上手く行ったが、パターン①については以下の2点をミスしてトラブルシュートに戸惑った。

ミス①　WLZは対応エリア外からアクセス不可

筆者は関東で疎通確認を行っていたため、東京リージョンで構築したVPC内にWLZ対応のサブネットを作成した。
サブネット作成時に指定できるWLZが2つあったが、特に注意をしなかった。

が、実は東京リージョンで提供されているWLZ2つのうち、１つは東京（東日本エリア）、もう1つは大阪（西日本エリア）のものだった。

気づかぬうちに大阪（西日本エリア）のWLZを選択してしまっていたが、東京（東日本エリア）のWLZ内のリソースには東日本エリアのKDDI回線からしかTCPトラフィックでアクセスできないようだった。
あとで気づいて東京（東日本エリア）のWLZに対応したサブネットを作成し直す羽目になった。

ミス②　WLZはWi-Fi経由でアクセス不可

1つ目のミスに気づいたあとも疎通確認がとれず、調べた結果、KDDIのスマートフォンをWi-Fi接続済み状態で検証するという初歩的なミスを犯していた。
WLZ内のリソースにTCPトラフィックでアクセスするにはKDDI回線を利用する必要があるが、Wi-Fi接続していると当然KDDI回線経由にはならない。

スマートフォンを利用する際には常にWi-Fi接続を有効化しておき、利用可能なWi-Fiが近くに飛んでいればWi-Fi経由でインターネット接続するという使い方が一般的だと思われる。
しかし、WLZ内のリソースと通信させたい際にはWi-Fi接続を無効化することも検討しないといけないと分かった。

その他、疎通確認の過程で以下のことも確認できた。

WLZへはKDDI端末でテザリングしたPCでもアクセス可

疎通確認のパターン①の経路ではKDDI回線が必要なので、PCからではアクセス不可だと思いこんでいた。
が、KDDI端末でテザリングしたPCでもKDDI回線を利用することになるので、WLZ内で起動するWebアプリケーションにアクセス可能だった。

WLZ内のEC2をネットワーク的に保護する方法

WLZの利用目的はあくまでデモ開発であったため、WLZ内のEC2で稼働するWebアプリケーションへのパターン①の経路での接続元を極力制限したいと考えた。
WLZ内のEC2にもAZ内のEC2と同様にセキュリティグループをアタッチするので、セキュリティグループのインバウンドルールを厳しく設定できないか調べてみた。

調べたところ、KDDIのスマートフォンがインターネット接続する際のIPはこちらで表示されるグローバルIPが使われることが分かった。
EC2のセキュリティグループで全てのIPからではなくそのグローバルIPからのHTTPアクセスのみ許可すれば条件を満たせることが検証でも確認できた。

ただし、さらに調べてみて分かったことだが、端末に割り当てられるグローバルIPは定期的に変わるそうだ。（参考：動的IPアドレスと固定（静的）IPアドレス）
そのため、常時WLZ内のEC2のセキュリティグループのインバウンドルールを厳しく設定したいのであれば、KDDI回線経由でアクセスさせたい端末の最新のグローバルIPを検知してセキュリティグループを更新するような運用を考える必要があり、あまり現実的ではない。

利用してみて分かったWavelengthの制約（2022年4月時点）

Wavelengthには、WLZ内のリソースへのTCPトラフィックはAWSが提携しているキャリア回線（東京リージョンの場合はKDDI回線）からのアクセスのみ許可されるという大きな制約がある。
疎通確認やデモ開発でWavelengthを利用してみると、その他の機能上の制約も分かったので以下にまとめる。

制約①　WLZは1つの対応エリアでは1つのみ提供されている

疎通確認時のミスで書いた内容と重複するが、東京リージョンで提供されているWLZは2つあり、１つは東京（東日本エリア）、もう1つは大阪（西日本エリア）のものとなっている。

WLZが2つ提供されているが、東京（東日本エリア）のWLZ内のリソースは東日本エリアのKDDI回線からのTCPトラフィックを許可、大阪（西日本エリア）のWLZ内のリソースは西日本エリアのKDDI回線からのTCPトラフィックを許可するという動作となっている。

そのため、東京（東日本エリア）のWLZ内でWebアプリケーションを動かしたい、WLZの障害に備えて複数WLZにデプロイする構成を取りたいと思っても、東京（東日本エリア）のWLZは1つのみなので、マルチAZのような構成を取ることはできない。

WLZの障害に備えた可用性の高い構成を取りたいのであれば、以下のようにAZにフェイルオーバーできる構成を取ることはできる。

• 通常時

  • WLZ側の方がKDDIのスマートフォンとEC2との間で5Gネットワークを使った高速通信ができるため、AZ側に用意したアプリケーションサーバではリクエストを受け付けない
    

• 障害時

  • WLZ側で障害が発生した場合は、AZ側に用意したアプリケーションサーバでリクエストを受け付ける
    

制約②　WLZ内で起動できるサービスが限定されている

WLZ内で起動できるサービスはEC2インスタンスとEBSボリュームに限定されており、AZ内で起動できるRDSやELBといったサービスも基本的に起動できない。
そのため、WLZ内のEC2で動かすアプリケーションのデータストアとしてRDSを使いたいような場合には、図のようにRDSをWLZを使うサブネットと同じVPC内のAZを使ったサブネットに配置するような構成を取ることになる。

さらにEC2のインスタンスタイプについても、以下の4タイプに限定されている。

• t3.medium
• t3.xlarge
• r5.2xlarge
• g4dn.2xlarge

いずれのインスタンスタイプもt2.nanoと比べるとスペックが高く利用料金も高いので、t2.nanoでも稼働できるようなアプリケーションをWLZのEC2で動かす場合は利用料金面のデメリットが大きくなる。

その他の起動できるサービスの制約の詳細についてはAWSドキュメントを参照。

制約③　HTTPS通信の実装にACMの証明書を利用できない

通常、EC2で起動するアプリケーションと、クライアントとの間の通信を暗号化するには、AWSのサービスであるACMで発行したSSL/TLS証明書を利用できる。
SSL/TLS証明書はEC2または前段に配置したELBのいずれかにインストールする構成が取れる。

1. EC2に証明書をインストール
   ACMで発行した証明書をインストールできるEC2のインスタンスタイプはNitro Enclavesがサポートされる一部のインスタンスタイプに限定されるのが注意点
   
2. ELBに証明書をインストール
   

しかし、少なくともAWSに問い合わせした2021年12月時点では、WLZではELBやNitro EnclavesがサポートされるインスタンスタイプのEC2が配置できなかったため、ACM以外で証明書を発行し、WLZで稼働するEC2に証明書をインストールしてHTTPS通信を実装する必要がある。

以上のように不便に感じる点もあったが、Wavelengthの利用者が増えていけば、どんどん機能拡張されて便利になっていくはずなので、今後に期待したい。