Introduction
On this weblog, we clarify the right way to route AWS IoT Core messages from a number of ingestion accounts to Amazon Simple Queue Service (Amazon SQS) in an information account. It’s a widespread sample to have IoT telemetry ingested into one account after which require it to be shipped to a different account for additional processing. For instance, when a company hosts units in a number of accounts and the info being ingested is assessed as each delicate and operational. Delicate knowledge must be stored within the unique assortment account however operational knowledge must be relayed to a different account monitored by an operations crew.
You’ll learn to configure AWS IoT guidelines for cross-account entry to route MQTT subject knowledge units into Amazon SQS. Guidelines for AWS IoT give your units the power to work together with AWS companies. You should use guidelines to help duties comparable to augmenting or filtering knowledge from a tool, writing knowledge to database, publishing messages to Amazon SQS and extra. For a whole checklist of duties you’ll be able to carry out, please discuss with the Rules for AWS IoT part of the AWS IoT Core Developer Guide.
Answer Overview
On this answer, you’ll first create an Amazon SQS queue within the knowledge account and grant permissions to the ingestion account to publish to it . Subsequent, you’ll create AWS IoT guidelines and ship messages to them to check.
- Create an Amazon SQS queue referred to as
iot-data
within the knowledge account and permit publishing to this queue from the ingestion account. - Within the ingestion account:
a. Create an Identification and Entry Administration (IAM) position with a coverage that permits publishing to Amazon SQS within the knowledge account.
b. Create an IAM position with a coverage that permits a republish motion for errors encountered when publishing to the SQS queue. - Create an IoT rule within the ingestion account to judge messages from a subject referred to as
knowledge/personal
and ship them to the info account SQS queue. The rule may have an error motion that republishes messages to theerror/guidelines
subject for troubleshooting. - Publish messages to the MQTT subject
knowledge/personal
and confirm the messages are seen within the knowledge account SQS queue.
Answer Diagram
Answer Directions
Stipulations
- Two AWS accounts
- Administrator privileges in each accounts
- AWS Command Line Interface (AWS CLI)
Create an SQS queue within the knowledge account
- Create a file named
queue_attributes.json
with the next content material.{ "MessageRetentionPeriod": "259200" }
- With the AWS CLI configured for the info account and utilizing the
create-queue.json
file, create an SQS queue referred to asiot-data
.aws sqs create-queue --queue-name iot-data --attributes file://queue_attributes.json
- Report the QueueURL from the output as that might be wanted within the subsequent part.
- To grant permissions for the Amazon SQS queue useful resource to be accessed by the ingestion account, run the add-permission command. Be sure you replace the account numbers accordingly.
aws sqs add-permission --queue-url https://sqs.<knowledge account area>.amazonaws.com/<knowledge account ID>/iot-data --label IoTSendMessage --aws-account-ids <ingestion account ID> --actions SendMessage
Create the AWS Identification and Entry Administration (IAM) position and coverage for cross-account publishing to SQS
In an effort to publish to the SQS queue from the info account, you first want to permit that motion.
- Create a file named
iot_policy.json
with the next content material:{ "Model": "2012-10-17", "Assertion": [ { "Effect": "Allow", "Principal": { "Service": "iot.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
- With the AWS CLI configured for the ingestion account, run the next command to create a job referred to as
iot-cross-sqs-allow
and fasten the belief coverage to permit it to work together with IoT.aws iam create-role --role-name iot-cross-sqs-allow --assume-role-policy-document file://iot_policy.json
- Evaluate the output and guarantee it’s appropriate:
{ "Function": { "Path": "/", "RoleName": "iot-cross-sqs-allow", "RoleId": "XXXXXXXXXXXXXXXXXXXXX", "Arn": "arn:aws:iam::XXXXXXXXXXXX:position/iot-cross-sqs-allow", "CreateDate": "2022-09-07T05:05:58+00:00", "AssumeRolePolicyDocument": { "Model": "2012-10-17", "Assertion": [ { "Effect": "Allow", "Principal": { "Service": "iot.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } } }
- Create a file referred to as
allow_send_cross_sqs.json
with the next content material. For the useful resource ARN, you should definitely replace with the area and account ID of the info account.{ "Model": "2012-10-17", "Assertion": [ { "Effect": "Allow", "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:<data account region>:<data account ID>:iot-data" } ] }
- Add this practice inline coverage to the position you created within the earlier step through the use of the next command:
aws iam put-role-policy --role-name iot-cross-sqs-allow --policy-name new-iot-cross-sqs-policy --policy-document file://allow_send_cross_sqs.json
Create the AWS IAM position and coverage to permit republishing of errors
When republishing messages with an AWS IoT rule, permissions have to be correctly set to permit this motion.
- With the AWS CLI configured for the ingestion account and utilizing the identical file created earlier, create a brand new position referred to as
iot-republish
:aws iam create-role --role-name iot-republish --assume-role-policy-document file://iot_policy.json
- Evaluate the output and guarantee it’s appropriate:
{ "Function": { "Path": "/", "RoleName": "iot-republish", "RoleId": "XXXXXXXXXXXXXXXXXXXXX", "Arn": "arn:aws:iam::XXXXXXXXXXXX:position/iot-republish", "CreateDate": "2022-09-07T05:24:36+00:00", "AssumeRolePolicyDocument": { "Model": "2012-10-17", "Assertion": [ { "Effect": "Allow", "Principal": { "Service": "iot.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } } }
- Subsequent create a file referred to as
allow_republish.json
with the next content material. Please observe that this coverage restricts publishing to subject names beginning with errors. Be sure you replace with the area and account ID of the ingestion account.{ "Model": "2012-10-17", "Assertion": { "Impact": "Enable", "Motion": "iot:Publish", "Useful resource": "arn:aws:iot:<ingestion account area>:<ingestion account ID>:errors/*" } }
- Add the coverage simply created as an inline coverage to the
iot-republish
position:aws iam put-role-policy --role-name iot-republish --policy-name iot-republish --policy-document file://allow_republish.json
Create an IoT rule within the ingestion account to judge messages and republish errors
Subsequent, we are going to create the IoT rule that can route messages to the SQS queue within the and likewise republish any messages that encounter an error to a subject named error/guidelines
.
- Create a file named
ingestion_rule.json
with the next content material. Be sure you replace thequeueURL
androleArn
values with these obtained in earlier steps.{ "sql": "SELECT * FROM 'knowledge/personal'" , "description": "Cross-account publishing of messages to SQS.", "ruleDisabled": false, "awsIotSqlVersion": "2016-03-23", "actions": [{ "sqs": { "roleArn": "<iot-cross-sqs-allow role ARN>", "queueUrl": "https://sqs.<data account region>.amazonaws.com/<data account ID>/iot-data", "useBase64": true } }], "errorAction": { "republish": { "roleArn": "<iot-republish position ARN>", "subject": "error/guidelines", "qos": 0 } } }
- With the AWS CLI configured for the ingestion account, create an IoT rule for the publishing of message to SQS within the knowledge account:
aws iot create-topic-rule --rule-name "cross_account_sqs_publish" --topic-rule-payload file://ingestion_rule.json
Publish messages and confirm they’re seen within the knowledge account SQS queue
To check the answer, you’ll be able to publish a message to AWS IoT Core and see if it arrives efficiently within the knowledge account SQS queue.
- From the ingestion account, use the AWS IoT MQTT client to subscribe to the
knowledge/personal
anderror/guidelines
matters. - Persevering with with the AWS MQTT IoT consumer, publish a message to the
knowledge/personal subject
with a pattern payload:{ "message": "Good day, world", "clientType": "MQTT consumer" }
- Retrieve messages from the SQS queue and evaluation the output by configuring the AWS CLI for the info account and operating the next command.
aws sqs receive-message --queue-url https://sqs.<knowledge account area>.amazonaws.com/<knowledge account ID>/iot-data
The Physique parameter of the output could also be Base64 encoded. If that’s the case, you have to to decode it to see the contents of the printed message
- If messages should not being obtained within the SQS queue, test the error/guidelines subject subscription for error messages associated to supply from the AWS MQTT IoT consumer within the ingestion account.
Cleansing Up
It’s good observe to wash up any assets you not wish to use. Cleansing up AWS assets prevents your account from incurring any additional costs.
- Delete the SQS queue:
aws sqs delete queue --queue-url https://sqs.<knowledge account area>.amazonaws.com/<knowledge account ID>/iot-data
- Delete the
iot-cross-sqs-all
IAM position:aws iam delete-role-policy --role-name iot-cross-sqs-all --policy-name iot-cross-sqs-all aws iam delete-role --role-name iot-cross-sqs-all
- Delete the
iot-republish
position:aws iam delete-role-policy --role-name iot-republish --policy-name iot-republish aws iam delete-role --role-name iot-republish
- Delete the
cross_account_sqs_publish
subject rule:aws iot delete-topic-rule --rule-name cross_account_sqs_publish
Conclusion
On this weblog we defined the right way to route AWS IoT messages from an ingestion account to Amazon SQS in an information account. Now we have proven you one sample that permits for segmentation of a delicate gadget and operational knowledge inside separate accounts. For additional examples on the right way to carry out cross-account message routing with different AWS companies, please try the associated documentation within the AWS Developer Guide.
Authors
Steve Krems is a Specialist Answer Architect for IoT at Amazon Net Providers (AWS). Previous to this position, Steve spent 18 years within the semiconductor business in Data Expertise administration roles with a deal with cloud migration and modernization. |
Kai-Matthias Dickman is a Specialist Answer Architect for IoT at Amazon Net Providers (AWS). He enjoys working with builders and resolution makers at giant enterprises to drive the adoption of AWS IoT companies. Kai has in-depth data of IoT and cloud and works on this position with international clients starting from start-up to enterprises to allow them to construct IoT options with the AWS Eco system. |