Which IoT resources should be managed by CDK? |

Contents

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). Today I wanted to add an IoT Thing to the Thing Group using CDK.

Unfortunately, I failed due to races between Custom Resources.

1
2


Received response status [FAILED] from custom resource.
Message returned: Cannot find requested thing group for accountId

I tried to establish a dependency between those Custom Resources, but I failed yet again.

/posts/cdk_iot/cdk_iot_management.png

The thought

At this stage, I had the thought:

Which IoT resources should be managed by CDK?

I realized that, even for educational purposes, going too far from best practices is not a good idea.

The IoT system might have way more devices (represented as IoT Things) than the resource limit allowed by CloudFormation. Because of that, the management of IoT Things using CloudFormation will not scale and (in my opinion) should be avoided. As a consequence, the assignment of IoT Things to Thing Groups should not be handled by CloudFormation.

AWS Cloud Development Kit (CDK) generates the CloudFormation template under the hood - so CloudFormation constraints apply to the CDK.

The question

Which IoT resources should be managed by CDK/CF?

In my opinion, it is convenient to manage relatively static resources using CDK: IoT Policies, Role Aliases (and corresponding IAM Roles), IoT Rules, and Provisioning Templates.

I suggest creating X.509 Certificates, IoT Things and managing Thing Groups assignments via SDK or Provisioning Templates (depending on the actual use case).

This way we have full control over our IoT resources and we avoid the risk of hitting CloudFormation constraints.

Final thoughts

I wanted to use a single tool to keep my training materials easy to understand and follow. In the process, I realized my mistake - training materials should be easy to understand, but they must follow good practices (as clearly as possible).

Aws Iot