Recently, I had to significantly redesign the database structure of an IoT platform I designed one month ago. Changing the database forced the adaptation of the backend logic*, which demanded my extra attention and careful testing. During that change, I was constantly questioning my initial reasoning and my ability to design solutions. “That was obviously a wrong decision! Why does that setup not support this access pattern?!?!" Once my frustration level dropped a bit, I had yet another reflection - “There was no way I could have predicted all of that one month ago”.

The initial connectivity of IoT devices to the AWS Cloud can be a major hurdle, impacting user experience and project success. Every device is unique, and ensuring secure, seamless onboarding for thousands of units presents significant manufacturing and operational challenges. I’ve seen my customers struggle with these issues for years. Finally, I decided to encode my experience and develop a device provisioning module that simplifies this process. It allows you to securely connect any device to your AWS account without requiring expertise in AWS or a large IT department.

There is no technical debt, only an investment opportunity in education or future business returns. The effort of fixing the consequences of bad decisions is part of the price you have to pay. The only loss happens when you fail to acknowledge the “debt” and choose to pretend it is not there. I designed and built numerous IoT systems, and I made countless mistakes in the process. The truth is that when you start creating something innovative, you have no clue if your design decisions are correct or not; there is no way to predict the long-term impact of the way you structure the early version of your system.

Amazon Timestream for LiveAnalytics will no longer be open to new customers starting June 20, 2025. That is very bad news for numerous AWS IoT deployments. I deployed Amazon Timestream for various customers using this time series database to store telemetry data. I liked Timestream because it was an AWS-managed service, so there was no need to worry about the scalability and availability of the underlying infrastructure. Unfortunately, AWS decided to disable this service for new customers.

It all started typically - that person contacted me on LinkedIn asking for assistance in designing and building an IoT-powered product. We met, discussed the business idea, found a common ground, and agreed to start in a month. Time has passed, and I haven’t heard from that person. Ok, I thought, yet another lead that went south. I decided to give it one last try and sent an email asking for confirmation that the initial agreement was no longer valid.

I’ve got access to numerous AWS accounts and typically use my phone as the MFA (Multi-Factor Authentication) device. That is a handy, secure, and cost-effective solution. There is a specific case in which I do recommend using a hardware security token as the secondary MFA. I use it to protect access to the Root User of the AWS Management Account. Let’s break this down: ✅ The Root User has unlimited permissions, can create and destroy any AWS infrastructure, and manage other users in that account.