工場や研究拠点、事業所など複数のオンプレミス環境から、Amazon Web Services (AWS) 上の分析基盤へ分析データを定期アップロードする構成です。各拠点は 4G (LTE) ルーターや IoT ゲートウェイに IoT SIM を装着して接続し、SORACOM Canal と Virtual Private Gateway (VPG) を使って Amazon Virtual Private Cloud (Amazon VPC) と閉域接続します。自社クラウドを利用する一般論は、3. 特化型 IoT ゲートウェイ - 自社システムパターン を参照してください。
この構成が向いているケース
- 製造拠点や研究拠点、事業所など、地理的に分散した複数拠点から同じ分析基盤にデータを送信する。
- 各拠点ごとに Virtual Private Network (VPN) 装置や固定回線を手配せず、できるだけ早く立ち上げる。
- Amazon Simple Storage Service (Amazon S3)、Amazon Athena、Amazon QuickSight などを使って自社の分析基盤を構築する。
- AWS サービスへの通信をインターネットに公開せず、閉域接続のまま運用する。
- IoT SIM の差し替え防止や通信量の異常検知などを中央で統制する。
拠点数が少なく既存の VPN 基盤が整っている場合
拠点数が少なく拡張予定が少ない場合や、既存ネットワークがすでに整備されている場合は、従来の VPN ベース構成でも要件を満たせることがあります。一方で、多数拠点を短期間で接続する場合は、この構成のメリットが大きくなります。
一般的な構成との違い
AWS 側の分析基盤そのものは、オンプレミスとクラウドを一般的なプライベート接続で結ぶ構成と大きく変わりません。違いは、各拠点の接続方法と、名前解決および IoT SIM の運用統制をどこで集約するかです。
この構成が目指すことは、次の 5 点です。
- オンプレミスのデバイスやサーバーから分析データを定期アップロードする。
- オンプレミスと AWS の間の通信を閉域接続のまま完結させる。
- 単一障害点をできるだけ減らす。
- サーバーレスな分析基盤を使って運用負担を抑える。
- 拠点追加と現場運用の負担を増やしにくい形にする。
一般的な VPN ベース構成と、この構成の違いを整理すると以下のとおりです。
| 項目 | 一般的な VPN ベース構成 | この構成 |
|---|---|---|
| 拠点側の接続 | 拠点ごとに VPN 装置や回線を準備する | 4G (LTE) ルーターや IoT ゲートウェイに IoT SIM を装着する |
| AWS への接続点 | お客様側で VPN 接続を設計する | SORACOM Canal と VPG を利用する |
| AWS サービスの DNS | 拠点ごとの DNS フォワーダーで転送する | IoT SIM の カスタム DNS で Route 53 Resolver に転送する |
| 拠点追加時の作業 | 拠点ごとに接続装置や設定追加が必要 | IoT SIM とグループ設定の追加で横展開しやすい |
| 通信統制 | ネットワーク機器側に寄る | VPG、IMEI ロック、イベントハンドラー を組み合わせて中央集約しやすい |
構成要素と役割
| 層 | 構成要素 | 役割 |
|---|---|---|
| オンプレミス | デバイス、サーバー、分析データの送信元アプリケーション | Amazon S3 などの宛先に分析データを送信する。送信には AWS Software Development Kit (AWS SDK) や AWS Command Line Interface (AWS CLI) などを利用できる。 |
| オンプレミス | 4G (LTE) ルーター、IoT ゲートウェイ | IoT SIM を使ってセルラーネットワークへ接続し、拠点と SORACOM をつなぐ。 |
| SORACOM | IoT SIM、SIM グループ | 接続先の VPG、カスタム DNS、監視設定などをグループ単位で一元化する。 |
| SORACOM | VPG、SORACOM Canal | SORACOM 側の閉域ネットワークとお客様の Amazon VPC をプライベート接続する。本記事では VPG Type-F と Amazon VPC ピアリング接続 を例にする。 |
| AWS | Amazon VPC、プライベートサブネット、インターフェイス VPC Endpoint | AWS サービスへの通信をプライベート IP アドレスで終端する。 |
| AWS | Amazon Route 53 Private Hosted Zone、Route 53 Resolver インバウンド Endpoint | オンプレミスからの DNS クエリを受け、AWS サービスの DNS 名をプライベート IP アドレスへ解決する。 |
| AWS | Amazon S3、Amazon Athena、Amazon QuickSight | データ蓄積、分析、可視化を行う。 |
| 認証と統制 | IMEI ロック、イベントハンドラー、SORACOM Krypton | IoT SIM の差し替え抑止、異常通信の監視、永続的なアクセスキーを置かない設計を支える。 |
通信経路と名前解決の設計
この構成でつまずきやすいのは、通信経路よりも Domain Name System (DNS) 設計です。ネットワーク経路が正しくても、AWS サービスの DNS 名をプライベート IP アドレスへ解決できなければ、Amazon S3 などのサービスに到達できません。
AWS 側で設計する項目
- Amazon VPC で DNS ホスト名と DNS 解決を有効化する。
- 接続先サービスのインターフェイス VPC Endpoint を作成する。
- Route 53 Private Hosted Zone を作成し、サービスの DNS 名を VPC Endpoint 固有の DNS 名やプライベート IP アドレスへ解決するレコードを設定する。
- Route 53 Resolver のインバウンド Endpoint を作成する。
- 単一障害点を避けるために、VPC Endpoint とインバウンド Endpoint は 2 つ以上のアベイラビリティーゾーンで構成する。
SORACOM 側で設計する項目
- Virtual Private Gateway (VPG) のタイプ を確認したうえで、VPG Type-F を作成し、お客様の Amazon VPC と SORACOM Canal でプライベート接続する。
- 対象の IoT SIM を同じ SIM グループに所属させ、同じ VPG を利用するように設定する。
- SIM グループの カスタム DNS に、Route 53 Resolver インバウンド Endpoint の IP アドレスを設定する。
- インターネットへの自由な通信が不要な場合は、VPG 側でインターネットに抜ける経路を使わない設計にする。
デバイス側の挙動
デバイスやサーバーは、通常どおり AWS サービスの DNS 名を指定して通信します。IoT SIM に通知されたカスタム DNS によって、その DNS クエリは Route 53 Resolver インバウンド Endpoint へ転送され、応答としてプライベート IP アドレスが返ります。この結果、データ通信も名前解決も閉域接続の内部で完結します。
DNS 設計は切り分けポイントになりやすい
通信経路の疎通が取れていても、Private Hosted Zone のレコードやカスタム DNS の設定が不正だと、AWS サービスに到達できません。閉域接続の疎通確認と DNS 応答確認を分けて切り分ける準備をしたうえで設計してください。
拠点追加と運用ガバナンスの設計
この構成の狙いは、単に閉域接続を作ることではなく、IoT プロジェクトで増えやすい「拠点追加のスケール」「立ち上げ速度」「運用ガバナンス」を崩さずに運用することです。
拠点追加のしやすさ
- 各拠点で必要になる主な追加物は、4G (LTE) ルーターまたは IoT ゲートウェイと IoT SIM です。
- AWS 側の分析基盤や DNS 設計は共通化しやすく、拠点ごとに VPN 装置や回線工事を繰り返す構成より展開しやすくなります。
- VPG と SORACOM Canal はユーザーコンソールでセルフサービスで構成できるため、フィールドテストから本番移行までの立ち上げ速度を高めやすくなります。
運用ガバナンス
- SIM グループに VPG とカスタム DNS を設定することで、拠点ごとの接続設定を中央で揃えやすくなります。
- IMEI ロック を利用すると、指定した端末だけがその IoT SIM を利用できるように制限できます。
- イベントハンドラー を組み合わせると、想定外の通信量や異常な状態を監視しやすくなります。
セキュリティ設計
通信の閉域化
- オンプレミスから AWS までの通信は、セルラーネットワーク、VPG、SORACOM Canal、Amazon VPC、インターフェイス VPC Endpoint を通る。
- AWS サービスへの到達はプライベート IP アドレスで完結し、インターネットへ公開しない。
- 必要に応じて VPG 側のフィルタリングも組み合わせる。
IoT SIM の不正利用対策
IMEI ロック を設定すると、IoT SIM を意図した端末以外で使い回されるリスクを下げられます。さらに イベントハンドラー を組み合わせることで、異常利用の中央監視にもつなげられます。
IMEI ロックは事前検証してください
通信キャリアによっては、IMEI ロックが意図したとおりに動作しない場合があります。本番適用前に、対象の通信環境で IMEI が正しく通知されることを確認してください。
永続的な AWS 認証情報を置かない
オンプレミスのデバイスやサーバーに長期利用の AWS Identity and Access Management (AWS IAM) アクセスキーを配置し続ける運用は避けます。選択肢としては、次のような構成が考えられます。
- 閉域接続のままデバイス管理を行う場合は、AWS Systems Manager のハイブリッドアクティベーションを利用する。
- SORACOM Krypton と Amazon Cognito Identity Pools を利用した一時認証情報の払い出し を組み合わせる。
判断ポイントとトレードオフ
- 拠点数が少なく既存の社内ネットワークや VPN 装置を再利用できるなら、従来の VPN ベース構成のほうがシンプルな場合があります。
- 多拠点展開や短期立ち上げを重視するなら、IoT SIM と VPG を軸にしたこの構成のほうが運用負担を抑えやすくなります。
- AWS 側では、インターフェイス VPC Endpoint や Route 53 Resolver インバウンド Endpoint など、プライベート接続のためのコンポーネント設計が必要です。
- データ量が大きく、セルラーではなく専用線や既存 Wide Area Network (WAN) を中心に検討すべきケースでは、ほかの接続方式も比較してください。
関連する SORACOM ドキュメント
- 一般的な設計パターン: 3. 特化型 IoT ゲートウェイ - 自社システムパターン
- 閉域接続の構成: SORACOM Canal を使用して閉域網で接続する (Amazon VPC ピアリング接続)
- Canal の概要: SORACOM Canal
- VPG の選定: Virtual Private Gateway (VPG) のタイプ
- 名前解決の設定: IoT SIM のカスタム DNS を設定する
- IoT SIM の統制: IoT SIM に IMEI ロックを設定する
- 監視と自動化: イベントハンドラー
- 一時認証情報の払い出し: Cognito のクレデンシャルを取得し S3 からファイルをダウンロードする
元記事
本記事は、SORACOM Blog で公開した技術ブログの内容を、アーキテクチャーセンター向けに設計判断しやすい形へ再構成したものです。背景や検討の流れもあわせて確認する場合は、以下のオリジナル記事を参照してください。