ソラコム公式ブログ

IoT リファレンスアーキテクチャ：多拠点とAWSのプライベート接続

2026年03月10日 18時00分更新

　本記事はソラコムが提供する「SORACOM公式ブログ」に掲載された「IoT リファレンスアーキテクチャ：多拠点とAWSのプライベート接続」を再編集したものです。

こんにちは。ソラコムでソリューションアーキテクト(お客様への技術支援)を担当している服部です。IoT のプライベートネットワーク設計では、拠点数の増加と運用ガバナンスが設計を複雑にするため、以下のようなご相談をよく頂きます。

IoT の現場とクラウドをつなぐプライベートネットワーク接続の基本形を知りたい。
IoT のプライベートネットワークの構成上のポイントは何か？
SORACOM では何が出来るのか？

本記事では、よくお問い合わせ頂く AWS クラウドを例にして AWS 公式リファレンスアーキテクチャを出発点に、多拠点 IoT を“拠点追加と運用負荷”の観点で破綻させないための設計パターンとして、SORACOM で実現するプライベートネットワーク接続のアーキテクチャと構成上のポイントを整理します。

なお、このようなプライベートネットワーク型構成は、通信業界では「閉域網」や「閉域接続」などと呼ばれます。通信業界で言うところの「閉域網」とは？SORACOM ではどう実現しているか？については、以下のブログで解説しておりますので、併せてご参照ください。

閉域網とは？IoTデバイスとデータを保護する方法とSORACOM – SORACOM公式ブログ

一般的なオンプレミスとクラウド上の分析環境をプライベートネットワーク接続するアーキテクチャ

まずは理解のベースを揃えるために、一般的なオンプレミスとクラウドのプライベートネットワーク接続のアーキテクチャを見ながら、構成上のポイントを確認していきましょう。以下は、オンプレミスのデバイスやサーバーから、AWS 上の S3 にプライベートネットワーク経由で分析データを保存するアーキテクチャのシステム構成図です。

システム構成図とアーキテクチャの目的

本アーキテクチャの目的は以下の通りです。

製造拠点や研究拠点、事業所などオンプレミスのデバイスやサーバーからプライベートネットワークを通じてクラウドに分析データを定期アップロードする
オンプレミスとクラウド間の通信はプライベートネットワーク内で閉じた通信とする
システム構成内の単一障害点を極力排除する
サーバーレスな設計によりランニングコストと運用コストを抑えたアドホックな分析環境を構築する
BI ツールもウェブサービスとして利用することで高機能な分析環境を迅速に立ち上げる

このアーキテクチャは、AWS のウェブサイト [目的別クラウド構成と概算料金例] で紹介されている、”データ分析基盤を AWS クラウドで構築（基本編）” と “オンプレミスと AWS を VPN を⽤いてプライベート接続したい” とを組み合わせたものです。また、AWS を例にしましたが、Microsoft Azure や Google Cloud などでも同様の構成をとることができます。これで、上記のアーキテクチャの目的は達成できます。また、大容量で安定した通信が必要な場合はインターネット VPN の代わりに専用回線の導入を検討してコストとパフォーマンスのバランスをとることもできます。

構成上のポイント

このときのプライベートネットワーク構成のポイントを簡単にまとめます。

オンプレミスとクラウド間のプライベート接続
- VPN ルーターの冗長化 ( Active/Standby, HA機能が利用可能な機種の選定 ) や VPN 接続 (そのためのインターネット回線) 経路の冗長化、それらを適切に利用するためのネットワーク設計を実施する
オンプレミスのデバイスの、プライベートネットワーク内での AWS サービスの名前解決
- Amazon S3 などの AWS サービスのためのインターフェイス VPC エンドポイントを作成する
- Route 53 の [プライベートホストゾーン] を構成する
  (Amazon S3 ではオンプレミス側からのリージョン DNS 名による名前解決のために必要)
- Route 53 の VPC リゾルバーで [インバウンドエンドポイント] を作成する
- 単一障害点を回避するために VPC エンドポイントや Route 53 インバウンドエンドポイントは 2 つ以上のアベイラビリティゾーンを使用する
- オンプレミス側で、AWS サービスの名前解決を Route 53 インバウンドエンドポイントに転送する DNS フォワーダーを構成する
オンプレミスのデバイスへの、AWS IAM アクセスキーの永続的な配備を避けるために、IAM ロールを割り当てる
- 例として、AWS SSM ハイブリッドアクティベーションを適用

オンプレミスとクラウド間の通信を、インターネットを経由しないプライベートネットワーク内で完結させる場合、このように AWS サービスの DNS 名の名前解決を考慮したシステム構成が必要になります。

拠点数が少なく拡張予定が無い場合や既存ネットワークが整備されている場合は、従来の VPN 構成でも十分に要件を満たすケースがあります。一方で IoT プロジェクトでは、多数の拠点を短期間で接続する必要があるため、セルラー通信を利用した接続方式が適するケースも多く見られます。

SORACOM で実現するプライベートネットワーク接続を通じたオンプレミス IoT デバイスからの AWS 接続

それでは、SORACOM を利用する場合はどうでしょうか。前述のリファレンスアーキテクチャの目的と対応はそのままに、多拠点への展開で求められる「拠点追加の容易さ」と「運用ガバナンス」を、クラウドへのプライベート接続と SIM 運用のレイヤーでシンプルにする構成を示します。AWS 内のシステム構成は先程の例示した構成とほぼ同じですね。SORACOM との接続ポイントに違いがあります。

システム構成図とアーキテクチャの目的

各拠点のオンプレミスにあるデバイスやサーバーは LTE ルーターや IoT ゲートウェイに接続します。分析データの定期アップロードには、AWS CLI や AWS SDK などが利用できます。現場ユーザーは、特に意識することなく指定された宛先にデータを送信します。
LTE ルーターからの通信は、暗号化された無線区間や専用回線接続で構成されるセルラーネットワークを経由して SORACOM に到達します。SORACOM では VPG というお客様専用のネットワークゲートウェイを利用することによって、お客様の Amazon VPC と SORACOM の VPC がプライベートネットワーク接続を構成しています。VPG には外部通信のフィルタリング機能が具備されており、インターネットに抜ける経路を無効化することもできれば、特定の通信をフィルタリングすることもできます。
Amazon VPC に到着後は、冒頭の一般的なアーキテクチャと同様に、インターフェイス VPC エンドポイントを経由して S3 にアクセスします。

IoT プロジェクトではプライベート接続のアーキテクチャの目的にしばしば ”追加の要求” が現れます。

製造拠点や研究拠点、事業所などオンプレミスのデバイスやサーバーからプライベートネットワークを通じてクラウドに分析データを定期アップロードする
複数の地理的に分散した拠点をクラウドに接続する(*追加の要求:「拠点追加のスケール」(地理的分散) )
オンプレミスとクラウド間の通信はプライベートネットワーク内で閉じた通信とする
ネットワーク敷設のリードタイムを最小化しフィールドテストのトライアルから本番稼働可否への検証サイクルを迅速化する(*追加の要求: 「立ち上げ速度」(現地作業・回線調整の削減) )
システム構成内の単一障害点を極力排除する
サーバーレスな設計によりランニングコストと運用コストを抑えたアドホックな分析環境を構築する
BI ツールもウェブサービスとして利用することで高機能な分析環境を迅速に立ち上げる
現場ユーザーの運用負担を最小化しつつセキュリティレベルを確保する(*追加の要求: 「運用ガバナンス」(端末・SIM・通信の統制) )

これは、一般的なオンプレミスとクラウドのプライベート接続のアーキテクチャと比べて IoT プロジェクトでは分散した大小様々な拠点に対してプライベート接続を導入する必要があるという背景のためです。こうした “追加の要求” を実現するためにアーキテクチャの目的が複雑化しており、そうした “追加の要求” を実現するためには、各拠点にプライベート接続を導入するための工数や現場が担う運用負担をいかに最小化しつつ構成するかが重要となります。

この観点において、追加された要求: 「拠点追加のスケール」は、まさにセルラー通信網が日本全国やグローバルで利用できるメリットによって活かされます。そして特に「立ち上げ速度」と「運用ガバナンス」は、拠点ごとに VPN 装置と回線敷設工事を手配・設定を積み重ねる方式だと運用負担が厳しくなる領域ですが、SORACOM の IoT プラットフォームが活かせるポイントであり、プライベートネットワーク接続と SIM 管理機能を組み合わせることでシンプルに対応が可能です。

構成上のポイント

続いて、SORACOMを利用したプライベートネットワーク構成のポイントを簡単にまとめます。

オンプレミスとクラウド間のプライベート接続
- お客様の Amazon VPC と SORACOM の VPC の間のプライベートネットワーク接続は、AWS とのプライベート接続サービス SORACOM Canal を利用
  - SORACOM Canal では、VPG とお客様の Amazon VPC の間で VPC ピアリング接続や AWS Transit Gateway 接続などのプライベート接続を構成。いずれも システム担当者が意識することなく AWS が提供する冗長化設計を前提とした高い可用性を利用できる
  - SORACOM Canal や VPG は ユーザーコンソールで数時間とかからずセルフサービスで構築が完了するため、工事の日程調整や現地作業が不要
- SIMの差し替え利用を防ぐための IMEI ロック(特定の端末だけが IoT SIM を使用して通信できるように制限する機能) や想定していない通信量の発生を監視するためのイベントハンドラー (通信量をモニタリングし監視通知する機能) を設定し、不正や異常な利用を中央監視する
オンプレミスのデバイスの、プライベートネットワーク内での AWS サービスの名前解決
(基本的な設定内容は前述の一般的な構成と同様です*)
- Amazon S3 などの AWS サービスのためのインターフェイス VPC エンドポイントを作成する
- Route 53 の [プライベートホストゾーン] を構成する
  (Amazon S3 ではオンプレミス側からのリージョン DNS 名による名前解決のために必要)
- Route 53 の VPC リゾルバーで [インバウンドエンドポイント] を作成する
- 単一障害点を回避するために VPC エンドポイントや Route 53 インバウンドエンドポイントは 2 つ以上のアベイラビリティゾーンを使用する
- SORACOM の機能 “カスタム DNS” を対象の SIM グループで設定し、オンプレミスのデバイスによる AWS サービスの名前解決を Route 53 インバウンドエンドポイントに転送する ←ここだけ先程と異なります*
オンプレミスのデバイスへの、AWS IAM アクセスキーの永続的な配備を避けるために、IAM ロールを割り当てる
- 冒頭の “一般的なオンプレミス環境” の場合と同様に、AWS SSM ハイブリッドアクティベーションを適用
  - SORACOM での具体的な構成方法は以下のブログ記事を参照してください。

閉域網内でのAWS Systems ManagerによるIoT機器のリモートアクセスの構成と注意点 – SORACOM公式ブログ

SIM 認証に基づくセキュア・プロビジョニングサービス SORACOM Krypton を使用することで、オンプレミスのデバイスに対して、あらかじめ指定した IAM ロールの一時認証情報を Amazon Cognito Identity Pools から動的に払い出すことも可能

Getting Started: Cognito のクレデンシャルを取得し S3 からファイルをダウンロードする | SORACOM Krypton | ソラコムユーザーサイト – SORACOM Users

以上のように、SORACOM の通信とサービスを活用頂くことで、IoT プロジェクトでよくある要求事項に対応しながらオンプレミス (現場) の IoT デバイスからお客様の AWS までをインターネットを介さずに接続する構成が実現できます。

ポイント解説：プライベートネットワーク内での名前解決の流れ

プライベートネットワーク接続の設計でつまずきやすいのが AWS サービスの名前解決 (DNS) です。通信経路が正しくても、DNS 設計に不備があると「S3 に届かない」「疎通が不安定」といった事象が起きます。ここでは、構成や設定上のポイントと実際の名前解決の流れを整理します。

構築・設定のポイント

構成要素	設定項目	効果	ユーザーガイドへのリンク
VPC	[DNS ホスト名] および [DNS 解決] を有効化する	Route 53 VPC Resolver (以前の Amazon Provided DNS) を有効化し、VPC 上に DNS サービスを稼働する。これにより、プライベートホストゾーンへの DNS クエリに応答できる。	https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resolver.html
VPC – エンドポイント	接続対象の AWS サービスの [インターフェイスエンドポイント] を [プライベート DNS 名] を有効化して作成する^*1	インターネットを経由せずプライベートサブネットから AWS サービスにアクセスを提供する。 [プライベート DNS 名] を有効化することで、VPC 内からの AWS サービスのパブリック DNS 名へのリクエストがプライベート IP アドレスに解決できるプライベートホストゾーンと関連付ける。	https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/privatelink-access-aws-services.html#interface-endpoint-private-dns
Route 53	[プライベートホストゾーン] を作成し、S3 のパブリック DNS 名を VPC エンドポイント固有の DNS 名として解決するエイリアスレコードを設定する^*2	プライベートネットワークを通じて、オンプレミスなど VPC 外からの AWS サービスのパブリック DNS 名へのリクエストがプライベート IP アドレスに解決できる。	https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/hosted-zone-private-considerations.html
Route 53 – VPC リゾルバー	[インバウンドエンドポイント] を作成する	プライベートネットワークを通じて、オンプレミスなどVPC 外から Route 53 VPC Resolver へ DNS クエリを転送するためのエンドポイントを提供する。	https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html
SORACOM – SIM グループ	SIM グループに [カスタム DNS] として VPC Resolver のインバウンドエンドポイントを設定する	セルラー通信の確立時に、IoT デバイスに DNS サーバーとして、 VPC Resolver のインバウンドエンドポイントを通知する	https://users.soracom.io/ja-jp/docs/air/configure-custom-dns/

*1 エンドポイントのセキュリティグループでは、インバウンドアクセスの 53/TCP と 53/UDP を許可してください
*2 AWS サービスそのものではなく、アプリケーションサーバーで独自の DNS 名による名前解決を行う場合はプライベート IP アドレスに名前解決する A レコードを作成してください

実際の名前解決時のシーケンス

上記の表では、主に構築と設定時の項目とその効果について説明しました。これを設定フェーズとすると、実際の名前解決のフェーズ(制御フェーズ) とその後のデータ通信フェーズが存在します。そのシーケンスを図示したものが以下になります。このシーケンスのすべてが、VPG および SORACOM Canal による AWS とのプライベートネットワーク内で完結しています。

まとめ

オンプレミスとAWSのプライベートネットワーク接続のアーキテクチャを題材として、IoT 特有の追加の要求事項 { 「拠点追加のスケール」,「立ち上げ速度」, 「運用ガバナンス」 } が、SORACOM の活用でどのようにスムーズに構成できるかをご説明しました。

SORACOM の活用といってもシステム構成が特殊な形に変化するわけではなく、お客様の AWS から見ると、SORACOM の IoT プラットフォームも AWS (のVPC) であり、AWS VPC 同士のプライベートネットワーク接続におけるリファレンスアーキテクチャやベストプラクティスの大半を適用できることがお分かり頂けたかと思います。

分散した拠点、多数の IoT 機器であっても、SORACOM をハブとしてシンプルなプライベートネットワーク接続が構築できることは、構築時も運用保守時も大きなメリットになります。オンプレミス (現場) とクラウドのプライベートネットワーク接続の基本的なアーキテクチャとして参考になれば幸いです。

― ソラコム服部 (masa)

投稿 IoT リファレンスアーキテクチャ：多拠点とAWSのプライベート接続は SORACOM公式ブログに最初に表示されました。

ツイートする

soracom トップへ