Intro While working on the AWS IoT Greengrass training, I had the following thought: Which IoT resources should be managed by CDK? For educational purposes, I wanted to declare every single component required by Greengrass using CDK. I was aware that was not the best practice approach, but I wanted to present important concepts regarding Greengrass. In my previous post, I demonstrated how to create a Thing Group (natively not supported by CDK or CloudFormation).

How to create an IoT Thing Group using CDK? By default, we can not manage IoT Thing Groups using AWS Cloud Development Kit (CDK). CDK deploys infrastructure using CloudFormation and CloudFormation does not support Thing Groups. Today I want to share an elegant solution for this challenge. CDK Constructor I propose to create a custom CDK Constructor. Constructor represents a specific resource and enables the management of the corresponding AWS infrastructure.

I am losing money! Customers are not using my IoT system as they are supposed to! LM: First of all - congratulations! Your system delivers value for users! Not every IoT deployment does. Owner: But customers are not using my IoT system as they are supposed to and I am losing money! LM: That is often the case when customers are interacting with the solution differently than estimated in the business case.

Increased usage of an IoT service would decrease your margin! In what scenario the above statement could be true? The only possible reason that comes to my mind is poor service design. Areas of the increased costs due to the poor service design include: extra staff required to manually onboard and manage IoT devices manually over-provisioned cloud infrastructure to meet increased demand extra developers hired for fixing backend bottlenecks (when increased infrastructure does not fix the poor design issues) the churn of customers due to poor service quality All of the above leads to increased expenses and decreased income.

IoT device generates a running cost for the service provider. That fact is often overlooked by companies during PoC verification. In the long run, a connected device might cost more to operate than the income it generates for its provider. At a minimum, every connected device requires: connectivity to send telemetry data to a backend system processing capabilities of a backed system to analyze the telemetry data storage capabilities of a backend system to store data personnel to support customers and maintain backend infrastructure Depending on the specific service/product, the above cost factors may differ.

Introduction During the Internet of Things engagements, we need to adapt our solution to the capabilities offered by existing hardware and/or firmware. In some cases, our devices might not be able to use “fancy” MQTT clients. Is there a way to connect those devices to the AWS IoT Core? One of the possible options is to use the HTTPS protocol to publish messages from those devices to AWS. Limitations of the HTTPS protocol Before I present how can we send messages to AWS IoT Core using the HTTPS protocol, I want to underline some important limitations of this approach: