Your production plant has just started sending data. Dozens of sensors, a few connected machines. It works. Then the day comes when devices become hundreds, and the small server you configured in an afternoon starts coughing. Connections drop, data is lost, and your technician spends Saturday restarting services. This is the moment when most SMEs discover that IoT is not an hardware problem, but an infrastructure one.
At Meteora Web, we have been building web platforms and automations for almost a decade. We have seen companies spend weeks building a DIY IoT backend, only to throw it away when data volume grew. IoT clouds like AWS IoT Core, Azure IoT Hub and Google IoT Core exist to solve exactly this: managing millions of messages without you having to think about servers, queues and reconnections. But choosing the wrong vendor can cost you dearly in terms of lock-in and monthly fees.
Why should a business use an IoT cloud instead of its own server?
The right question is not "which cloud is better", but "why not build everything in-house?". The answer is in the numbers. Managing an IoT infrastructure means dealing with authentication, encryption, reconnections, message buffering, horizontal scaling and monitoring. A single server can handle a hundred devices sending one data point per minute. With ten thousand devices sending one data point per second, the math changes: you need load balancers, distributed queues and scalable databases. The IoT cloud gives you all of this as a service, with a predictable cost.
Let's use a concrete example. A client of ours in the agricultural sector installed humidity sensors in five greenhouses. At first, a Raspberry Pi with a SQLite database was enough. When he extended monitoring to fifty greenhouses with readings every thirty seconds, the Raspberry Pi crashed. With AWS IoT Core, the problem would not have even arisen: the service handles millions of concurrent connections and the client would have paid only for the messages actually exchanged.
The economic benefit is clear: zero initial investment in servers, zero maintenance costs, and a pay-per-use model that adapts to growth. The risk is lock-in: once your devices speak a vendor's protocol, migrating is painful. That is why the choice must be made carefully, evaluating MQTT as the lingua franca.
Sponsored Protocol
The basics: MQTT and the publish-subscribe model
Before choosing a cloud, you need to understand how devices communicate. MQTT is the standard protocol for IoT: lightweight, designed for unstable connections and low power consumption. The model is publish-subscribe: a device publishes a message to a topic (e.g. greenhouse/01/temperature) and anyone interested subscribes to that topic. The IoT cloud acts as a broker, routing messages without devices knowing each other.
This model is powerful because it decouples data producers from consumers. A temperature sensor does not need to know if the message goes to a database, a dashboard or an alert function. It just publishes. The cloud handles the rest. It is the same architecture we use for web platforms: message queues and workers processing asynchronously, without blocking those who produce the data.
import paho.mqtt.client as mqtt
# Connect to an MQTT broker (e.g. AWS IoT Core)
client = mqtt.Client()
client.tls_set()
client.username_pw_set("device-id", "password")
client.connect("your-endpoint.iot.eu-west-1.amazonaws.com", 8883)
# Publish a message on the sensor topic
client.publish("greenhouse/01/temperature", "21.5")
client.disconnect()This code works with any MQTT broker, including a local Mosquitto. The difference with a cloud is that you do not manage the broker: they do, with redundancy and automatic SSL certificates. Your job is only to authenticate devices and define topics.
How does AWS IoT Core work and how much does it cost compared to Azure?
AWS IoT Core is the most mature service on the market. It offers a managed MQTT broker, a device registry, a rules engine to route data to other AWS services (Lambda, S3, DynamoDB) and a security system based on X.509 certificates. The pricing model is simple: you pay 5 dollars per million messages published or delivered, with a minimum threshold of 5 dollars per month for the service. If your use case is environmental monitoring with one message per minute per device, the cost is negligible.
Sponsored Protocol
Azure IoT Hub works similarly but with an architectural difference: instead of a pure MQTT broker, it offers an MQTT-compatible endpoint integrated with Azure's identity system. Devices register in the IoT Hub registry and authenticate with SAS tokens or certificates. Pricing is tiered: the free tier (F1) allows 8,000 messages per day, the basic tier (B1) starts at about 25 dollars per month and includes 400,000 messages per day. The standard tier (S1) adds message routing to other Azure services, which is the feature you need if you want to process data in real time.
Google IoT Core, unfortunately, shut down in August 2023. If you have an existing project on Google, you must migrate. We recommend evaluating AWS or Azure as destinations, because they are the two ecosystems with the broadest support and the largest community. The choice between the two depends on where the rest of your infrastructure lives: if you already use AWS for your website, AWS IoT Core is the natural choice. If your company is already in the Microsoft ecosystem (Office 365, Dynamics), Azure integrates better.
Practical comparison: authentication and security
Security is the point where SMEs make the most mistakes. With a self-hosted broker, you have to manage SSL certificates and credentials yourself. With AWS IoT Core, each device has a unique X.509 certificate, revocable at any time. Azure uses SAS tokens or certificates, with the ability to rotate keys automatically. In both cases, the cloud gives you a level of security that would be complex to replicate in-house.
A common mistake is using the same API key for all devices. If a sensor is stolen or compromised, you need to revoke only that one, not the whole fleet. Both AWS and Azure support per-device registration and selective revocation. At Meteora Web, we always recommend enabling two-factor authentication and using AWS policy documents or Azure identities to limit what each device can do.
Which IoT cloud should you choose for an industrial or agricultural project?
The answer depends on three factors: data volume, required latency, and internal skills. If your project generates fewer than 100,000 messages per day and you do not need to process data in real time, Azure IoT Hub in the basic tier is the most economical choice. If instead you need to integrate IoT data with an existing web application, AWS IoT Core with Lambda and DynamoDB is unbeatable for development speed.
Sponsored Protocol
We have built a proprietary platform for managing social content, and we know how important it is to have control of the code. With IoT clouds, the code is yours: devices speak MQTT, which is an open standard. The vendor only manages the infrastructure. This means you can migrate from AWS to Azure if needed, rewriting only the integration layer, not the device firmware.
For an agricultural project with humidity and temperature sensors, our advice is to start with Azure IoT Hub free tier (F1) for a proof of concept, then move to B1 when the fleet grows. For an industrial project with machines that must communicate in real time for quality control, AWS IoT Core with a rules engine towards Lambda is the most robust choice, because Lambda scales automatically with load.
Operational steps to connect your first device
Here is the sequence we follow for every new IoT project, regardless of the chosen cloud:
- Register the device: create a "thing" in AWS IoT Core or a "device" in Azure IoT Hub. You will get a unique ID.
- Generate credentials: for AWS, create an X.509 certificate and download it. For Azure, generate a SAS token or certificate.
- Configure the firmware: use an MQTT library (Paho for Python, PubSubClient for Arduino) and set the cloud endpoint.
- Define topics: structure topics as
company/plant/sensorto have a clear hierarchy and filter data easily. - Test the connection: send a test message and verify it arrives at the cloud using the vendor's console.
- Set up a rule: in AWS, create a rule that forwards messages to a Lambda; in Azure, configure routing to an Event Hub or Function App.
This checklist takes you from zero to a working device in an afternoon. The most important step is the fifth: without a connection test, you do not know if the problem is in the firmware or in the cloud. We always use an MQTT client like MQTT Explorer for debugging before writing a single line of production code.
Sponsored Protocol
How to manage costs and scalability without surprises?
Cost is the number one fear for SMEs. With AWS IoT Core, the price is 5 dollars per million messages, but beware: acknowledgment messages (ACK) also count. A device publishing one message per minute generates 43,800 messages per month, so about 0.22 dollars per month per device. With 1,000 devices, we are talking about 220 dollars per month, plus Lambda and storage costs. With Azure, the B1 tier at 25 dollars per month includes 400,000 messages per day, which is enough for 277 devices sending one message per minute. Beyond that threshold, you scale to B2.
The practical advice is to estimate the number of messages per day per device and multiply it by the number of devices expected in 12 months. Add a 20% margin for reconnection events and status messages. Then compare the pricing plans of the two providers. At Meteora Web, we always do this calculation with clients before recommending a platform. A wrong estimate can lead to a bill of hundreds of euros more per month.
Scalability, on the other hand, is the cloud's strength. If your project takes off and you go from 100 to 10,000 devices, you do nothing: the cloud absorbs the load. The only thing you need to monitor is the budget. Set up a billing alert on AWS or Azure to be notified when you exceed a threshold. It is the simplest way to avoid surprises at the end of the month.
What role does cybersecurity play in an IoT cloud architecture?
Security is the issue that SMEs underestimate the most. A compromised IoT device can become a gateway into your corporate network. IoT clouds offer powerful tools: per-device certificates, granular access policies, encryption in transit and at rest. But these tools only work if you configure them correctly. We often see projects where all devices share the same certificate, or where policies allow a sensor to read and write on all topics. These are mistakes that cost dearly.
The golden rule is the principle of least privilege: each device must have access only to the topics it needs. A temperature sensor must be able to publish to plant/01/temperature and nothing else. It must not be able to subscribe to other devices' topics, nor publish commands. On AWS, this is implemented with a policy document attached to the certificate. On Azure, with identities and roles.
Sponsored Protocol
Another critical aspect is firmware updates. Field devices are hard to update, so cloud security must be your main defense layer. Always use TLS 1.2 or higher, rotate certificates periodically, and monitor access logs. AWS CloudTrail and Azure Monitor give you the visibility needed to detect anomalous behavior.
What to do now
If you are considering moving your devices to an IoT cloud, here are the concrete actions to take today:
- Estimate the volume: count how many devices you have and how many messages each produces per day. Use this figure to compare AWS and Azure pricing plans.
- Run a proof of concept: register one device on Azure IoT Hub (free tier) and one on AWS IoT Core. Connect a real sensor and measure latency and ease of configuration.
- Design your topics: define a clear topic hierarchy for your project, e.g.
company/site/plant/sensor. This structure will simplify your life when you need to filter data. - Set cost alerts: configure a billing threshold on both platforms before going to production. You do not want to discover costs at the end of the month.
- Verify security: make sure each device has a unique certificate and that policies restrict access to only the necessary topics.
IoT cloud is not a luxury for large enterprises. It is the tool that allows an SME to compete with big players, without having to hire an infrastructure team. We see it every day: those who adopt these tools early, scale without pain. Those who wait, end up migrating a legacy system with double costs. The choice is yours.
To dive deeper into the overall IoT architecture for SMEs, read our pillar on IoT and programmable hardware. If you want to understand how to protect your stack, our article on Open Source in Business gives you the basics to assess risks.
