- [Raf] Driving an Industrial IoT operation may not be a simple task. And many times, you may even need to use custom or legacy hardware that is already installed and operating on the factory floor. Within all this conversation of connected factories, assembly lines, industrial plants, and everything we talked so far, it makes sense to talk about hardware and their logical representation in the cloud. In this video, I will talk about some important topics about devices, things, and some security best practices. These are something real simple to differentiate, but some people may end up confused because of the amount of abstraction needed to understand the whole scope. Here we go. When you hear us talking about a device, a node, or a sensor, it means that we are talking about a hardware component with communication capabilities, such as microcontrollers with sensors. When you hear us talking about a thing, it means that we are referring to the virtual representation of that hardware in the cloud. IoT things are entries in the AWS IoT Device Registry. Each thing should have unique name and set of attributes, and it is associated with an IoT certificate, typically, an X5091. For the sake of a security best practice, each of those certificates should be unique per device. You can register existing certificates, or have AWS IoT generate and register new certificates for you. Once you have a thing and the corresponding certificate for it, you are ready to attach an IoT policy. Now, some words about certificates. AWS IoT Core provides several different ways to provision a device, and install unique client certificates on it. Let me explore three scenarios on that matter. First scenario, in the case that you have the ability to install certificates on IoT devices before they are delivered. For that, things can be provisioned using just-in-time provisioning, or just-in-time registration. Second scenario, in the case that end users or installers can use an app to install certificates on their IoT devices. In this case, you can use the provision-by-trusted-user process, which uses temporary and unique certificates to obtain another certificate for the device. And third scenario, in the case that end users cannot use an app to install certificates on their IoT devices. In this case, you can do a provisioning by claim, which in terms of security is less recommended, but more flexible. Don't worry if you didn't get it. I am going to provide a documentation page in the next reading of this course containing more details about these three scenarios I described. So, to recap, the cloud schema between the devices, things, certificates, and policies are: Devices are the real hardware. Things are the logical representation of that device in the cloud. Things are attached to IoT certificates. The certificate material goes inside the device. AWS IoT certificates are associated with an IoT policy, and all this communicates with the device gateway. You can do some API calls to manually provision a thing, such as create-thing, create-certificate-from-csr, create-policy, attach-policy, and attach-thing-principal. After doing all that, you can add the certificate material to the device. Industrial IoT needs to operate things at scale. So, instead of doing manual-API-calls-for-everything provisioning, there are more sophisticated ways to do all this through bulk actions. Continue through the course to see that happening, as we talk more about AWS IoT services.