Alternative à AWS IoT Core : quand un broker MQTT standard est plus simple

Une alternative à AWS IoT Core a du sens lorsque votre projet a davantage besoin d'un broker MQTT standard que d'une plateforme IoT propre à un cloud. Ce guide explique ce qu'offre AWS IoT Core, quelles différences évaluer, comment se comparent les modèles d'authentification et dans quels cas un broker MQTT managé conforme aux standards est la voie la plus simple, avec du code pour tester les deux.

Ce qu'AWS IoT Core fait bien

AWS IoT Core est un service managé qui connecte les appareils au cloud AWS. Au-delà d'un endpoint MQTT, il propose un registre et une identité des appareils, une authentification par certificats X.509, des politiques IoT fines, des device shadows et un moteur de règles qui route les messages vers d'autres services AWS. Si votre back-end vit déjà chez AWS et que vous voulez faire circuler les données des appareils vers les services AWS avec peu de code d'intégration, c'est la principale raison de le choisir.

Cet article ne cherche pas à dire si AWS IoT Core est bon ; il s'agit de savoir s'il a la bonne forme pour votre projet. AWS met régulièrement le service à jour : vérifiez chaque point précis dans le guide du développeur AWS IoT Core actuel.

Quand les équipes cherchent une alternative

Les raisons se répartissent généralement en quelques groupes :

• Il leur faut un simple broker. Le projet concerne la messagerie entre appareils et applications, un tableau de bord ou un hub de données industrielles, pas un pipeline de données AWS.
• Leur back-end n'est pas chez AWS. Il tourne sur un autre cloud, sur site ou dans un environnement mixte.
• Les frictions d'enrôlement. Le provisioning de certificats par appareil est une sécurité solide, mais ajoute des étapes pour les prototypes, les salles de cours et les petites flottes.
• Les enjeux de portabilité. Elles veulent des appareils capables de changer de broker en modifiant quelques paramètres.
• Des modèles tarifaires prévisibles. Certaines équipes préfèrent une tarification par plan à une facturation à l'usage. Lequel est le moins cher dépend entièrement de votre charge.

Ce qu'il faut évaluer : AWS IoT Core ou un broker MQTT standard

AWS publie une page décrivant les points sur lesquels son implémentation MQTT diffère de la spécification MQTT. Lisez-la en parallèle de vos exigences. Le tableau liste ce qu'il faut vérifier plutôt que d'affirmer des détails actuels.

Les deux dernières lignes sont celles où AWS IoT Core offre davantage en natif. Si elles sont au cœur de votre conception, il est peut-être le meilleur choix.

La différence de modèle d'authentification

C'est souvent la plus grande différence en pratique.

Un appareil AWS IoT Core typique détient un certificat client et une clé privée, ainsi que l'autorité de certification racine d'Amazon, et se connecte en TLS mutuel. Les politiques attachées au certificat déterminent ce qu'il peut publier et ce à quoi il peut s'abonner. C'est un modèle solide qui, à grande échelle, nécessite un processus de provisioning.

Un broker standard comme ConnectMQ utilise un TLS côté serveur avec un nom d'utilisateur, un mot de passe et un client ID délivrés dans un portail. Les appareils vérifient le certificat Let's Encrypt du broker à l'aide du magasin de CA du système, et le client ID est lié aux identifiants délivrés. Le démarrage est plus simple ; votre responsabilité est de stocker les identifiants de façon sûre sur les appareils.

Aucun n'est universellement meilleur. Évaluez quel modèle la taille de votre flotte, vos exigences de sécurité et votre processus de fabrication peuvent supporter.

Écrire un code d'appareil compatible avec les deux

La meilleure façon d'éviter la dépendance est d'isoler les détails de connexion de la logique applicative. Cet exemple MQTT.js v5 se connecte soit avec un certificat (à la manière d'AWS IoT Core), soit avec un nom d'utilisateur et un mot de passe (broker standard), et le reste du code reste identique :

// npm install mqtt
const fs = require("fs");
const mqtt = require("mqtt");

const mode = process.env.BROKER_MODE || "standard"; // "standard" ou "certificate"

const options = {
  clientId: process.env.MQTT_CLIENT_ID || "YOUR_CLIENT_ID",
  protocolVersion: 5,
  reconnectPeriod: 5000,
};

let url;
if (mode === "certificate") {
  url = `mqtts://${process.env.MQTT_ENDPOINT}:8883`;
  options.key = fs.readFileSync("device.private.key");
  options.cert = fs.readFileSync("device.cert.pem");
  options.ca = fs.readFileSync("root-ca.pem");
} else {
  url = "mqtts://broker.connectmq.com:8883";
  options.username = process.env.MQTT_USERNAME || "YOUR_USERNAME";
  options.password = process.env.MQTT_PASSWORD || "YOUR_PASSWORD";
}

const client = mqtt.connect(url, options);
const topic = "site1/area1/pump7/telemetry";

client.on("connect", () => {
  console.log("Connected in", mode, "mode");
  setInterval(() => {
    const reading = { pressure: 2.4 + Math.random() * 0.2, ts: Date.now() };
    client.publish(topic, JSON.stringify(reading), { qos: 1 });
  }, 5000);
});

client.on("error", (err) => console.error("MQTT error:", err.message));

Gardez les noms de topics exempts de préfixes propres au fournisseur et évitez que le firmware des appareils dépende de fonctionnalités exclusives à un fournisseur. Changer de fournisseur devient alors une simple modification de configuration. L'article sur la dépendance fournisseur MQTT liste les schémas à surveiller.

Remplacer les fonctionnalités propres à AWS

Si vous passez à un simple broker, prévoyez comment couvrir les fonctionnalités que vous utilisiez :

1. Moteur de règles. Exécutez un service abonné, un flow Node-RED ou un agent Telegraf qui lit les topics et écrit dans votre base de données ou votre API.
2. Device shadows. Publiez l'état souhaité et l'état rapporté sur des topics retenus comme site1/area1/pump7/state/reported et .../state/desired.
3. Identité de la flotte. Délivrez un jeu d'identifiants par appareil et tenez un inventaire dans votre propre système.
4. Supervision. Utilisez le topic d'état de connexion du broker ($SYS/broker/connection/{clientId}/state sur ConnectMQ) et le tableau de bord du portail.

Un chemin de migration à faible risque

Si vous décidez de déplacer tout ou partie de vos appareils, procédez par étapes plutôt qu'en une seule bascule :

1. Commencer par un miroir. Exécutez un petit service de bridge qui s'abonne à certains topics sur l'endpoint existant et les republie vers le nouveau broker. Les tableaux de bord et les nouveaux consommateurs peuvent alors passer sur le nouveau broker pendant que les appareils restent en place.
2. Piloter un groupe d'appareils. Reflashez ou reconfigurez un petit lot d'appareils avec le nouvel endpoint et les nouveaux identifiants. Observez le comportement de reconnexion, les débits de messages et la taille des payloads au regard des limites du nouveau plan.
3. Déplacer les intégrations. Remplacez chaque règle par un abonné externe ou un flow Node-RED, une destination de données à la fois, et comparez les sorties côte à côte.
4. Basculer la flotte par vagues, en gardant l'ancienne configuration disponible pour un retour arrière jusqu'à ce que chaque vague soit stable.

Comme les deux côtés parlent MQTT, chaque étape est réversible, et c'est la principale raison de garder le firmware exempt de dépendances propres à un fournisseur.

Une liste de décision

• L'essentiel de votre back-end est-il chez AWS, et utilisez-vous intensivement le moteur de règles ? AWS IoT Core est probablement le meilleur choix.
• Vous faut-il un broker neutre pour des appareils, des applications et des systèmes sur site répartis entre plusieurs environnements ? Un broker standard est plus simple.
• Avez-vous besoin de QoS 2 ou de fonctionnalités MQTT 5 précises ? Vérifiez la prise en charge actuelle des deux côtés.
• Le provisioning de certificats par appareil est-il réaliste pour vous aujourd'hui ?
• Votre équipe peut-elle exploiter les intégrations qu'un broker léger délègue à des outils externes ?

Essayez un broker conforme aux standards

Vous pouvez évaluer l'alternative sans rien migrer. Créez un broker Serverless gratuit sans carte bancaire, exécutez le script ci-dessus en mode standard et inspectez le trafic dans l'explorateur de topics en direct. Pour de simples essais de protocole sans compte, le serveur MQTT public gratuit broker.connectmq.com suffit, à condition de n'y publier que des données de test, jamais de données de production. Pour plus de contexte, lisez le guide du broker MQTT cloud, comparez avec l'alternative à Azure IoT Hub et voyez en quoi un broker MQTT managé diffère d'une plateforme IoT. Plus d'informations sur connectmq.com.

Questions fréquentes

Des appareils conçus pour AWS IoT Core peuvent-ils se connecter à un autre broker MQTT ?

Oui, s'ils utilisent du MQTT standard. En général, vous changez l'endpoint, remplacez l'authentification par certificat par la méthode du nouveau broker et supprimez toute utilisation de topics propres à AWS.

Un broker standard remplace-t-il le moteur de règles d'AWS IoT ?

Pas à lui seul. Vous ajoutez un abonné externe, Node-RED ou Telegraf pour router les données, ce qui garde chaque élément remplaçable.

AWS IoT Core est-il plus sûr qu'un broker à nom d'utilisateur et mot de passe ?

Le TLS mutuel avec des certificats par appareil est un modèle solide. Un broker utilisant TLS avec des identifiants uniques par appareil est lui aussi fiable lorsque les identifiants sont correctement stockés et renouvelés.

Où vérifier les limites d'AWS IoT Core ?

Consultez le guide du développeur AWS IoT Core et les pages de quotas de service à jour, car les limites et les fonctionnalités prises en charge évoluent.