AWS IoT Core のカスタムドメインを利用してコネクテッドデバイスを AWS に移行する

この記事は Daniele Crestini, Ajinkya Farsole, Prateek Prakash によって投稿された Migrating connected device fleets to AWS with Custom Domains for AWS IoT Core を翻訳したものです。

はじめに

AWS は、お客様がカスタムドメイン名で AWS IoT Core のデータエンドポイントの動作をカスタマイズできる新機能 Configurable Endpoints with Custom Domains for AWS IoT Core を提供開始しました。カスタムドメインは、お客様が独自のカスタムドメイン名と関連するサーバー証明書を AWS IoT Core のエンドポイントに登録することを可能にします。

この新機能は、AWS のお客様が社内外のセキュリティやコンプライアンスの要件に準拠することを支援し、IoT デバイスの AWS IoT への移行をよりシンプルにし、ディザスタリカバリを目的としたフェイルオーバー戦略の実装を助け、複数の AWS リージョンを用いた利用シナリオを容易に構築することができます。

この記事では、Configurable Endpoints を使用して、既存の IoT ソリューションから AWS IoT への IoT デバイスの移行を簡素化し、迅速に行う方法を紹介します。

IoT デバイスを移行する際の課題

コネクテッドデバイス群を AWS IoT Core に移行することは、IoT 移行のジャーニーの重要なタスクです。デバイスは、ユーザーやデータと同様に、IoT バリューチェーンの中心的なリソースであり、その移行も同様に信頼性が高く、高速でなければなりません。AWS IoT へのデバイスの移行では、ファームウェアや、接続に使用する IoT エンドポイントや認証方法などのソフトウェア設定の更新がしばしば行われます。しかし、地理的に異なる地域に分散している大規模なデバイス群(数千から数百万ものデバイス)の大規模なアップデートを実行すると、以下のようないくつかの課題が生じる可能性があります。

1. IoT デバイスから amazonaws.com への接続が許可されない場合がある

セキュリティとコンプライアンスに関する組織の戦略的決定により、会社が所有するドメインやサーバ証明書を使用し、独自の秘密鍵基盤(PKI)と認証局を管理する必要があるかもしれません。つまり、IoT アプリケーションは、iot.yourcompany.example.com のような自社のプライベートまたはパブリックドメイン上にエンドポイントを公開し、そこにデバイスを接続することになります。このシナリオでは、デバイスのソフトウェアをアップグレードしない限り、標準の .amazonaws.com ドメインを使用することができません。

例1: 組織のサイバーセキュリティポリシーにより、IoT デバイスは AWS に移行できない

2. 大規模な無線アップグレード(OTA)は避けたい場合がある

デバイスの設定を再構成するための大規模な OTA (Over The Air Upgrade) を簡単に実行できない状況があります。これは、ファームウェアの開発と検証に長い時間がかかることや、フリートの特定の地域では接続が限定的であるため、リモートでのデバイスのアップグレードが信頼できないことが原因です。

例2: OTA アップグレードによる移行(左)と DNS レコード変更による移行(右)

デバイスのファームウェアにカスタムドメイン名を使用すると、OTA アップグレードを行う代わりに、Domain Name System (DNS; シングルポイントモディファイ) の Canonical Name (CNAME) レコードを更新するだけで済むため、移行作業が容易になります。これにより、Incremental migrations を実行するための加重ルーティングなど、DNS の他の利点を活用できます。

3. 管理すべきデバイスファミリーが異なる場合がある

お客様のフリートには様々なデバイスアーキテクチャがあり、それぞれが異なる信頼できるエンドポイントや認証メカニズムを必要とする場合があります。レガシーデバイスをサポートするためには、各ファミリーに複数の設定可能なエンドポイントが必要です。

例3: 複数のデバイスファミリーが同じ AWS IoT Core のエンドポイントにまとめられる場合

ソリューションの概要: AWS IoT Core のカスタムドメインを使った IoT デバイスの移行

次の図は、IoT デバイスの移行に AWS IoT Core のカスタムドメインを使用する方法を示しています。

AWS IoT Core のカスタムドメインを使用した移行のリファレンスアーキテクチャ

このソリューションでは、以下のサービスを活用しています。

Domain Name Service (DNS) としての Route 53。この例では、既存の IoT アプリケーションから AWS へのトラフィックをルーティングするために、シンプルルーティングポリシーを設定します。
メインサーバーの証明書ストアとして AWS Certificate Manager (ACM) を使用します。この例では、ACM を使用して、プライベート認証局 (CA) から発行されたサーバー証明書と、ドメインの所有権を検証するために使用されるパブリックサーバー証明書を保存します。
移行先の IoT エンドポイントとして AWS IoT Core を使用します。この例では、AWS IoT Core に IoT デバイスをオンボードし、サンプルのドメイン名でカスタムエンドポイント構成を設定します。

前提条件

この手順では、以下の前提条件が必要です。

AWS アカウント。
AWS Command Line Interface (CLI)。AWS CLI のインストールと設定の方法については、AWS CLI ドキュメントを参照してください。
CLI を通じて AWS リソースを作成するための資格を持つ AWS IAM ユーザー。
カスタムエンドポイントの設定に使用するドメイン名。Route 53 で登録したドメインや、他の DNS プロバイダーで登録したドメインにも Route 53 を使用することができます。
AWS IoT Core に接続するための要件を満たす、AWS に移行させたいデバイス。
テストを行うための MQTT クライアント。この手順では、Eclipse Mosquitto MQTT Client を使用します。
(オプション) CA から発行されたサーバー証明書と、ドメインの所有権を検証するための秘密鍵。サーバー証明書やプライベート CA を所有していない場合は、AWS を通じてリクエストすることができます。この手順では、両方のシナリオをカバーしています。

デバイス証明書に関する注意点: この手順では、カスタムドメイン機能の動作をテストするために、新しいデバイス証明書を生成しています。すでに独自のデバイス証明書をお持ちの場合は、その証明書をインポートしてテストを行うことができます。

お持ちの AWS アカウントでのソリューションの実装

この例では、AWS IoT Core と Configurable Endpoints を使って、移行元の IoT エンドポイントを同じ AWS アカウントの別のリージョンでシミュレートします。この記事では、このソリューションを実装するための以下のステップを説明します。

ステップ1: 登録したドメイン名で Route 53 のホストゾーンを構成します。
ステップ2: 選択した AWS リージョンで、移行対象の IoT エンドポイントを設定します。この例では、エンドポイントをアイルランド(eu-west-1) リージョンに設定します。これには以下が含まれます。
- AWS Certificate Manager (ACM) で証明書チェーンを登録すること。
- サーバー証明書を使用して、AWS IoT Core にカスタムドメインを設定する。
- AWS IoT Core でデバイス証明書と IoT ポリシーを作成するか、自分のものをインポートする。
ステップ3: Route 53 に CNAME レコードを設定してトラフィックをルーティングし、MQTT クライアントでテストを実行します。

ステップ1：Route 53 でホストゾーンを設定する

この例では、登録したドメイン名 example.com を管理するために、Route 53 でホストゾーンを作成します。

コマンドラインのターミナルウィンドウを開きます。
Route 53 を使用してドメインを登録した場合、ホストゾーンは自動的に作成されます。ドメインが別の場所で登録されている場合は、次のコマンドを実行して Route 53 にホストゾーンを作成します。
aws route53 create-hosted-zone --name example.com --caller-reference 2021-05-04-18:30
このコマンドの出力として、Route 53 がホストゾーンに割り当てた ID が表示されます。ホストゾーンの ID は、以下のコマンドで確認することもできます。
aws route53 list-hosted-zones

次のコマンドを実行して、ホストされたゾーンに関連するネームサーバーを取得します。
aws route53 get-hosted-zone --id <Hosted_Zone_ID>
レスポンス (JSON):

...
"DelegationSet": {
       "NameServers": [
           "ns-1769.awsdns-29.co.uk",
           "ns-955.awsdns-55.net",
           "ns-113.awsdns-14.com",
           "ns-1256.awsdns-29.org"
        ]
}
...

Route 53 以外のドメイン業者をご利用の場合は、ドメイン業者の管理コンソールで、ホストゾーンのネームサーバーを設定してください。これにより、Route 53 を使用してドメインを管理することができます。

ステップ2a: 移行対象の IoT エンドポイントの設定 – ACM での証明書チェーンの登録

カスタム IoT ドメインのサーバー証明書を所有していない場合は、ACM を通じてサーバー証明書を要求できます。独自のサーバー証明書を所有している場合は、証明書に署名するために使用されているルート CA 証明書が Mozilla の trusted ca-bundle に含まれているかどうかを確認します。含まれていれば、ACM で証明書チェーンをインポートすることができます。含まれていない場合は、ACM で証明書チェーンをインポートし、さらに ACM を通じてパブリック証明書を要求します。

以下の手順では、両方のシナリオの例を示します。

シナリオi）カスタム IoT ドメイン用のサーバー証明書を所有していない場合

以下のコマンドを実行してリクエストを発行します。aws acm request-certificate –-domain-name iot.example.com –-validation-method DNS --region <AWS_Region>
レスポンスからサーバー証明書の ARN をメモします。
```
{
   "CertificateArn": "arn:aws:acm:eu-west-1:XXXXXXXXXXXXXXXXX:certificate/<certificate_id>"
}
```

続いて、証明書のドメイン検証パラメータを記述することで、DNS の設定パラメータ(太字)を取得することができます。

aws acm describe-certificate --certificate-arn arn:aws:acm:eu-west-1:XXXXXXXXXXXXXXXXX:certificate/<certificate_id> --region eu-west-1

レスポンスの例:

{
    "Certificate": {
      "CertificateArn": "arn:aws:acm:eu-west-1:<account_id>:certificate/<ceritficate_id>",
……
           "ValidationStatus": "PENDING_VALIDATION",
           "ResourceRecord": {
               "Name": "_XXXXXXXXXXXXXXXXXXXXX.iot.example.com.",
               "Type": "CNAME",
               "Value": "_XXXXXXXXXXXXXXXXXXXXX.XXXXXXXXXXX.acm-validations.aws."
     },
…
}

30分以内に、ステータスが PENDING_VALIDATION から SUCCESS に変わります。ステータスが変わったら、取得したパラメータを使って、以下の構文で records.json というファイルを作成します。

{
    "Comment": "Create ACM Validation Record",
    "Changes": [
        {
            "Action":  "UPSERT",
            "ResourceRecordSet":
            {
                "Name": "_XXXXXXXXXXXXXXXXXXXXX.iot.example.com.",
                "Type":"CNAME",
                "TTL": 300,
                "ResourceRecords": [
                    {
                        "Value": "_XXXXXXXXXXXXXXXXXXXXX.XXXXXXXXXXX.acm-validations.aws."
                    }
                ]
            }
        }
    ]
}

ここで以下のコマンドを実行して、Route 53 のホストゾーンにレコードを追加します。aws route53 change-resource-record-sets --hosted-zone-id <your_hosted_zone_id> --change-batch file://records.json

AWS マネジメントコンソールの ACM で、サーバー証明書が検証状態「成功」で表示されるのがわかります。

ACM でパブリックサーバーの証明書が検証済みのステータスとなっている

AWSマネジメントコンソールの Route 53 > ホストゾーン > <作成したホストゾーン名> で、先ほど追加した CNAME レコードが Route 53 に表示されていることも確認できます。

Route 53 ホストゾーンの DNS 検証用レコード

シナリオii）Mozilla の ca-bundle に含まれる認証局によって署名されたカスタム IoT ドメイン用のサーバー証明書を所有している。

この操作を実行するには、次のリソースが必要です。

Certificate.pem という名前のファイルに格納されている PEM エンコードされたサーバー証明書。
CertificateChain.pem という名前のファイルに格納されている、PEM エンコードされた証明書チェーン。
PrivateKey.pem という名前のファイルに格納されている PEM エンコードされた秘密鍵。

サーバー証明書チェーンを設定するには、以下の手順に従います。

コマンドラインのターミナルウィンドウを開きます。
以下のコマンドを実行して、サーバー証明書をインポートします。
aws acm import-certificate –-certificate fileb://Certificate.pem –-certificate-chain fileb://CertificateChain.pem –-private-key fileb://PrivateKey.pem --region <AWS_Region>

ステップ2b: 移行先の IoT エンドポイントの設定 – 登録したサーバー証明書を使って AWS IoT Core にカスタムドメインを設定

この操作を実行するには、登録済みのサーバー証明書の ARN と自分のドメイン名が必要です。

ターミナルウィンドウを開きます。
以下のコマンドを実行して、ACM に登録されているサーバー証明書を確認し、その “CertificateArn” の値をメモします。
aws acm list-certificates –region <your_AWS_Region>
レスポンス:
```
{
    "CertificateSummaryList": [
        {
            "CertificateArn": "arn:aws:acm:eu-west-1:XXXXXXXXXXXXXXXXX:certificate/<certificate_id>",
            "DomainName": "iot.example.com"
        }
    ]
}
```
以下のコマンドを実行して、AWS IoT Core にカスタムドメインを登録します。
aws iot create-domain-configuration --domain-configuration-name "TargetTestIoTPlatform" --service-type "DATA" --domain-name "iot.example.com" --server-certificate-arns "arn:aws:acm:eu-west-1:XXXXXXXXXXXXXXXXX:certificate/<certificate_id>"

これで対象リージョンの AWS IoT Core にカスタムドメインの設定ができ、AWS マネジメントコンソールの AWS IoT > 設定で設定が表示されます。

AWS IoT Core の設定でのカスタムドメイン設定

ステップ2c: 移行先の IoT エンドポイントの設定 – デバイス証明書の作成、AWS IoT Core での IoT ポリシーの作成

フリート内のデバイスは、接続先の IoT エンドポイントで有効なアイデンティティと IoT ポリシーが必要です。ベストプラクティスとして、プロビジョニングフローでは、パブリックインターネット上での秘密鍵の共有を回避できるようにする必要があり、IoT デバイス設計の一部としてプロビジョニングフローを組み込むことをお勧めします。

AWS は、AWS IoT Core のドキュメントの一部として、デバイスプロビジョニングのためのオプションのリストを提供し、実際の顧客のシナリオに関して各オプションを詳しく説明した “Device Manufacturing and Provisioning with X.509 Certificates in AWS IoT Core” ホワイトペーパーを提供しています。

オプションのステップ：自分のデバイス証明書を持ち込む

AWS IoT Core に既存のデバイス証明書と CA 証明書をインポートすることで、スムーズな移行を可能にし、OTA を実行したり、デバイスが既存の PKI を介して証明書をローテーションする必要がなくなります。また、AWS IoT Core に登録されていない CA で署名されたデバイス証明書を登録することもできます。詳細については、AWS IoT Core のドキュメント CA 証明書の登録とクライアント証明書を手動で登録するを参照してください。

なお、インポートできるデバイス証明書は、AWS IoT Core でサポートされている規格に準拠している必要があります。追加の詳細については、X.509 クライアント証明書の AWS IoT Core ドキュメントを参照してください。

今回の例では、CLI を使ってテスト用のモノ、デバイス証明書、IoT ポリシーを作成します。まず、テスト用の IoT デバイスそれぞれのアイデンティティを作成します。

コマンドラインのターミナルウィンドウを開きます。

以下のコマンドを実行して、デバイス証明書とキーペアを生成します。ファイルはローカルに作成されます。
aws iot create-keys-and-certificate \
--certificate-pem-outfile "TestThing.cert.pem" \
--public-key-outfile "TestThing.public.key" \
--private-key-outfile "TestThing.private.key" \
--region <your_AWS_Region>
レスポンス:

{
    "certificateArn": "arn:aws:iot:eu-west-1:XXXXXXXXXXXXXXXXX:cert/<certificate_id>",
    "certificateId": "<certificate_id>",
    "certificatePem": "-----BEGIN CERTIFICATE----- […] -----END CERTIFICATE-----",
    "keyPair": {
        "PublicKey": "-----BEGIN PUBLIC KEY----- […] -----END PUBLIC KEY-----",
        "PrivateKey": "-----BEGIN RSA PRIVATE KEY----- […] -----END RSA PRIVATE KEY-----"
    }
}

コマンドの出力から “certificateArn” と “certificateId” をコピーします。
以下のコマンドを実行して、デバイスレジストリにモノを作成します。
aws iot create-thing \
--thing-name TestThing \
--region <your_AWS_Region>

モノのポリシー変数を使って IoT ポリシーを作成し、接続している IoT デバイスに対して最小権限の原則を適用します。ベストプラクティスとして、可能な限りポリシー変数を使用してください。以下の内容の TestPolicy.json ファイルを作成します。

{
  "Version": "2012-10-17",
  "Statement": [{
       "Effect": "Allow",
       "Action": [
         "iot:Publish"
       ],
       "Resource": [
         "arn:aws:iot:eu-west-1:XXXXXXXXXXXXXXXXX:topic/test/device/${iot:Connection.Thing.ThingName}"
       ]
   },
   {
       "Effect": "Allow",
       "Action": [
          "iot:Connect"
       ],
       "Resource": [
         "arn:aws:iot:eu-west-1:XXXXXXXXXXXXXXXXX:client/${iot:Connection.Thing.ThingName}"
       ]
   }
  ]
}

以下のコマンドを実行して、AWS IoT Core にポリシーを登録します。
aws iot create-policy \
--policy-name TestPolicy \
--policy-document file://TestPolicy.json \
--region <your_AWS_Region>
ポリシーをデバイス証明書にアタッチし、デバイス証明書をモノにアタッチします。以下のコマンドを実行して、IoT ポリシーをデバイス証明書にアタッチします(証明書の ARN が必要です)。
aws iot attach-policy \
--policy-name TestPolicy \
--target <your__device_certificate_ARN> \
--region <your_AWS_Region>
最後に、以下のコマンドを実行して、デバイス証明書をモノにアタッチします。
aws iot attach-thing-principal \
--thing-name TestThing \
--principal <your_device_certificate_ARN> \
--region <your_AWS_Region>

AWS IoT コンソールから AWS アカウントに登録されたモノ、ポリシー、デバイス証明書を確認します。

ステップ3: Route 53 の CNAME レコードの設定

設定プロセスの最後のステップは、あなたのドメイン名から AWS IoT Core エンドポイントへのルーティングを実装するために、DNS に CNAME レコードを作成することです。

最低限の設定として、希望する AWS IoT Core エンドポイントをターゲットとして、ホストゾーンに CNAME レコードを作成する必要があります。以下の CLI コマンドで、AWS IoT Core エンドポイントを特定できます。aws iot describe-endpoint --endpoint-type iot:Data-ATS —region <your_AWS_Region>

Route 53 を使用する場合は、利用可能なルーティングメカニズムを使用して、ブルー/グリーンデプロイを実行するために加重ルーティングを使用したり、あるエンドポイントから別のエンドポイントにトラフィックを徐々にシフトしたりするなど、より複雑なシナリオを実装することができます。

Route 53 を使用してシンプルルーティングポリシーを作成するには、以下の手順に従います。

コマンドラインのターミナルウィンドウを開きます。

simpleRoutingRecords.json という名前のファイルを以下の内容で作成します。

{
   "Comment": "Create Simple Routing CNAME records ",
   "Changes": [{
       "Action": "UPSERT",
       "ResourceRecordSet": {
            "Name": "iot.example.com.",
            "Type": "CNAME",
            "TTL": 300,
            "ResourceRecords": [{
               "Value": "<prefix>-ats.iot.eu-west-1.amazonaws.com"
            }]
        }
   }]
}

以下のコマンドを実行して、Route 53 のホストゾーンにレコードを追加します。aws route53 change-resource-record-sets --hosted-zone-id <hosted_zone_id> --change-batch file://simpleRoutingRecords.json

これが完了すると、Route 53 のホストゾーンに新しいレコードが表示されます。

Route53 でのシンプルルーティングの CNAME レコード

ソリューションのテスト

次に、前提条件の中でダウンロードした Eclipse Mosquitto MQTT クライアントを使用して、iot.example.com として登録したターゲットプラットフォームのエンドポイントにテスト MQTT メッセージを送信します。これにより、設定したルーティングポリシーとマイグレーションが期待通りに機能したことを確認できます。

ソリューションをテストするための要件

手順のステップ2c で作成し、ファイルとして保存された PEM エンコードされたデバイス証明書と秘密鍵。この例では、TestThing.cert.pem と TestThing.private.key の2つのファイルが必要です。
AWS IoT Core のルート CA 証明書。この例では、RSA 2048ビットの鍵を使用します: Amazon Root CA 1

ソリューションをテストする手順

デバイス証明書、秘密鍵、Amazon Root CA ファイルがあるターゲットフォルダでターミナルウィンドウを開きます。
あなたの AWS アカウントで AWS IoT コンソールを開き、MQTT テストクライアントに移動します。テストクライアントはテスト > MQTT テストクライアントで見つけることができます。

AWS IoT Core コンソールの MQTT テストクライアント
トピックのフィルターボックスに “test/device/TestThing” と入力し、サブスクライブを選択してウィンドウを開いたままにします。
ターミナルウィンドウで、以下のコマンドを実行します。mosquitto_pub -h iot.example.com --cafile AmazonRootCA1.pem --cert TestThing.cert.pem --key TestThing.private.key -p 8883 -q 1 -d -t test/device/TestThing -i TestThing -m "{\"message\": \"helloFromTestThing\"}"
AWS IoT Core のテストクライアントコンソールで、メッセージが表示されることを確認します。

AWS IoT Core コンソールの MQTT テストクライアントで受信したテストメッセージ

リソースのクリーンアップ

AWS アカウントへの不要な課金を防ぐために、この手順で使用した AWS リソースを削除します。これらの AWS リソースには、AWS IoT Core、AWS Certificate Manager、Route 53 が含まれます。AWS CLI、AWS マネジメントコンソール、または AWS API を使用してクリーンアップを行うことができます。このセクションでは、AWS CLI のアプローチを示します。これらのリソースを残しておきたい場合は、このセクションを無視しても構いません。

DNS の設定の無効化

以下の内容のファイルを作成します。この例では、ファイル名を change-resource-record-sets.json とします。

{
  "Comment": "Delete the CNAME Record Set",
  "Changes": [
      {
          "Action": "DELETE",
          "ResourceRecordSet": {
              "Name": "iot.example.com",
              "Type": "CNAME",
              "TTL": 300,
              "ResourceRecords": [
                  {
                      "Value": "<prefix>-ats.iot.eu-west-1.amazonaws.com"
                  }
              ]
          }
     },
     {
          "Action": "DELETE",
          "ResourceRecordSet": {
              "Name": "_XXXXXXXXXXXXXXXXXXXXX.iot.example.com",
              "Type": "CNAME",
              "TTL": 300,
              "ResourceRecords": [
                  {
                      "Value": "_XXXXXXXXXXXXXXXXXXXXX.XXXXXXXXXXX.acm-validations.aws."
                  }
              ]
          }
      }
   ]
 }

以下の CLI コマンドでレコードを削除します。
aws route53 change-resource-record-sets --hosted-zone-id <your_hosted_zone_id> --change-batch file://change-resource-record-sets.json
以下の CLI コマンドでホストゾーンを削除します。
aws route53 delete-hosted-zone --id <your_hosted_zone_id>

AWS IoT Core リソースのクリーンアップ

以下の CLI コマンドを使用して、IoT ポリシーからデバイス証明書をデタッチします。
aws iot detach-policy --target "arn:aws:iot:eu-west-1:XXXXXXXXXXXXXXXXX:cert/<certificate_id>" --policy-name "TestPolicy"
以下の CLI コマンドで IoT ポリシーを削除します。
aws iot delete-policy --policy-name TestPolicy
以下の CLI コマンドを使用して、テスト用のモノからデバイス証明書を切り離します。
aws iot detach-thing-principal --thing-name TestThing --principal arn:aws:iot:eu-west-1:XXXXXXXXXXXXXXXXX:cert/<certificate_id>
以下の CLI コマンドで、AWS IoT Core からデバイス証明書を削除します。
aws iot delete-certificate --certificate-id <certificate_id>
次の CLI コマンドを使用して、AWS IoT Core からモノを削除します。
aws iot delete-thing --thing-name TestThing

カスタムドメイン構成の無効化

次の CLIコマンドを使用して、AWS IoT Core のカスタムドメイン構成のステータスを無効にします。
aws iot update-domain-configuration --domain-configuration-name "TargetTestIoTPlatform" --domain-configuration-status "DISABLED"
以下の CLI コマンドを使用して、AWS IoT Core のカスタムドメイン設定を削除します。
aws iot delete-domain-configuration --domain-configuration-name "TargetTestIoTPlatform"
次の CLI コマンドを使用して、ACM でインポートおよび要求されたすべてのサーバー証明書を削除します。
aws acm delete-certificate --certificate-arn arn:aws:acm:eu-west-1:XXXXXXXXXXXXXXXXX:certificate/<certificate_id>

まとめ

この記事では、IoT デバイス群を AWS に移行する際にお客様が直面する主な課題と、AWS IoT Core の Configurable Endpoints がどのようにプロセスを簡素化できるかについて説明しました。このブログで提案されているアーキテクチャと例は、IoT デバイス群の AWS へのシームレスな移行を可能にするために採用できるソリューションを提供し、IoT アプリケーションに必要となる将来の移行ニーズをよりシンプルに管理するための基礎を築きます。

提供されている実装例を使って、自分で機能をテストし、AWS IoT Core、Route 53、AWS Certificate Manager に必要なリソースを設定することができます。より柔軟性を高めるために、AWS IoT Core に独自のデバイス証明書や CA 証明書を持ち込むこともできます。AWS IoT Core の Configurable Endpoints の使用方法の詳細については、ドキュメントを参照することができます。

AWS IoT への移行に興味がありますか？

AWSは、LG, Traeger Grills, Belkin, Centrica Hive, Weissbeerger などのお客様が、自社開発またはサードパーティ製の IoT プラットフォームから迅速かつ容易に移行することを支援してきました。これらのお客様は、AWS の IoT サービスのセキュリティ、スケーラビリティ、信頼性、そして広さと深さを活用するために移行しました。

AWS IoT 移行ソリューションページでは、AWS がどのようにお客様の移行を迅速かつ容易にすることができるかをご紹介しています。また、お問い合わせいただければ、お客様のユースケースを相談する時間を設けさせていただきます。

著者について

Daniele は、AWS プロフェッショナルサービスのシニア IoT データアーキテクトです。彼は、AWS クラウド上で AWS IoT サービスを活用した革新的なソリューションを設計・構築することで、AWS カスタマーのビジネス目標達成を支援しています。

Prateek は、AWS プロフェッショナルサービス Global Speciality Practice のシニア IoT アーキテクトです。彼は、AWS IoT および関連サービスを利用した最新のアプリケーションプラットフォームを設計・構築することで、AWS カスタマーのビジネス成果の達成を支援しています。

Ajinkya Farsole は、AWS プロフェッショナルサービスのクラウドインフラストラクチャアーキテクトです。彼は、AWS クラウド上で安全でスケーラブルなソリューションを構築することで、お客様の目標達成を支援しています。仕事以外では、物理学や歴史のドキュメンタリー番組を見るのが好きです。

この記事はソリューションアーキテクトの三平が翻訳しました。

Amazon Web Services ブログ