AWS IoT Device SDK for Embedded C: Libraries Over a Transport You Supply

A Source Only SDK With No Third Party Dependencies

The AWS IoT Device SDK for Embedded C, usually called C-SDK, is a collection of C source files released under the MIT open source licence. It is distributed in source form and is meant to be compiled into customer firmware alongside application code, other libraries and an operating system of your choice.

The dependency policy is the defining constraint. The README states that the libraries depend only on standard C libraries, so they can be ported from embedded RTOS to Linux, Mac and Windows. There is no bundled TLS stack and no bundled MQTT broker client beyond the client itself, which means the security layer of your device is something you implement and audit.

The intent is a device, not a server. The SDK exists so that a microcontroller or a small Linux box can connect to AWS IoT Core using the same service semantics, and the project states it was tested to work with AWS IoT Core and with an open source MQTT broker for interoperability. Sample usage is given on POSIX systems with OpenSSL, in the demos directory, and on FreeRTOS with mbedTLS, in the FreeRTOS repository.

coreMQTT Runs Over a Transport Interface You Implement

coreMQTT is the piece most projects adopt first. It establishes an MQTT connection with a broker over a customer-implemented transport layer, which can be a secure channel such as a TLS session with either mutual or server-only authentication, or a non-secure channel such as a plaintext TCP connection. The connection supports publishing to topics and subscribing to them.

Events are surfaced through callbacks that the customer registers, covering incoming PUBLISH, acknowledgement and keep-alive responses from the broker. The library was refactored for memory optimisation and is compliant with the MQTT 3.1.1 standard, and it depends on nothing beyond the standard C library, your transport interface, and optionally a platform time function you provide.

That last point is the one to internalise. A time function means the library does not call time() itself, which is exactly what you want on a microcontroller where the tick source is a hardware timer, and it is also the thing you must get right. The design is described as covering everything from resource-constrained platforms using only QoS 0 PUBLISH messages up to resource-rich platforms using QoS 2 over TLS, and the memory requirements for the current release are published in the coreMQTT doxygen output for 202412.00.

The Library Inventory Beyond MQTT

The README lists the libraries that make up the SDK, and the set is broader than a protocol client:

coreMQTT
coreHTTP
coreJSON
corePKCS11
AWS IoT Device Shadow
AWS IoT Jobs
AWS IoT Device Defender
AWS IoT Over-the-air Update Library
AWS IoT Fleet Provisioning
AWS SigV4
backoffAlgorithm

coreHTTP provides the ability to establish an HTTP connection, and coreJSON is a JSON parser. corePKCS11 covers the PKCS11 interface, which matters for devices that keep keys in a secure element. Device Shadow, Jobs and Device Defender are the service-side libraries, and the README notes they are flexible enough to work with any MQTT client and JSON parser, not only the ones bundled here. That is deliberate: the MQTT client and the JSON parser are offered as choices rather than being tightly coupled to the rest of the SDK.

Two smaller pieces complete the set. AWS SigV4 is the request signing algorithm the AWS services require, and backoffAlgorithm is a separate library, which tells you the SDK treats retry behaviour as something you configure rather than something baked in. There is also a documented path for sending metrics to AWS IoT.

Release Numbers Encode the Calendar, and Branches Carry Different APIs

Versioning in this project is unusual enough to trip people up. Releases are named after the year and month, with a build number: 202412.00, 202211.00, 202108.00, 202103.00, 202012.01, 202011.00 and 202009.00, preceded by a v3.1.5 from the older scheme. The newest tag is 202412.00, published on 2024-12-16, with 202211.00 and 202108.00 before it.

The branch structure matters as much. The default branch is main, and there is a separate branch named v4_beta_deprecated, formerly called v4_beta, which the table of contents records as deprecated. Anyone arriving from a v3 or v4 beta integration needs to read the migration guides before touching the code, because the API changed underneath them.

The documentation is organised around those boundaries as well. There is a porting guide for 202009.00 and newer releases, covering coreMQTT, coreHTTP, Device Shadow and Device Defender, and a separate migration guide from v3.1.5 with sections for MQTT, Shadow and Jobs. The project also publishes a CHANGELOG.md, a SECURITY.md and a MISRA.md at the root of the repository, alongside a manifest.yml and a tools directory.

Building the Demos With CMake, and the Docker Path for Local Brokers

The Getting Started section of the README is organised as a sequence: clone the repository, install the build dependencies, set up an AWS IoT account, then configure the demo you want. The configuration steps differ per demo, with separate instructions for the mutual authentication demos of MQTT and HTTP, for Device Defender and Device Shadow, for the Fleet Provisioning demo, for the S3 demos, for the AWS IoT Jobs demo and for the Greengrass local auth demo. That list is the clearest statement of the SDK's service coverage, and it is worth skimming before choosing a demo to copy.

The build is CMake driven, with a CMakeLists.txt at the repository root and the library sources under libraries/ and the platform layer under platform/. The README documents building a single demo and building all configured demos, plus separate handling for the corePKCS11 demos.

There is an alternative for running the demos locally, using Docker containers, and it names the two services you need: Mosquitto for the MQTT demos and httpbin for the HTTP demos. That path is the one to use if you want to exercise the client without provisioning anything in AWS first.

The Transport, the TLS and the Time Function Are Yours

The most common way this SDK is misused is to expect it to be a complete IoT client. It is not. coreMQTT depends on a customer-implemented network transport interface, and optionally on a customer-implemented platform time function, and it has no dependencies on any additional libraries other than the standard C library. The same pattern holds for the HTTP side, where the transport is again supplied by the customer.

The README shows what that looks like in practice. On POSIX systems the samples use OpenSSL, and on FreeRTOS they use mbedTLS, so the TLS provider changes with the platform while the SDK libraries stay the same. For a device with a hardware secure element, corePKCS11 and the separate SigV4 library cover key access and request signing respectively, but the wiring of those into your board support package is still your task.

Two practical implications follow. First, porting the SDK to a new board is a matter of implementing the transport and time interfaces, and the porting guides exist precisely because those interfaces changed shape in 202009.00. Second, the security review of a device using this SDK has to include the code you wrote around it, since the SDK deliberately keeps the trust-critical edges outside its own boundary.

Where C-SDK Is the Wrong Choice

The SDK is a poor fit in several ordinary situations, and the reasons are structural rather than matters of taste.

It is wrong for a hosted service. The whole design targets a device that links C into firmware, and a Linux server has far easier paths to AWS IoT Core, where you would pick a managed client rather than compile a C library and a TLS stack yourself.

It is wrong when you need a feature the library set does not cover. The inventory is fixed and dated: MQTT, HTTP, JSON, PKCS11, Shadow, Jobs, Device Defender, over-the-air update and Fleet Provisioning. Services outside that list are not in scope, and the README does not describe an extension point for adding them.

It is also wrong if you cannot supply a transport. A hosted environment with no embedded network stack of your own, or a team without anyone able to write and review a TLS integration, will spend its time on the porting layer instead of on the product.

Finally, be careful about the release trail. The newest tag is 202412.00 from 2024-12-16, the repository is not archived, and the last push was on 2026-04-22, so the tree is moving without a fresh release number to pin against. Choosing a branch and recording it in your dependency lock is more important here than in a project with a tagged release every few weeks.

Editorial conclusion

The C-SDK fits firmware teams that need AWS IoT Core connectivity on a constrained device, are willing to supply their own transport and TLS layer, and want MIT licensed source they can compile into the image rather than a linked binary. It is a poor fit for a project that expects a turnkey TLS stack, for a hosted Linux service where a Python or JavaScript SDK would be simpler, or for anyone who needs a recent feature, because the newest release is 202412.00 from 2024-12-16 and the last push was on 2026-04-22. Before starting, read the porting guide for 202009.00 and newer releases, since the API changed at that boundary, and confirm your board's C library provides what the libraries expect.

Frequently asked questions

Official sources

1. aws/aws-iot-device-sdk-embedded-C on GitHub
2. Issues
3. License: MIT
4. README
5. Releases