ESP32 firmware development & AWS IoT — from one device to a fleet

The four building blocks of an ESP32 fleet on AWS

Most ESP32 prototypes are built quickly, with a single device, a single MQTT topic, and credentials baked into source. That works until you have 50 units in the field. Moving an ESP32 design from prototype to a production fleet is a matter of getting four building blocks right.

1. Code-signed OTA firmware updates

The device runs Amazon FreeRTOS or ESP-IDF with the OTA agent. Firmware images are signed with an AWS Certificate Manager code-signing certificate and stored in S3. AWS IoT Core creates an OTA job that the device picks up over MQTT. The agent verifies the signature with the device's private key before swapping the active partition — so a tampered or interrupted image never becomes active firmware. Rollback is automatic on boot failure.

2. Fleet provisioning

Devices ship with a bootstrap certificate and request their production identity at first boot. The device presents its bootstrap cert plus a CSR. A custom Lambda validates ownership, IoT Core enacts the birth policy, signs the CSR, and returns the official certificate. A provisioning template then runs automatically — creating the Thing, attaching it to the right groups, and applying the production policy. Each unit ends up with a unique, revocable identity without manual setup at the factory.

3. Device Shadow

Each Thing has a JSON shadow that holds desired and reported state. The device publishes to deviceId/shadow/update; the cloud writes desired state to the same topic, and the broker fans out a /update/delta message to the device. Apps and dashboards interact with the shadow rather than the device directly, so commands queue cleanly while devices sleep or roam.

4. Targeted rollouts with IoT Jobs

Production rollouts target subsets of the fleet. We use dynamic groups — queried by shadow attributes such as firmware version or hardware revision — combined with a static exclude-list group for canaries. A Lambda updates target shadow attributes so a rollout advances ring by ring, and an IoT job carries the work to every matching device.

ESP32 firmware capabilities

Stack we ship in production

Layer	What we use
Silicon	ESP32, ESP32-S3, ESP32-C3 (RISC-V)
SDK / RTOS	ESP-IDF, Amazon FreeRTOS, Arduino-as-component for legacy projects
Cloud	AWS IoT Core, S3, Lambda, IoT Jobs, IoT Device Shadow, IoT Device Defender; Azure IoT Hub when required
Bootloader	ESP-IDF bootloader with secure boot v2, MCUboot for portability
Security	Secure boot, flash encryption, ATECC608, code-signing, SBOM
CI / tooling	GitHub Actions, IDF.py, esp-idf-monitor, OpenOCD, J-Link, Joulescope for power

Proof — ESP32 + AWS IoT programs we have shipped

FAQ

FreeRTOS or ESP-IDF, which do you use?

Both. ESP-IDF is our default for new projects because of its first-party support, integrated component manager, and tight AWS IoT device SDK integration. Amazon FreeRTOS is the right choice when you need the OTA library and AWS IoT integration on a board that doesn't yet ship with full ESP-IDF support.

Can you set up code-signed OTA on AWS IoT Core?

Yes. AWS Certificate Manager code-signing certificate, image in S3, OTA job orchestrated by AWS IoT Core over MQTT. The device verifies the signature before swapping partitions, with automatic rollback on boot failure.

How do you onboard a factory full of devices to AWS IoT Core?

Fleet provisioning. Devices ship with a bootstrap certificate, present a CSR at first boot, and receive their production identity via a Lambda-validated provisioning template. Each unit ends up with a unique, revocable identity without manual factory setup.

Can you do BLE + Wi-Fi on ESP32?

Yes. Coexistence is delicate — we have shipped products that pair over BLE, exchange Wi-Fi credentials, and then run BLE telemetry alongside Wi-Fi MQTT. We measure throughput on a real board so the BLE link stays usable while Wi-Fi is active.