AWS IoT Analytics is a piece of infrastructure that technical architects can use to build all sorts of things, whereas DevicePilot is a finished application that people can use to visualise and manage their device estate.

AWS IoT Analytics introduces some logic or analysis into the individual stream of telemetry coming from each device, to create bits of your application, or do data reduction ahead of further analysis. It's a nice example of the AWS serverless lambda architecture - triggering code in response to a situation (in this case data arriving from a device).

• You can use it to create bits of your application, e.g. if you want your heating to turn off when the temperature in the house reaches 20C then you could create a lambda which will run every time a message comes from the device, and if "current_temp >= target_temp" then it can send a message to turn off the heating. Your code might even be very sophisticated, for example doing machine-learning.
• You can use it to do data-reduction, e.g. if you want to see which of your devices have a flat battery, then you can create a lambda which runs every time a battery message comes from the device, and turns the stream of "battery=20, battery=10, battery=5, battery=0" messages into a much smaller stream of "battery_ok=true, battery_ok=false" messages. After reducing the data in this way you can run higher-level analysis to ask questions like "how many devices have a flat battery?".

So could you use AWS IoT Analytics to build an application for visualising and managing your devices, as an alternative to using DevicePilot? There are several reasons why the answer is probably "no" (or at least, "not on its own"):

1. In AWS IoT Analytics the model is that you write code do your analysis, so the analysis is "burned in" to the code. As you device estate grows, the number of people asking new questions about it also grows, until new types of question are occurring daily. If each new question requires a developer to write code to answer it, that's no fun for the person asking the question (they'll have to beg, and probably wait days or weeks for the answer). It's also no fun for the developer, because they're constantly getting interrupted from writing the code for the core application. This is the difference between a piece of infrastructure and a finished application.
2. When the question changes, you want to be able to answer it historically too. For example, if you change your definition of "uptime" (and you probably will), then you'll want your uptime charts to change to using the new definition, including historical values (you don't want to see a chart where the number suddenly jumps because you changed the definition). This requires working everything out again from the original data (which is how DevicePilot works) rather than storing pre-digested results (which is how AWS IoT Analytics would naturally work, if you add some storage after it).
3. The types of analysis: A classic question that someone might ask in DevicePilot is "what is my device uptime or availability over the past week?". IoT Analytics intrinsically works per-device, not across the whole-estate, so a further stage of analysis must be done to calculate the whole-estate answer. Also, measuring uptime requires that you measure e.g. how often a device has talked to you. If a device stops talking, then there are no messages from it to trigger IoT Analytics.

In conclusion, AWS IoT Analytics is a useful tool to consider for building pieces of application logic or perhaps analysis (if you're sure exactly what analysis you need and it won't change often), but - at least on its own - isn't the right tool for general device visualisation and management.

DevicePilot is an AWS Marketplace partner, and an AWS IoT Competency partner.

See IoT analysts MachNation's analysis of AWS IoT in our summary white paper here.