Skip to main content

IoT offer comparison: AWS vs Azure

Nowadays IoT is appealing for everyone. These opportunities made the two biggest cloud providers from the market (Amazon and Microsoft) to come up IoT platforms and solutions. The main purpose this this article is to compare the current solutions from features perspective and capabilities perspective.
The interesting thing that happened in the last few years is the way how IoT solution evolved. At the beginning the solutions were oriented around transport and communication, but now the IoT platforms evolved and are integrated with systems that runs on the edge and in the cloud, supporting the business needs.

X-Rays
Let’s take a look on the available solutions that Amazon and Microsoft offers. Both providers are offering a central Hub that is used to establish and facilitate a communication between devices and backend systems.
At device level, each provider is offering a set of package libraries that allows clients to integrate their devices with the communication platform faster. At backend level, the basic functionality is almost the same, with some small differences. Most of the processing systems used for data crunching can be found on both providers.
Is interesting how both platforms are positioning. Both of them are focused on telemetry and data collection from devices. Even if there is full support for communication (commands) from backend to device, complex scenarios or chatty devices might have some problems.
Don’t be shocked if you will find a lot of similarities between these two solutions. The main focus of both providers is to fulfill the clients’ needs. Because of this, it is normal when a new feature is available on one platform, the other one to provider a similar one in a short period of time.
Overall, from the way how both solutions are organized and list of cores features the offer is similar.

Core functionality
Let’s take a look on the main features of each platform. This list represents the main core features that are available today. Starting from tomorrow this list might be incomplete, because new functionality can be added anytime.


Device Management
From device management perspective, both providers are offering a similar list of features.  You have the ability to specify the list of attributes of each device and have a device shadow into the cloud. A useful feature that can be found on both platform is the ability to enable a device and control device capabilities. This is extremely useful when concepts like devices black list needs to be supported.
Azure IoT Hub is offering pipeline support for data that needs to be send to the device, in comparison with AWS where this is not an out of the box feature. Extra development feature is required for it.

Authentication and Authorization 
Good authentication and authorization mechanism are offered by both providers. For startups and small companies that are not using Active Directory (AD), AWS might be tempting, but Microsoft is very attractive in the moment when a corporate is using AD. Native AD support combined with token based access for device will simplify integration with legacy application that exist inside the company.

Communication Channels
The list of protocols supported by both providers starts with HTTPS, MQTT and AMQP. Be aware that Azure is very strict related to HTTPS and HTTP is not supported anymore. If you need HTTP protocol between device and Azure, they can be supported only with a custom gateway between device and Azure IoT Hub.

SDK and programing language
AWS and Azure have a clear statement related to this – to support all top platforms, starting from Node.JS and C (ANSI C99) to Java and C#. The SDK features and API is the same for all programming language. Don’t expect to find a feature available only in a specific programming language.

Extra capabilities
The current IoT vision that is shared in the market is starting at device level and goes until to Machine Learning, AI and Analytics solutions. Azure and AWS are offering not only the same capabilities, but are using also similar is not even the same solutions. Hadoop, Spark and R language are something common for both of them.
Monitoring and Identity Registry
Azure is storing all the device information in the backend. The last device state can be queries in any moment. The state of the device is available in Azure IoT Hub together with last know activity, with full control of the device (create, updated and delete).
The identify management in AWS is called Thing Registry and is equivalent to the one offered in Azure.

Device Communication
Bi-directional communication is supported by AWS and Azure. The only difference is how is this supported. AWS is supporting this using a rule engine. Devices that are connected to AWS IoT platform have a specific topic/subscription that plays the role of message broker that sends messages to their devices. Each device publishes their state through publishing updates and stored in a Thing Shadow.

Azure IoT Hub is using two different endpoints that are used to send and receive data from devices. Messages contains a timestamp and can expired after a specific period of time. The concept of Thing Shadow can be found also on Azure IoT Hub as Twin Device. Personally, I thing that in this moment the Azure IoT Hub is offering a more mature solution at device communication level.
From communication perspective, both provided are offering the same feature, but implement in a different way.

Security
Nowadays security is a hot topic. You will be able to find a lot of whitepapers related to this. You should remember that Azure IoT Hub relies on Transport Layer Security (TLS) protocol that offers an encrypted communication channel that guarantees data confidentiality. Customers can come with their own X.509 certificates. Beside this, services and devices are secured using access control and credentials that specify a list of permissions. In this way, each device will have control to a specific list of actions.
AWS also relies on TLS for backend authentication with full support of mutual authentication. Clients has the ability to attach certificates to device and policies.

Certified Hardware Boards
Each provider is offering starter kits together with different hardware manufacture. This kits are ideal to create prototypes and validate ideas. Below you can find a list with the most important partners.

Application and Services
Each provider is offering a collection of services to help their clients. The most important services offered by Azure (IoT Suite) around IoT are:
Stream Analytics
Machine Learning
Power BI
Azure Time Series Insights
Azure Storage
Azure Cosmos DB
Azure Web Apps
The services offered by AWS are covering the same functionality:
DynamoDB
Kinesis
Lambda
AWS S3

Pricing
This topic is pretty hot and complex. Calculating the E2E cost of an IoT platform it’s hard, especially when you need to make different assumptions (data volume, ingest, egress, number of messages, size, queries complexity, …). The message size for AWS is 1KB in comparison with Azure where the message size is 4 KB. This can have affect at costs level.
It seems that if you put all the costs together you might find that an IoT platform to be 20-50% cheaper on Azure than on AWS. Free tiers at communication level are offered by both providers.

Final thoughts
The best way to finish such an article is not with the writer opinion, because this might be irrelevant. I thing that most relevant information would be a chart that compares this two platforms.

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP