AWS IoT Core multiple environments

Question

Lets say I want to have a staging environment and a production environment. The application works by adding topic rules and processes the ingest with AWS lambda.

What is the best way to have multiple environments in AWS IoT Core?

I thought about doing this:

1. Set up two accounts (not possible in my project)
2. Split environments by topic prefix like dev/* or prod/*
   • Means the device needs to know in advance where it belongs to
3. Add devices to a group and do rule based filtering
   • Is there any guidance how to do this? I know I can call a lambda function, but this seems a bad idea. It would be great to have a group based filter but afaik there is no access to the device`s groups or properties right now

I would strongly prefer 3. as it allows me to also use production devices for testing. 1. and 2. are alright but not very flexible.

Maybe there are some best practices?

Hershelhershell

I have the same question, as it appears the IoT https endpoint for my 'thing' is the same. I was also considering putting dev and prod in different regions. What did you end up doing? – Starks

Answer 1

We have experienced the stage topic prefix approach in our project for months. I think we keep doing it but there are some side effects that I have mentioned below.

STAGE AS TOPIC PREFIX

Most of the time messages will routed to IoTCore Rules and will trigger some AWS services like Lambda/S3/Dynamo etc. If you are using serverless this could achive with env variables as follows

...
custom:
  myStage: ${opt:stage, self:provider.stage}
  STAGES:
    - dev
    - prod
 
provider:
  name: aws
  runtime: nodejs12.x
  region: eu-central-1
  environment:
    STAGE: ${self:custom.myStage}

functions:
  someLambdaFunction:
    timeout: 180 
    handler: someLambdaFunction.handler
    events:
      - iot:
          name: "iotRuleName_${self:custom.myStage}"
          sqlVersion: "2016-03-23"
          sql: "SELECT  * as data , topic() as topicName FROM '${self:custom.myStage}/room/+/temperature'"

So when you deploy to serverless app to development environment, the rule name will be iotRuleName_dev and the rule sql will be like dev/room/+/temperature

But there are some problems:

• As you say with this approach, endnodes should know the prefix value.

• AWS limits your topic levels as 8 -max 7 forward slashes(/) - so by adding stage as prefix to all topics you basically decrease your limit to 7 AWS IoT Core Quotas

• You still have to check for thingName collision. You cant have same thingName in multiple environments at the same time and you would not want to deal with it. Adding stage prefix to thing names could solve confusion. Something like 'DEV-Thing1'

You would also want to consider using basic ingest to reduce costs

STAGE AS REGIONS

It could also possible to split your whole application environments between AWS regions, No collision, no side effects. But you should almost split everything to sleep well in your bad at night. Because accessing different regions entities could cause a big chaos.

CUSTOM APPLICATION

Build your own IoT Core. Well, if you achive this. Do not only use it but sell it.

Nastassia

Dear Ozan, thank you for a detailled answer. We also followed the stage as topic prefix in our cloud solutions where splitting accounts does not make sense. The basic ingest tip is helpful, we also followed that approach for basic ingest – Hershelhershell