AWS IoT Greengrassは、工場のゲートウェイやラズパイなどのエッジ機器でLambda関数・コンテナ・自作プログラムを動かし、AWSから遠隔で配布・更新するためのオープンソースのランタイムとクラウドサービスです。この記事では、現行のV2の仕組み、Java版のnucleusと軽量版のnucleus liteの選び分け、東京リージョンの料金(Coreデバイス1台あたり月0.18ドル)、AWS IoT Coreとの違い、2026年10月7日にサポートが終了したV1からの移行までを、公式ドキュメントと料金データで確かめた数字で解説します。
まとめ:AWS IoT Greengrassの要点
- 役割:AWS IoT Coreがクラウド側の接続口、Greengrassはエッジ機器の中で処理を動かす実行環境。GreengrassのCoreデバイスもIoT Core経由でAWSにつながるので、両者は組み合わせて使う。
- 現行版:V2のみ。V1は2026年10月7日にサポートが終了し、V1のAPIとリソースはもう使えない。最新はnucleus 2.18.4(2026年10月14日)、nucleus lite 2.7.0(2026年9月25日)。
- 2つのランタイム:Java版nucleusはLinuxならCoreソフトウェア用にRAM 96MB以上とJRE 8以上が要り(追加するコンポーネントの分は別)、全機能に対応する。C製のnucleus liteはRAM 15MBで動くが、Lambda・ローカルMQTT機器の接続・シャドウは使えない。
- 料金:その月にAWSへ認証したCoreデバイス1台ごとに課金。東京は月0.18ドル、米国東部は0.16ドル。ローカルにつなぐ機器は無料。別にIoT Coreの接続・メッセージ料金がかかる。
- 採るべき場面:回線が切れても現場の処理を止められない、データ量をエッジで減らしたい、多数の機器のソフトを遠隔で更新したい場合。クラウドへ送るだけならIoT Core単体で足りる。
AWS IoT Greengrassの役割:エッジで動くランタイムとクラウドの管理機能
Greengrassは2つの部分でできています。1つはエッジ機器にインストールするGreengrass Coreソフトウェアで、この機器を「Coreデバイス」と呼びます。もう1つはAWS側のクラウドサービスで、どのCoreデバイスにどのソフトウェアを配るかを管理します。AWS公式ドキュメントはGreengrassを「オープンソースのIoTエッジランタイムおよびクラウドサービス」と定義しています。
読み方はグリーングラスです。用途は、クラウドで行っていた処理を現場に降ろすことです。設備の振動データを1秒ごとにクラウドへ送る代わりに、Coreデバイスで1分ごとの平均と最大値に集計して送る、カメラ映像をその場で推論して異常の画像だけを上げる、といった構成を組めます。エッジで処理する考え方そのものはエッジAIとは?クラウドAIとの違い・仕組み・実装の判断基準を解説で整理しています。
V2の構成要素:nucleus・コンポーネント・デプロイ
V2は、V1のひとかたまりのソフトウェアを「nucleus」と「コンポーネント」に分けました。必要な機能だけを機器に載せ、機能ごとに別々に更新できます。
nucleusとコンポーネントのレシピ
nucleusはCoreソフトウェアの中で必ず入れる部分で、デプロイの受け取り、コンポーネントの起動・停止、IPC(プロセス間通信)を担います。それ以外の機能はすべてコンポーネントです。AWSが提供するコンポーネントには、大量データをKinesisなどへ送るストリームマネージャー、ログをCloudWatch Logsへ送るログマネージャー、ローカルMQTTブローカーなどがあります。自作のコンポーネントは「レシピ」(YAMLまたはJSON)に、版番号・依存関係・インストールや起動時に実行するコマンドを書き、プログラム本体(アーティファクト)はS3に置きます。
デプロイとOTA更新の単位
配布はモノ(Thing)単位か、モノのグループ単位で行います。グループへのデプロイは継続的に効くので、後からグループに加えたCoreデバイスにも同じ構成が自動で届きます。多数の機器へのOTA更新もグループ単位で管理できます。本番では検証用グループで動作を確かめ、配布速度や失敗時の扱いを設定して展開します。
ローカル通信:IPCとMQTTブローカーのコンポーネント
Coreデバイス内のコンポーネント同士は、nucleusのIPCでローカルにpublish/subscribeできます。一方、センサー機器など別の機器をMQTTでCoreデバイスへつなぐ機能は、nucleusに組み込まれていません。AWS提供コンポーネントの一覧にある次の3つを追加でデプロイします。
- Client device auth:ローカル機器の証明書を検証し、接続を許可する。
- MQTTブローカー:MQTT 3.1.1のMoquetteか、MQTT 5のEMQXのどちらかを選ぶ。
- MQTT bridge:ローカル機器、コンポーネント間のpublish/subscribe、AWS IoT Coreの間でメッセージを中継する。
クラウドと切断されている間も、コンポーネントとIPCは動き続けます。ローカル機器のMQTT接続は条件付きで、切断中に機器が再接続するにはClient device authのオフライン認証を設定しておく必要があります。認証結果を信頼する期間clientDeviceTrustDurationMinutesの既定値は1分なので、想定する回線断の長さに合わせて延ばします。ブローカー製品の違いやTLS・ACLの設計はMQTTブローカーとは?仕組み・主要ブローカー比較とMosquittoでの構築手順【2.1対応】とMQTTセキュリティ|TLS 8883番・証明書認証・トピックACLの設計を実装目線で解説が詳しいです。
nucleusとnucleus liteの選び分け
2024年12月のGreengrass 2.14.0で、C言語で書かれた軽量なランタイム「nucleus lite」が加わりました。nucleus liteの公式ページによると、必要なのはRAM 15MBとストレージ5MBで、対象はsystemdを使うLinuxです。Java版nucleusはデバイス要件でLinuxならRAM 96MB以上(Windowsは160MB以上)、ディスク256MB以上を求めます。どちらも同じクラウドサービスから管理でき、1つのフリートに混在させられます。
差が出るのは使える機能です。機能の対応表から、選定に効く項目を抜き出しました。
| 機能 | nucleus(Linux) | nucleus(Windows) | nucleus lite |
|---|---|---|---|
| Lambda関数の実行 | 可 | 不可 | 不可 |
| Dockerコンテナの実行 | 可 | 可 | 可 |
| ローカルMQTT機器の接続 | 可 | 可 | 不可 |
| デバイスシャドウ | 可 | 可 | 不可 |
| ストリームマネージャー | 可 | 可 | 可 |
| Secrets Managerのシークレット | 可 | 可 | 不可 |
| DLR・TensorFlowでのML推論 | 可 | 可 | 不可 |
| インストーラの自動プロビジョニング | 可 | 可 | 不可 |
| TPMなどHSMでの鍵保管 | 可 | 不可 | 可 |
メモリに余裕があるゲートウェイ(ラズパイ4以降や産業用PC)ならnucleusを選びます。Lambdaコンポーネントを動かす、近くのセンサー機器をAWS提供のMQTTブローカーで束ねる、のどちらかが要る場合もnucleusです。ML推論は分けて考えます。AWS提供のDLR・TensorFlowの推論コンポーネントはnucleus専用ですが、推論ライブラリを同梱した自作プログラムやコンテナならnucleus liteでも配布できます。nucleus liteが向くのは、RAMが数十MBしかない組み込みLinuxで、自作プログラムやコンテナを配布・更新できれば十分な場合です。liteは版の進みが速く、GitHubの最新は2.7.0(2026年9月25日)ですが、公式ドキュメントの変更履歴は2.5.1までしか載っていない点にも注意してください。
エッジでの推論モデルの軽量化はTensorFlow Lite(LiteRT)とは?改称後の位置づけ・モデル変換・NPU実行を実装目線で解説を参照してください。なお、機能表に残っているAmazon Lookout for Vision連携は、サービス自体が2025年10月31日に終了しています(AWSの終了サービス一覧)。
AWS IoT CoreとGreengrassの違いと使い分け
AWS IoT Coreは、機器とAWSをMQTT・HTTPでつなぐクラウド側のメッセージブローカーです。Greengrassは機器の中で動く実行環境で、CoreデバイスはIoT Coreに接続してクラウドとやり取りします。二者択一ではなく、IoT Coreの上にGreengrassを重ねる関係です。
| 観点 | AWS IoT Core | AWS IoT Greengrass |
|---|---|---|
| 動く場所 | AWSクラウド | 手元のCoreデバイス |
| 役割 | 接続・認証・メッセージ配送 | ローカル実行・配布・更新 |
| 回線断の間 | 機器から届かない | ローカル処理を継続 |
| 課金 | 接続時間・メッセージ数 | Coreデバイスの台数 |
| 端末の条件 | マイコンでも可 | Linux・Windowsが動く機器 |
IoT Core単体で足りるのは、各機器が自分でクラウドへ送れて、判断もクラウドで済む構成です。Greengrassを重ねるのは、回線が切れても制御を止められない、送るデータを現場で減らしたい、機器のソフトを遠隔で入れ替えたい、のいずれかがある場合です。IoT Core側の料金や接続方法はAWS IoT Coreとは?料金の東京単価と月額試算・MQTT接続・はじめ方にまとめています。
Greengrassの料金:東京リージョンの単価と月額試算
Coreデバイスの台数で決まる課金
Greengrassの料金ページでは、その月にAWSへ認証したCoreデバイスを「アクティブ」とし、1台ごとに月額を課金します。AWSの料金データ(Price List)で確かめた単価は、東京・ソウル・シンガポール・フランクフルトなどが月0.18ドル、米国東部・米国西部(オレゴン)が月0.16ドルです。1万台を超える場合は個別見積もりです。
Coreデバイスにローカルでつなぐ機器は、何台でも追加料金はかかりません。月に一度もAWSへ認証しなかったCoreデバイスは課金されません。ただし、使わなくなった機器がIoT Coreへの認証を続けていると課金が続くので、nucleusを停止してGreengrassサービスから機器を削除するアンインストールまで行う必要があります。
IoT Coreの料金を含めた月額試算
実際の請求には、CoreデバイスがIoT Coreを使う分が加わります。東京のIoT Core単価は接続時間100万分あたり0.096ドル、メッセージ100万件あたり1.20ドル(月10億件まで)です。メッセージは5KB単位で数えるので、8KBのメッセージは2件になります(AWS IoT Coreの料金ページ)。
センサー100台が1秒に1回ずつ、1件5KB以内のデータを30日間送る場合で比べます。通常のMQTT送信を対象とし、Basic Ingest、受信側への配信、ルール実行、保存先サービス、税金、機器費用は含めません。
| 構成 | 月のメッセージ数 | 月額の目安 |
|---|---|---|
| 100台がIoT Coreへ直接送る | 2億5,920万件 | 約311ドル+接続0.41ドル |
| Greengrassで1分ごとに集計して送る | 4万3,200件 | 約0.05ドル+Core 0.18ドル |
集計後のメッセージは、100台分の平均・最大・最小を1件にまとめて5KB以内に収める前提です。課金上の件数はメッセージサイズを5KB単位で切り上げて数えるため、10KBなら2件、15KBなら3件になります。まとめる内容と送る間隔を先に決めておきます。Coreデバイス自身の接続料は1接続なら月約0.004ドルで、ほぼ無視できます。この試算ではメッセージ料金の削減額がGreengrassの月0.18ドルを上回ります。ただし、導入全体の採算は機器・開発・保守費用を加えて判断します。
無料枠の現状
料金ページには「毎月3台まで1年間無料」と書かれていますが、これは2025年7月15日より前に作ったAWSアカウントの12か月無料枠です。無料枠はアカウント作成日から12か月なので、2026年10月時点で期間が残っているアカウントはありません。IoT Coreの料金ページにあるとおり、2025年7月15日以降の新規アカウントは最大200ドルのクレジットを対象サービスに使う方式に変わっています。
Greengrass V1のサポート終了とV2への移行
V1からの移行ガイドは、2026年10月7日にV1のサポートが終了し、V1のAPIとリソースはもう使えないと告知しています。V1のCoreデバイスが現場に残っている場合、クラウドからの管理はできません。
V2はV1と互換性がなく、V1のOTA更新でV2へ上げることもできません。移行ガイドの手順は、まずV1とV2の概念の違いを確認し、ランタイムを選び、新しい検証用の機器でV1のアプリを動かしてから、既存の機器を1台ずつV2に入れ替える流れです。ランタイムの選び方で手間が変わります。
- nucleusへ移す:V1のLambda関数をLambdaコンポーネントとして取り込め、コードの修正は少ない。ローカルシャドウ、ローカル機器の接続、コネクタもV2の機能で置き換えられる。
- nucleus liteへ移す:Lambdaを汎用コンポーネントに書き直し、Greengrass Core SDKからAWS IoT Device SDK V2などへ乗り換える必要がある。ローカルシャドウ、ローカル機器、コネクタは使えない。
同じくサービスが終わったAWS Snowconeからエッジ処理を移す場合も、移行先の候補はGreengrassです。手順はAWS Snowconeとは:サービス終了後の現状とDataSync・Greengrassへの移行手順【2026年版】で解説しています。
Greengrass V2をインストールする手順(nucleus・Linux)
Coreデバイスの要件
Java版nucleusの要件はJRE 8以上(AWSはAmazon CorrettoかOpenJDKのLTS版を推奨)、glibc 2.25以上、RAM 96MB以上、ディスク256MB以上です。公式にテストされているCPUはArmv7l・Armv8(AArch64)・x86_64で、Windowsは10・11・Server 2019〜2025に対応します。/tmpがexec付きでマウントされていることも条件です。
Ubuntu 25.10以降には注意が要ります。既定のsudoが-E(環境変数の引き継ぎ)に対応しておらず、別ユーザーで動くコンポーネントが起動しません。sudo update-alternatives --set sudo /usr/bin/sudo.wsで従来のsudoに切り替えます。ラズパイをCoreデバイスにする場合は、先にラズパイとAWS IoT Coreを接続する手順|証明書・MQTT送信・SSH設定でIoT Coreとの疎通を確かめておくと、証明書やネットワークの問題を切り分けやすくなります。
インストーラによるAWSリソースの自動プロビジョニング
自動プロビジョニングの手順では、必要なIAM権限を持つ認証情報をAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYに設定し、一時認証情報の場合はAWS_SESSION_TOKENも設定します。そのうえで、最新のインストーラを取得して実行します。
curl -s https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-nucleus-latest.zip > greengrass-nucleus-latest.zip
unzip greengrass-nucleus-latest.zip -d GreengrassInstaller
sudo -E java -Droot="/greengrass/v2" -Dlog.store=FILE \
-jar ./GreengrassInstaller/lib/Greengrass.jar \
--aws-region ap-northeast-1 \
--thing-name MyGreengrassCore \
--thing-group-name MyGreengrassCoreGroup \
--thing-policy-name GreengrassV2IoTThingPolicy \
--tes-role-name GreengrassV2TokenExchangeRole \
--tes-role-alias-name GreengrassCoreTokenExchangeRoleAlias \
--component-default-user ggc_user:ggc_group \
--provision true \
--setup-system-service true
このコマンドは、モノ(Thing)・モノのグループ・IoTポリシー・トークン交換ロールを作り、ggc_userでコンポーネントを動かす設定にして、Greengrassをsystemdのサービスとして登録します。起動後はAWS IoTコンソールのGreengrassの画面にCoreデバイスが現れ、そこからコンポーネントをデプロイします。本番のフリートでは、機器ごとに強い権限の認証情報を置かずに済むフリートプロビジョニングへ切り替えます。
Greengrassの不採用条件:端末性能・通信量・Windowsの制約
次の条件に当てはまるなら、Greengrassを入れても運用の手間が増えるだけです。
- 端末がマイコン級:nucleus liteでもsystemdのLinuxとRAM 15MBが要る。ESP32などのマイコンはAWS IoT Device SDKやFreeRTOSで直接IoT Coreへつなぎ、Greengrassはその上のゲートウェイにだけ置く。
- 送る量が少なく、判断もクラウドで済む:1台が数分に1回送る程度ならメッセージ料金は小さく、エッジで集計する利点が出ない。IoT Core単体で構成を単純に保つ。
- WindowsでLambdaを動かしたい:WindowsのnucleusはLambda関数に対応していない。汎用コンポーネントで書くか、Linuxの機器を使う。
フリート全体の設定逸脱や不審な通信を監視する場合は、AWS IoT Device Defenderの機能・料金とDetectの新規利用停止を参照してください。Auditは引き続き利用できますが、不審な通信を検出するDetectは2026年8月31日から新規顧客への提供が停止され、既存顧客のみ利用を継続できます(nucleus liteはDevice Defenderに未対応)。現場の機器構成からエッジとクラウドの分担を決める段階で迷う場合は、AI/IoTソリューション開発の支援で設計から相談できます。
よくある質問
AWS IoT CoreとGreengrassはどちらを使えばよいですか?
クラウドにデータを送って処理するだけならIoT Core単体で足ります。回線断の間も現場の処理を続けたい、送るデータを減らしたい、機器のソフトを遠隔で更新したい場合にGreengrassを重ねます。GreengrassのCoreデバイスもIoT Core経由でクラウドにつながるので、排他ではありません。
Greengrassの料金はいくらですか?無料で試せますか?
その月にAWSへ認証したCoreデバイス1台あたり、東京リージョンで月0.18ドルです。旧来の「毎月3台まで12か月無料」は2025年7月15日より前に作ったアカウントの枠で、2026年10月時点では期間が残っていません。新しいアカウントは最大200ドルのクレジットで試せます。
Greengrass V1はまだ使えますか?
使えません。2026年10月7日にサポートが終了し、V1のAPIとリソースは利用できなくなりました。V1の機器はV2へ入れ替える必要があり、V1のOTA更新ではV2へ上げられません。
インターネットが切れてもGreengrassは動きますか?
クラウドへのアクセスを必要としないローカル処理やIPCは継続できます。ローカルMQTT機器が切断中も再接続できるようにするには、Client device authのオフライン認証を設定し、機器が一度オンラインで接続して認証情報を保存しておく必要があります。信頼期間clientDeviceTrustDurationMinutesの既定値は1分です。ローカルのMQTTブローカーは、Client device authとMoquetteまたはEMQXのコンポーネントを追加したときに使えます。
Greengrassはラズパイで動きますか?
動きます。Raspberry Pi OSなどArmv7lまたはAArch64のLinuxで、JRE 8以上を入れればJava版nucleusを使えます。メモリの少ない機種や自作の組み込みLinuxでは、RAM 15MBで動くnucleus liteも選べます。