developersIO
AWS IoT Greengrass Coreデバイスが利用するエンドポイントを調査してみた

AWS IoT Greengrass Coreデバイスが利用するエンドポイントを調査してみた

AWS IoT GreengrassAWS IoT CoreAWS IoTGrafana
FacebookHatena blogX
2026.03.05

はじめに

ファイアウォールなどを利用している環境でAWS IoT Greengrass(以下Greengrass)を利用していると、Greengrass Coreデバイスがどのエンドポイントに対して、どのプロトコル、ポートを利用しているか気になることがあると思います。
しかし、それを把握するには複数のドキュメントを読み解き、GreengrassのドキュメントだけではなくIoT Coreのドキュメントも確認する必要があります。

一度調べて分かったつもりになっても時間をあけて再度確認すると、いつも頭の中がリセットされた状態からスタートしてしまうので、そんな未来の自分のためにも記事として残しておきたいと思います。

対応表

早速ですがエンドポイント、プロトコル、ポートの対応表です。
括弧で書かれている値についてはオプションで設定が変更できます。

サービス 操作種別 エンドポイント名 プロトコル ポート 説明
IoT Greengrass コントロールプレーン greengrass.<region>.amazonaws.com HTTPS 443 ・コンポーネント、デバイス、デプロイメントの管理など
IoT デバイス運用 <prefix>-ats.iot.<region>.amazonaws.com MQTT
HTTPS		 8883, (443)
8443, (443)		 ・シャドウ同期などの AWS IoT デバイス管理操作など
・IoT CoreのIoTデータエンドポイントと同じ
データプレーン greengrass-ats.iot.<region>.amazonaws.com
(<prefix>-ats.iot.<region>.amazonaws.com)		 HTTPS
MQTT		 8443, (443)
8883, (443)		 ・デプロイメントのインストールやクライアントデバイスの操作など
・Nucleus設定によりIoTデータエンドポイントと共通化可能
IoT Core コントロールプレーン iot.<region>.amazonaws.com HTTPS 443 ・AWS IoTリソース（モノ、証明書、ポリシー等）の作成/管理など
・自動プロビジョニングにも使用
データプレーン <prefix>-ats.iot.<region>.amazonaws.com MQTT
HTTPS		 8883, (443)
8443, (443)		 ・MQTT通信およびデバイス管理のためのデータプレーン操作など
認証情報プロバイダー <prefix>.credentials.iot.<region>.amazonaws.com HTTPS 443 ・AWS認証情報の取得(S3等のAWSサービスと直接通信する際に利用)
S3 デプロイ用 *.s3.amazonaws.com
*.s3.<region>.amazonaws.com		 HTTPS 443 ・デプロイ時のコンポーネントアーティファクト取得に使用
コンポーネント(例) ログマネージャー logs.<region>.amazonaws.com HTTPS 443 ・CloudWatch Logs へのログアップロード

また、これを図にするとこんな感じになります。
Pasted image 20260301211640

う〜ん、複雑ですね。
では、この表と図をベースに細かい部分を以下に説明していきます。

デフォルトのプロトコルとポート

まずは、デフォルトのプロトコルとポート、およびその変更方法について紹介します。
Greengrassを利用する場合、NucleusはデフォルトでHTTPSは8443、MQTTは8883を利用します。
社内のファイアウォールやProxyでポートを解放できないこともあると思います。
こういった場合は利用するポートを443に変更することも可能です。

イメージ図としてAWSのBlack Beltにわかりやすいスライドがありましたので拝借しております。
CleanShot 2026-02-28 at 16.04.17@2x
参照: https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2025_AWS-IoT-Greengrass-Network-Security_0131_v1.pdf

443ポートを利用するにはNucleusで以下の設定が必要です。
なお、443ポートを利用する場合は以下の制限があります。

参照: Nucleus設定ドキュメント

MQTTを443に変更

MQTTを443に変更する場合は、Nucleusコンポーネントの設定で mqtt.port を 443 に指定します。
デプロイ時の設定例

{
     "mqtt": {
        "port": 443
      }
}

インストール時に設定する場合、--init-config オプションで設定ファイルを指定し、以下を含めます

services:
  aws.greengrass.Nucleus:
    configuration:
      mqtt:
        port: 443

MQTTでポート443を使用する場合、認証方式がクライアント証明書認証からデバイスサービスロール認証に変わります。
そのため、必要に応じてToken Exchange Roleに権限を追加する必要があります。

HTTPSを443に変更

HTTPSを443に変更する場合は、Nucleusコンポーネントの設定で greengrassDataPlanePort を 443 に設定します。
デプロイ時の設定例

{
      "greengrassDataPlanePort": 443
}

インストール時に設定する場合、--init-config オプションで設定ファイルを指定し、以下を含めます

services:
  aws.greengrass.Nucleus:
    configuration:
      greengrassDataPlanePort: 443

HTTPSでポート443を使用する場合、TLS拡張(ALPN)を使用するため、Java 8 update 252以降（またはJava 9以降）が必要です。特に閉域環境などJavaのバージョンが古い可能性がある環境では事前に確認しておきましょう。

Greengrassのサービスエンドポイント

Greengrassのサービスエンドポイントは以下の3つの操作をサポートしています。

  • コントロールプレーン操作
  • AWS IoTデバイスの操作
  • データプレーン操作

https://docs.aws.amazon.com/general/latest/gr/greengrassv2.html
それぞれの操作がざっくりどういった系統の操作を実行するかはドキュメントに記載されていますが、具体的にどの操作がどのAPIに紐づいているかについては明記されていません。

では、それぞれのエンドポイントの特徴を見ていきましょう。

コントロールプレーン操作

コントロールプレーン操作はGreengrassがコンポーネント、デバイス、およびデプロイメントを管理する操作です。
エンドポイントは greengrass.<region>.amazonaws.com で、プロトコルはHTTPSです。

操作の内容的に、Greengrass Coreデバイスから実行するというよりAWSのマネジメントコンソールなど、開発者がGreengrass CoreデバイスをAWS上で管理する際に利用するAPIだと思います。
後述のやってみたの中でもGreengrass CoreデバイスからAWSへの通信で greengrass.<region>.amazonaws.com への通信は発生していません。

AWS IoTデバイス操作

AWS IoTデバイス操作はAWSリージョン固有の Amazon Trust Services (ATS) エンドポイントで、後述するIoT Coreのデータプレーンエンドポイントと同じになります。
このエンドポイントはアカウントごとに異なるエンドポイントでAWS CLIで aws iot describe-endpoint --endpoint-type iot:Data-ATS コマンドを実行することで取得できます。
このエンドポイントを利用する操作でサポートされているアクションはドキュメントに記載があります。
参照: https://docs.aws.amazon.com/iot/latest/apireference/API_Operations_AWS_IoT_Data_Plane.html

この操作は接続の削除や、MQTTメッセージのパブリッシュなどをサポートしています。
エンドポイントは <prefix>-ats.iot.<region>.amazonaws.com で、プロトコルはHTTPSとMQTTです。
HTTPSとMQTTの使い分けですが、デバイスからパブリッシュのみの操作はHTTPSを利用して、パブリッシュとサブスクライブどちらも必要な操作はMQTTを利用するようです。

データプレーン操作

データプレーン操作は、ResolveComponentCandidates等のデータプレーン操作をサポートしているようですが、他にどのようなAPIをサポートしているかは明示的には記載がありません。
データプレーン操作は、デフォルトではgreengrass-ats.iot.<region>.amazonaws.com が使用されます。
ただし、上記のエンドポイントは現在レガシーエンドポイントとされており、ATSエンドポイントを使用することが推奨されています。

AWS IoT Greengrass uses the AWS IoT Core Region-specific ATS endpoints for data plane operations, such as ResolveComponentCandidates. For a complete list, see AWS IoT Core - data plane endpoints. You must set greengrassDataPlaneEndpoint to iotdata. For more information, see AWS IoT Greengrass nucleus configuration.
参照: https://docs.aws.amazon.com/general/latest/gr/greengrassv2.html

このATSエンドポイントはAWS IoTデバイス操作と同じ <prefix>-ats.iot.<region>.amazonaws.com で、プロトコルはHTTPSとMQTTです。
つまり、データプレーン操作とIoTデバイス操作は同じエンドポイントを使用することになります。

また、ATSエンドポイントを使用するためにはNucleus設定のgreengrassDataPlaneEndpointをiotdataに設定する必要があります。

デプロイ時の設定例

{
  "greengrassDataPlaneEndpoint": "iotdata"
}

プロビジョニング時のconfig.yamlで設定する場合

services:
  aws.greengrass.Nucleus:
    configuration:
      greengrassDataPlaneEndpoint: "iotdata"

Greengrassのエンドポイントはここまでです。
次はIoT Coreのエンドポイントです。

IoT Coreのエンドポイント

Greengrass CoreデバイスはGreengrassのエンドポイント以外にもIoT Coreのエンドポイントとも通信をします。
IoT Coreのエンドポイントは次の通りです。

  • コントロールプレーンエンドポイント
  • データプレーンエンドポイント
  • 認証情報プロバイダーエンドポイント
  • AWS IoT FIPSエンドポイント（特定のセキュリティ要件でのみ利用するため今回は触れません）

https://docs.aws.amazon.com/general/latest/gr/iot-core.html#iot-core-data-plane-endpoints

コントロールプレーンエンドポイント

コントロールプレーンエンドポイントは、AWS IoTリソース（モノ、証明書、ポリシー等）の作成・管理を行うための操作をサポートしています。
エンドポイントは iot.<region>.amazonaws.com で、プロトコルはHTTPSです。

Greengrassのコントロールプレーン操作と同様に、主にAWSマネジメントコンソールやCLIからIoT Coreのリソースを管理する際に利用されるエンドポイントです。
Greengrassの自動プロビジョニング時にはモノや証明書の作成のために、このエンドポイントへの通信が発生します。
後述のやってみたの際にも最初の自動プロビジョニング時のみこのエンドポイントへの通信が発生しています。

データプレーンエンドポイント

データプレーンエンドポイントは、MQTT通信やデバイスシャドウの操作など、デバイスとのデータのやりとりをサポートしています。
エンドポイントは <prefix>-ats.iot.<region>.amazonaws.com で、プロトコルはMQTTとHTTPSです。

このエンドポイントはGreengrassの「AWS IoTデバイス操作」で利用しているエンドポイントと同じです。
アカウントごとに異なるエンドポイントが割り当てられており、AWS CLIで aws iot describe-endpoint --endpoint-type iot:Data-ATS コマンドを実行することで取得できます。
例

$ aws iot describe-endpoint --endpoint-type iot:Data-ATS
{
    "endpointAddress": "<prefix>-ats.iot.ap-northeast-1.amazonaws.com"
}

認証情報プロバイダーエンドポイント

認証情報プロバイダーエンドポイントは、IoTデバイスがAWSサービスに直接アクセスするための一時的なAWS認証情報を取得する際に利用されます。
エンドポイントは <prefix>.credentials.iot.<region>.amazonaws.com で、プロトコルはHTTPSです。

Greengrass CoreデバイスがS3からコンポーネントアーティファクトをダウンロードしたり、CloudWatch Logsにログを出力する際など、AWS サービスへ直接アクセスが必要な場合にこのエンドポイントから認証情報を取得します。
アカウントごとに異なるエンドポイントが割り当てられており、AWS CLIで aws iot describe-endpoint --endpoint-type iot:CredentialProvider コマンドを実行することで取得できます。
例

$ aws iot describe-endpoint --endpoint-type iot:CredentialProvider
{
    "endpointAddress": "<prefix>.credentials.iot.ap-northeast-1.amazonaws.com"
}

これでIoT Coreのエンドポイントも出揃いました。

ダウンロード時のエンドポイント

次にデプロイ用のエンドポイントとして以下の2つが挙げられています。
*.s3.amazonaws.com, *.s3.<region>.amazonaws.com
このエンドポイントはデプロイの際に、S3バケットからコンポーネントを取得するためのエンドポイントになります。
プロトコルはHTTPSで、ポートは443です。
コンポーネントの取得はS3バケットに直接アクセスするため443を使用します。

注意点として、ファイアウォール側の制約で * が使えないといったケースもあるかと思います。
この場合は具体的にコンポーネントを保管しているエンドポイントを指定する必要があります。
カスタムコンポーネントであれば、自身の作成したS3バケットを指定します。
しかし、パブリックコンポーネントの場合は、AWSが管理するS3バケットからコンポーネントを取得する必要があります。
今回後述の「やってみた」の中でパブリックコンポーネントを取得したところ evergreencomponentmanageme-artifactbucket7410c9ef-x81b4h9rizzn.s3.ap-northeast-1.amazonaws.com への通信が確認できました。

この記事には書いていませんが、他のパブリックコンポーネントや古いバージョンのパブリックコンポーネントをダウンロードする際もこのエンドポイントから取得していました。
現時点ではこのエンドポイントを使用していますが、ドキュメントにはこのエンドポイントが明記されていないため、変更される可能性も0ではないと考えられます。
なので、S3バケットのエンドポイントは * で指定できるなら、その方が無難だと思います。

パブリックコンポーネントのエンドポイント

最後にパブリックコンポーネントのエンドポイントですが、上の表では例としてログマネージャーコンポーネントのエンドポイントを記載しています。
エンドポイントは logs.<region>.amazonaws.com で、プロトコルはHTTPSで、ポートは443です。
パブリックコンポーネントはコンポーネントごとにドキュメントが存在するため、自分の利用するコンポーネントのドキュメントで使用するエンドポイントとプロトコル、ポートを確認しましょう。
https://docs.aws.amazon.com/ja_jp/greengrass/v2/developerguide/public-components.html

自動プロビジョニング

Greengrassの自動プロビジョニングでインストールする場合、上記のエンドポイントに加えて以下のエンドポイントへの通信が発生します。
これは自動プロビジョニング時にデバイスからAWSサービスを操作するために必要なエンドポイントになります。

エンドポイント ポート 必須 説明
iot.<region>.amazonaws.com 443 Yes AWS IoTリソースの作成および既存リソースの情報取得に使用
iam.amazonaws.com 443 Yes IAMリソースの作成および既存リソースの情報取得に使用
sts.<region>.amazonaws.com 443 Yes AWSアカウントIDの取得に使用
greengrass.<region>.amazonaws.com 443 No --deploy-dev-tools 引数を使用してGreengrass CLIコンポーネントをデプロイする場合に必要

参照: プロキシまたはファイアウォールを介したデバイストラフィックを許可する

これで一通りのエンドポイントを書き出しました。
それでは実際にGreengrass Coreデバイスを動かしながらどのような通信が発生するのか見てみましょう。

やってみた

検証用のGreengrass Coreデバイス(EC2)が配置されたVPCのVPC Flow LogとDNSクエリログを取得して、どこにどのプロトコルで通信しているか監視してみました。
Athenaで毎度クエリすると面倒なので、GrafanaのダッシュボードでポートやDNSクエリの相関ダッシュボードを作成しました。

自動プロビジョニング

まずはGreengrassのデバイスを自動プロビジョニングした際の通信を確認していきます。

ダッシュボードの見方は、
上(表): エンドポイント、ポート番号、プロトコルの対応表
下(棒グラフ): エンドポイント別のタイムライン(エンドポイントごとに何KBの通信が発生したかをタイムラインで表示)
です。
このダッシュボードにより、どのエンドポイントにどのポート、プロトコルで通信しているのか。
そして、通信が何か操作をしたタイミングだけ発生しているのか、常時通信しているのかを確認することができます。

CleanShot 2026-02-23 at 17.21.30@2x
この結果はGreengrass Coreデバイスを自動プロビジョニングして、しばらく放置した際の結果です。
16:00あたりにプロビジョニングが実行されています。
宛先のエンドポイント名とプロトコル、ポートは公式ドキュメント「自動プロビジョニングによるインストールのエンドポイント」に記載の必須項目の通り
sts.ap-northeast-1.amazonaws.com, iot.ap-northeast-1.amazonaws.com, iam.amazonaws.com
にそれぞれ通信が発生しています。
https://docs.aws.amazon.com/greengrass/v2/developerguide/allow-device-traffic.html

ドキュメントに記載されていない <prefix>-ats.iot.ap-northeast-1.amazonaws.com との通信も発生しています。
これは常時IoT Coreとの通信用に利用されているのだと思います。
インストール完了後は <prefix>-ats.iot.ap-northeast-1.amazonaws.com のみ定期的に通信が発生しています。

デプロイの更新

まずはNucleusのみの状態（コンポーネント追加なし）でデプロイを更新します。
17:25あたりにデプロイの更新が実行されています。
CleanShot 2026-03-01 at 21.06.47@2x
Nucleusのみ更新した場合は
<prefix>-ats.iot.ap-northeast-1.amazonaws.com(8883) と greengrass-ats.iot.ap-northeast-1.amazonaws.com(8443) に通信が発生しています。
インストール時に発生していたiamやstsといったエンドポイントに対する通信は発生していません。

新たに発生している greengrass-ats.iot.ap-northeast-1.amazonaws.com はGreengrassのデータプレーン操作のデフォルトのエンドポイントです。

Greengrass データプレーン操作のエンドポイントを変更

前述しましたが、Greengrass データプレーン操作のエンドポイントはATS エンドポイントに変更することが推奨されています。
それでは、Greengrassのデータプレーン操作のエンドポイントをATS エンドポイント <prefix>-ats.iot.<region>.amazonaws.com に変更します。
デプロイ更新時にNucleusの設定を以下に変更します。

{
  "greengrassDataPlaneEndpoint": "iotdata"
}

それではタイムラインを確認してみます。
CleanShot 2026-02-23 at 19.25.12@2x
greengrass-ats.iot.ap-northeast-1.amazonaws.com への通信が消えて、 <prefix>-ats.iot.ap-northeast-1.amazonaws.com のみ通信が発生していますね。
また、ポートを確認すると8883と8443が利用されています。

ポートを443に変更

次はデフォルトのポートを変更してみます。
デフォルトは8883, 8443を利用しているので、これを443に変更します。
同じようにNucleusの設定を以下に変更します。

{
     "mqtt": {
        "port": 443
      },
      "greengrassDataPlanePort": 443
}

それではタイムラインを確認してみます。
CleanShot 2026-03-01 at 21.08.18@2x
全ての通信が443に変更されていますね。

パブリックコンポーネントの追加

次はパブリックコンポーネントをデプロイしてみます。
今回は aws.greengrass.LogManager をデプロイして、CloudWatch Logsにログを出力してみます。
CleanShot 2026-02-26 at 10.18.58@2x 1
新しいエンドポイントへの通信が確認できました。
新たに evergreencomponentmanageme-artifactbucket7410c9ef-x81b4h9rizzn.s3.ap-northeast-1.amazonaws.com というエンドポイントへの通信が発生しています。
このエンドポイントはGreengrassのパブリックコンポーネントが置かれたAWSの管理するS3バケットです。
パブリックコンポーネントを取得するためにAWS管理のS3にアクセスしていることが確認できました。

上記の設定タイミングでLogManagerコンポーネントを使ってCloudWatch Logsにログを出力する設定を忘れていたので追加します。
CleanShot 2026-02-26 at 11.14.21@2x
CloudWatch Logsへのログ出力設定を追加すると新たに logs.ap-northeast-1.amazonaws.com と <prefix>.credentials.iot.ap-northeast-1.amazonaws.com への通信が発生しています。
これはGreengrass CoreデバイスがCloudWatch Logsに直接ログを出力するために、
<prefix>.credentials.iot.ap-northeast-1.amazonaws.com から認証情報を取得して
logs.ap-northeast-1.amazonaws.com にログを出力していることが分かります。

パブリックコンポーネントによって必要なエンドポイントが変わるため、利用するコンポーネントのドキュメントから確認しましょう。

まとめ

今回はGreengrass Coreデバイスが利用するエンドポイントをドキュメントから整理し、さらにGrafanaを使って実際の通信先を確認してみました。
Greengrassはデバイスの構築・管理・デプロイを簡単に行える便利なサービスですが、裏側ではIoT Core、S3、CloudWatch Logsなど複数のサービスと連携しており、通信先のエンドポイントも多岐にわたります。
普段はこうした通信先を意識する必要はありませんが、ファイアウォールやProxyの設定でエンドポイントやポートを厳密に管理する必要がある場合は、途端に難易度が上がるように感じました。
全ての操作を網羅的に..とまではいきませんが、ベースとなる通信はある程度確認できたかと思います。
この記事がどなたかの助けとなれば幸いです。

この記事をシェアする

FacebookHatena blogX

関連記事

AWS IoT Greengrass Core デバイスの HTTPS に利用するポート番号を確認してみた
市田善久
2025.09.25
AWS IoT Greengrass AI Agents Context Packがリリース！AI エージェントでデバイスアプリケーションを開発してみた
市田善久
2025.11.07
Greengrass ユーザー必見！AWS IoT Greengrass の新しいインストール方法を試す
市田善久
2025.02.05
AWS IoT Core の Black Belt を読んだのでまとめてみる
くろすけ
2026.01.25