- Newest
- Most votes
- Most comments
UPDATE AUG 6 2025: Exclusive thing association was introduced in Nov 2024. This allows you to use the thing policy variable even when the client ID does not match the thing name. Accordingly, you can open multiple concurrent connections, each with a different client ID, using one certificate attached to one thing.
ORIGINAL ANSWER Hi micro-jumbo.
EDIT: When I attach the connect policy to the Device-Group - Lower-Power module CANNOT connect. When I attach the same policy directly to the Certificate, it CAN connect
That's because there's no Thing name that matches the client ID you use for the Low-Power module. Hence when you connect with the Low-Power client ID, there's no Thing group membership found. And hence it does not get the Thing group policy applied.
Stepping back from the policy detail for a moment, a couple of points:
- It seems like the High-Power and Low-Power modules never connect simultaneously. Is that right? In terms of IoT Core connectivity, they only need different client IDs if they would sometimes be connected at the same time.
- Would you perform independent device management of the High and Low Power modules? For example, send a job (or OTA) to just Low Power modules? If so, you would likely benefit from each High and Low Power module each being their own discrete Thing in the registry.
In both situations above you would no longer have two different client IDs for the one Thing.
If a Certificate is attached to a Thing does it mean I can use only clientId == ${thingName}?
If the only policy resource for Connection is ${iot:Connection.Thing.ThingName}, then yes. Otherwise no.
Relevant content
- asked 4 years ago
- asked 2 years ago
- AWS OFFICIALUpdated a year ago

Answer updated to mention exclusive thing association, a feature that was introduced after this question was answered.