The following figure provides an overview of the relationship between the multiple logical constructs you must configure within the AWS IoT Core and AWS IoT Greengrass services in-region. Remember, all the Greengrass v2 agent does is dial home and fetch its configuration from AWS. This includes the components (software) it needs to download from S3 and instructions on how to set them up:

Figure 9.5 – AWS IoT Greengrass logical entity relationships

AWS IoT Core things and AWS IoT Greengrass Core devices

In AWS IoT Core, all devices are things. In this architecture, AWS Snowcone is a Greengrass Core device, but first and foremost, it is a thing in IoT Core (albeit of a special type). In the following screenshot, we have three things configured – two of them are sensors that report to the Greengrass v2 agent on our Snowcone, and one of them is the Snowcone itself:

Figure 9.6 – AWS Snowcone and sensors as things in AWS IoT Core

The following screenshot shows an overview of snowcone1 from the perspective of AWS IoT Greengrass as a Greengrass Core device:

Figure 9.7 – Overview of snowcone1 as an AWS IoT Greengrass Core device

AWS IoT Greengrass deployments and components

You will notice that we have configured this particular device to be an AWS Systems Manager node, as well as set it up to push detailed logs and metrics to AWS CloudWatch. We did this by targeting it with a Greengrass deployment that contains public Greengrass components. Examining the following screenshot, you will see that we’ve also deployed several other Greengrass components. These include the things we need to run AWS Lambda functions, a local Moquette-based MQTT broker, and the MQTT bridge, which relays messages from the local broker up to matching topics in AWS IoT Core:

Figure 9.8 – A Greengrass deployment and its constituent Greengrass components

AWS IoT certificates and policies

All things – regardless of type – are mapped to individual certificates in AWS IoT Core. This goes for our AWS Snowcone device, as well as the IoT devices reporting to it. These certificates can be handed out by a private CA (either one of your own, or one in AWS Certificate Manager), but more commonly, they are provisioned by the internal CA the AWS IoT Core service itself uses. That is what we are doing in the following screenshot:

Figure 9.9 – An AWS IoT certificate and the IoT policy attached to it

You will also notice that the AWS IoT certificate for snowcone1 has an IoT policy attached to it. This is a type of policy distinct from the ones used in AWS IAM. The following example JSON shows a sample IoT policy of this type. You will notice that it governs only what the thing can do in the context of IoT and Greengrass actions:

Figure 9.10 – Example of an IoT policy

Notice the last section of the preceding policy. The resource it points to is another AWS IoT construct called a role alias. This is simply a mapping of the role alias ARN to the ARN of a standard IAM role. This is how we allow the Greengrass Core device’s certificate to assume a standard AWS IAM role for non-IoT/Greengrass-specific operations. This might include things such as permissions to publish to AWS CloudWatch, access certain Amazon S3 buckets, perform actions in AWS Systems Manager, or perform an iam:PassRole action to take on the persona of yet another IAM role.