はじめに
宇宙に関心があって、AWSが好きな人はAWS Ground Stationを、Azureな人はAzure Orbital Ground Stationを一度ぐらいは調べたことがあるのではないでしょうか。今回は、実際の宇宙関連の案件が舞い込んできたことを想定して、両クラウドのサービスを要件別に独自の観点で評価してみます！
2回にわたって比較結果をまとめます。本記事では、独自の観点で設定したセキュリティ要件や性能要件、法規制・監査要件などの机上調査結果を中心に説明します！
AWS Ground Stationとは
自身で地上局準備しなくても、衛星データの受信や制御が可能になるサービスです。
アンテナやデジタイザー、モデムなどの地上局機器も準備する必要がなく、衛星との通信時間をスケジュールするだけで衛星データの保存、処理、配信など、すべての衛星データの操作をAWS上で実行できます。
おおまかな仕組み
アンテナと地上局
AWS Ground Stationは、全方向可動式アンテナを使用しています。
これにより、人工衛星の通信を追跡し、データが受信可能となっています。
また、地上局はアンテナと通信インフラストラクチャから構成されており、AWSが提供する地上局は世界中のさまざまな地域に配置されています。
ネットワークアーキテクチャ
セキュリティに厳格な要件を満たす設計で作成されているとのことです。地上局は、AWSのグローバルネットワークバックボーンに接続されており、高速で信頼性のある通信を実現しているようです。
Azure Orbital Ground Stationとは
AWS Ground Stationと同じく、Microsoftが所有している基地局や提携を結んでいる基地局を利用して、衛星とAzure間の低遅延接続を可能とするサービスです。データの取り込み、衛星の正常性と状態の監視、衛星へのコマンドの送信を行う衛星との通信スケジュールなども柔軟に設定可能となっています。下図は衛星からデータを受信した後に、分析可能となるまでに必要な加工処理などをまとめたフローとなりますが、本サービス利用者は赤枠の解析された状態のデータから使用することが可能です。
検証・評価
ここからは、実際に衛星データを利活用したビジネスについて、素人ながらに検証範囲を定めたうえで、仮の評価項目を据えてみて、実際に調べてみます。
今回解説するスコープ
まずは簡単に衛星データ利用の簡単な背景から説明します。
衛星データを利活用するにあたり、法令や衛星データ売買等の契約上の留意点などが多く存在し、法的問題を検討する必要があります。
【対応・検討が必要な法令】
- 衛星リモセン法
- 電波法
- 知的財産関連法
【衛星データ利用契約上の留意点】
- 打上げに関する責任
- 衛星データの販売権限・利用権限
- 衛星データの取得困難時の責任
衛星リモートセンシングによって得られるデータは、悪用されると国の安全保障上の利益を害する恐れがあります。特に、衛星リモセン法は、衛星リモートセンシング記録の適正な取扱いの確保に関する重要な法律となっています。
以上の背景を踏まえ、要件を書きだして評価をする前に、本サービスのスコープについて一旦整理してみます。
衛星データの分析フローは大きく4段階に分かれます。
このうち、生データは衛星と地上局でのやり取りに閉じるので、本サービスの対象外かと思います。また、解析ツールなども他のサービスや製品の精度に依存することになるので、今回の評価対象外ということにします。
そのため、今回の評価対象は下記の図の赤枠で囲った「前処理」に限定します。
宇宙系の案件で想定される要件
本サービスを評価するにあたって、衛星データを使用したビジネスを想定する場合にどんな要件があるのか考えてみました。
| No | 分類 | 評価項目 |
|---|---|---|
| 1 | セキュリティ要件 | プライベートネットワーク環境下でデータ連携が可能か |
| 2 | セキュリティ要件 | 通信データの暗号化が可能か |
| 3 | 性能要件 | プライベートネットワーク環境下で衛星データが連携されるまでのリードタイムを比較する |
| 4 | コスト要件 | 衛星データ収集サービスの利用料を比較する |
| 5 | 耐障害性要件 | 地上局・データ配信先を冗長化することが可能か |
| 6 | 耐障害性要件 | マルチクラウド構成を取ることが可能か |
| 7 | 法規制・監査要件 | 日本国内のデータ保管に絞ることが可能か |
| 8 | 法規制・監査要件 | クラウドベンダーによる衛星データの利用があるか |
| 9 | 機能要件 | 衛星データ収集サービスが利用可能となるまでのリードタイムを比較する |
| 10 | 機能要件 | 利用者が指定するパブリッククラウドサービスに衛星データを連携可能か |
| 11 | 機能要件 | 衛星から受信したデータの復調方式はカスタマイズ可能か |
| 12 | 機能要件 | 衛星データの補正・圧縮処理の開発効率化が可能か |
基本的には机上調査になりますが、機能要件については一部いじって確かめてみようかと思います。
評価
ここから実際に評価していきます。セキュリティ要件から法規制・監査要件までは主に机上調査として調べたことのまとめ、機能要件については今回試しにAzure Orbital Ground Stationについては実際にオープンデータを用いて触ってみた結果をまとめてます。
1.セキュリティ要件：プライベートネットワーク環境下でデータ連携が可能か
AWSとAzureの衛星データ収集サービスのネットワーク仕様について調査しました。
AWSの場合、データ連携先をEC2とS3が選択可能です。
- EC2へデータ連携する場合、EC2に外部IPが必要
- S3へデータ連携する場合、外部IPは不要であり、プライベートネットワーク環境下で連携可能
一方、Azureの場合、宛先は2024年2月時点ではVMしか選択できないが、EIPは不要です。
以上より、基本的にAWS・Azureともにプライベートネットワーク環境下でデータ連携は可能です。ただしオンプレからEC2やVMなどのパブリッククラウドのサーバに移行する場合、AWSはプライベートネットワーク環境下にすることは出来ないようです。
2.セキュリティ要件：通信データの暗号化が可能か
AWS
① 配信先がEC2の場合
- GroundStation AnntenaからEIPは、暗号化用のカスタマーマネージドAWS KMSキーを使用した暗号化によるデータ配信が可能
② 配信先がS3の場合
- GroundStation AnntenaからS3は、暗号化用のカスタマーマネージド AWS KMS キーを使用した暗号化によるデータ配信が可能
Azure
① 配信先がVM
- アンテナからAzureデータセンターへのファイバーリンクは、MACsecの暗号化と専用の VXLANトンネルを含む** Azure ネットワーク標準によって暗号化**される
以上より、AWSとAzure共に暗号化がされていることは確認できたので、大きなそん色はないと判断できます。
3.性能要件：プライベートネットワーク環境下で衛星データが連携されるまでのリードタイムを比較する
前述の通り、プライベートネットワーク環境下では、AWSはS3を仲介してデータ連携する必要があります。そのため、復調や補正・圧縮処理後の衛星データがストレージサービスへと連携される際のAWS・Azureそれぞれの概略図は以下となります。
データ処理されて、利用者に連携されるまでのリードタイムは、サーバ上のデータ処理時間に大きく依存します。一方、構成観点で評価すると、プライベートネットワーク環境下において、途中に生データをストレージサービスに格納する必要ないAzure方が短いリードタイムでデータ連携は可能であると考えられます。
4.コスト要件：衛星データ収集サービスの利用料を比較する
Azureで構成した環境をもとに、AWSとAzureの利用料を比較します。衛星データ収集サービスからデータをストレージ格納する環境で、週2回10分間のデータを格納させた場合の利用料は以下となります。
その結果、AWSとAzureは遜色ないと判断しました。なお従来のアンテナ建設には、1基あたり1億円以上かかるようなので、オンプレと比べるともちろん非常に安価と言えます。
5.耐障害性要件：地上局・データ配信先を冗長化することが可能か
AWS
衛星と地上局(AWS Ground Stationアンテナ)は1対多となります。1つの衛星に対して複数の地上局からデータ取得可能です。
また、地上局と配信先は1対1で、地上局と配信先のリージョンは同じでなければなりません。なお、AWS Ground Stationはリージョンサービスであり、リージョン毎に地上局が存在しています。
以上より、1つの衛星に対して複数の地上局からデータ取得する場合、配信先は複数リージョンに作成する必要はありますが、冗長化の構成を取ることは可能です。
※1 以下のみクロスリージョンが可能だが、対象が極小的のため1対1と判断
- us-east-2からus-west-2
- us-west-2からus-east-2
※2us-west-2 (オレゴン) のリージョンのみ米国 (オレゴン)と米国(ハワイ)のAWS Ground Stationアンテナを選択可能
Azure
AWS Ground Stationと異なり、衛星と地上局の組み合わせを設定したAzure Orbitalを作成し、Orbital VMから配信先にデータ転送します。
衛星と地上局は1対多で、1つの衛星に対して複数の地上局からデータ取得が可能です。
また、Azure Orbitalと配信先は1対多となります。つまり、1つのAzure Orbitalに対して複数の配信先を指定できるためリージョンレベルの冗長化が取りやすいうえ、Azure Orbitalと配信先のVMは同じリージョンである必要がないようです。（クロスリージョン構成が可能）
6.耐障害性要件：マルチクラウド構成を取ることが可能か
AWS Ground StationとAzure Orbitalを利用できる衛星であれば、以下のようにマルチクラウド構成を取ることは可能です。
参考までに、AWSは12か所、Azureは5か所でAWSの方が数は多いです。 (2024年2月時点)
特定の地上局に障害が発生しても、衛星が対応している別の地上局でデータ取得が可能であるといった特徴もあります。
一方で、Azureは5つの地上局以外に、別途、契約は必要ですが、パートナーの地上局も利用可能です。
また、AWS Ground Station、Azure OrbitalともにSLAは99.9%です。サービスクレジットの月間稼働率に若干の差異があるが、どちらのクラウドが優位とは言い切れず、AWSとAzureはほぼ同等となっています。
AWS
| クラウド | 月間稼働率 | サービスクレジットの割合 |
|---|---|---|
| AWS | 99.9%未満99.0%以上 | 10% |
| AWS | 99.0%未満95.0%以上 | 25% |
| AWS | 95.0%未満 | 100% |
Azure
| クラウド | 月間稼働率 | サービスクレジットの割合 |
|---|---|---|
| Azure | 99.9%未満98.0%以上 | 10% |
| Azure | 99.0%未満98.0%以上 | 25% |
| Azure | 95.0%未満 | 100% |
7.法規制・監査要件：日本国内のデータ保管に絞ることが可能か
まず、AWS Ground Stationは東京・大阪リージョン非対応です。(2024年2月時点)AWS Ground Stationとデータの配信先は同じリージョンであることが必須なため、データ配信先は東京・大阪リージョン以外で作る必要があります。よって、日本国内にデータ保管を絞ることは、現時点では出来ません。
また、Azure Orbital自体も日本のリージョンは非対応です。(2024年2月時点)
しかし、配信先のVMについてクロスリージョンは可能で、Azure Orbitalに対応したリージョンのみ選択可能ではあります。とはいえ、あくまでAzure Orbital自体がまだ日本リージョンに対応していないため、AWS同様に日本国内にデータ保管を絞ることは出来ません。
8.法規制・監査要件：クラウドベンダーによる衛星データの利用があるか
AWS Ground Station利用に伴い、以下のような機能がないことは確認できたので、AWS社が衛星データを利用・閲覧することはないようです。
- AWS にてお客様の衛星を操作する仕組みや機能
- 利用者が衛星とやり取りしたデータを利用する仕組みや機能
また、AzureもAWS同様に、利用者の衛星コンタクト状況や取得データを閲覧・編集する仕組みがないことは確認できましたので、Microsoft社が衛星データを利用することはないようです。
さいごに
いかがでしたでしょうか。本記事では、机上調査を中心にAWS・Azureの宇宙サービスのGround Stationについて、それぞれ評価結果をまとめてみました。次回は実際にAzureでプロトタイプを実装した上での機能要件の評価を説明します。