- 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. I think you have already seen answers sharing this information: https://docs.aws.amazon.com/iot/latest/developerguide/thing-policy-variables.html
The thing name is obtained from the client ID in the MQTT Connect message sent when a thing connects to AWS IoT Core.
When you're replacing thing names with thing policy variables, the value of clientId in the MQTT connect message or the TLS connection must exactly match the thing name.
So, when you have ${iot.Thing.ThingName}-jobs in the resource of your policy, and client thingName-jobs connects, you end up with thingName-jobs-jobs as the resource. And similar for other combinations.
all of them need to connect to one single thing
Clients don't connect to a thing. In AWS IoT Core, things are just a way to organize your fleet. You don't need any things defined. Your services could all connect to AWS IoT Core, so long as the X.509 certificates are registered.
Based on what you described in your question, I recommend you create a thing for each service. Where, of course, the thing name is the same as the client ID used by each service. Then you can use the thing name policy variable to easily write scalable least-privilege policies.
Relevant content
- asked a year ago

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