Maybe I misinterpret @arjanvanb, but do I understand it correctly that with TTN v2 and AWS IoT connector will publish on the same topic on the AWS MQTT queue as on the TTN queue? So the message are published on the < AppEUI >/devices/< devEUI >/up topic on AWS IoT. And next to this the state is reported on a generated AWS IoT thing?
It is not that you should never sync devices and things. But in some use cases it is not by definition the best practice to do so. I do not know the exact specifications of TTN v2, but I can explain a bit on the reasons why we are not using AWS things currently. Note: We do sync devices and things for the devices whose state can be set via downlink, but this is only a small part of the total of devices.
A thing id is not very flexible, so you cannot register a rule on an application topic, nor a device type topic. This would mean a rule per device, in case of 1000s of devices, this would imply maintaining many IoT rules.
We want to store the information from different kinds of devices in a uniform format, we do this on AWS as TTN payload functions were not adequate at that time. I understood that the payload functions will be device specific in v2? Will there also be sort of payload functions per device type? So in case of 1000s of devices with the same payload function, would it be easy to update the code of the payload function?
Inspecting the latest (and historical devices readings, e.g. temp levels) can not be done fast and in bulk when storing the state in things. So that's why we are storing them in dynamo and our business logic. So skipping the thing will improve throughput time and lesten AWS costs.
Our solution is also multi-tenant. We are handling multiple applications on our AWS platform. It is undoable to authorize customers to only publish on the topics of their own things when handling 1000s of things. With MQTT topics like < appEUI >/devices/< deviceEUI >, authorization certificates can be created per customer for their own queue < appEUI >/+