Un'azienda gestisce una soluzione IoT con milioni di sensori domestici negli Stati Uniti. I sensori utilizzano MQTT per inviare dati a un broker MQTT personalizzato su una singola istanza EC2. I sensori si connettono al broker all'indirizzo iot.example.com (Route 53). Il broker scrive i dati su DynamoDB. Il broker è stato sovraccaricato più volte, causando la perdita di dati. Quale soluzione migliorerà l'affidabilità e soddisferà i requisiti?

La soluzione corretta sfrutta AWS IoT Core, un servizio gestito e scalabile progettato specificamente per la gestione di milioni di dispositivi IoT e l'ingestione di dati MQTT. Sostituendo il broker MQTT personalizzato su EC2 con IoT Core, si risolve il problema del sovraccarico e della perdita di dati, poiché IoT Core gestisce automaticamente la scalabilità e l'affidabilità. La configurazione di un nome di dominio personalizzato e l'aggiornamento del record Route 53 all'endpoint Data-ATS di IoT Core garantiscono una transizione fluida per i sensori esistenti. Le regole di IoT Core permettono di instradare facilmente i dati a DynamoDB, mantenendo la logica di archiviazione attuale. Le opzioni errate presentano i seguenti problemi: L'uso di ALB/Auto Scaling per il broker MQTT personalizzato, pur migliorando la scalabilità, non risolve intrinsecamente i problemi di affidabilità e complessità di gestione di un broker MQTT self-hosted su larga scala. L'NLB con Global Accelerator migliora le prestazioni e la disponibilità, ma non risolve la gestione del broker MQTT self-hosted e la sua scalabilità intrinseca per milioni di connessioni MQTT. AWS IoT Greengrass è per l'edge computing e non è un sostituto diretto per un broker MQTT centralizzato per milioni di sensori che inviano dati al cloud.