AWS IoT Device Client

Leading the AWS IoT Device Client remains one of the highlights of my career. I joined AWS to deploy IoT services in secure environments for government customers, then spent time with the teams behind AWS IoT Jobs, Secure Tunneling, and logging.

When an internal need emerged for a reference implementation showing customers how to connect their devices to AWS IoT, I volunteered. It was a chance to sharpen my C++ and build something useful in the open.

I led the design and implementation with review and guidance from several principal and distinguished engineers, including James Gosling. One of the more surreal moments was making the case to the father of Java that we should write this particular device client in C++.

Amazon’s writing culture also changed how I think. If I couldn’t put a plan into a simple document, explain it to a team of engineers, and accept their feedback, the idea probably wasn’t mature enough. More often than not, I needed to simplify or consolidate it.

I’ve carried that habit with me. Writing exposes ambiguity early, before implementation gets messy. These days, a fast LLM-assisted prototype can serve the same purpose from another angle: make the idea concrete, then see where it breaks. I still reach for a document when I want to circulate an idea, sharpen it with a team, and decide whether it has legs.

AWS IoT offered powerful fleet capabilities, but customers still had to assemble the device-side software that connected those capabilities and held up under real operating conditions.

Jobs, Secure Tunneling, logging, configuration, and diagnostics were not isolated SDK integrations. Together they formed an operating workflow that builders had to understand and operators had to support in production.

I designed the AWS IoT Device Client as a public C++ agent with coherent configuration, feature boundaries, and failure behavior. The work spanned Jobs, Secure Tunneling, logging, collaboration across SDK teams, and the less visible details that determine whether edge software remains operable.

Customer conversations, diagnostics, on-call experience, and partner feedback shaped the implementation. The goal was not cleverness at the edge. It was software builders and operators could reason about when devices, networks, and people were imperfect.

Because the project was open source, the artifact had to carry the argument. The repository, documentation, implementation, and design choices remain public and independently inspectable.

The project reinforced an operating instinct I carried into later fleet work: a device agent is also a contract for configuration, diagnostics, support, ownership, and failure—not only a bundle of technical integrations.

• https://aws.amazon.com/blogs/iot/build-a-proof-of-concept-iot-solution-in-under-3-hours-with-the-aws-iot-device-client/
• https://docs.aws.amazon.com/iot/latest/developerguide/iot-dc-runjobs.html