اختيار منصة سحابة إنترنت الأشياء: AWS أم ThingsBoard أم الاستضافة

The decision that outlives the firmware

By the time you are choosing the cloud layer, the hard embedded work usually feels done: the gateway polls its sensors, buffers locally, and publishes clean MQTT. The platform decision looks like a checkout step. It is not. It sets your recurring bill, operational burden, and how trapped you are when the first choice stops fitting.

The mistake we see most often is choosing the platform that wins the demo instead of the one that fits the fleet. A platform that feels effortless at 50 devices in a sprint can become an unbudgeted line item or a 3am pager habit at 50,000 in production. So this is a vendor-neutral framework, not a recommendation. The answer depends on fleet size, your team, and your tolerance for running infrastructure.

The three contenders, honestly

The candidates sit on a spectrum from "someone else operates it" to "you operate all of it."

• AWS IoT Core — fully managed. A managed MQTT broker with per-device X.509 auth, an IoT Rules engine that fans messages to other AWS services, device shadows, and fleet provisioning. You write no servers — you wire services together and pay per use — and assemble storage and a dashboard from AWS pieces.
• ThingsBoard — a platform product. An open-core IoT platform that ships what you would otherwise build by hand: a device registry, dashboards, a rule chain, alarms, and multi-tenancy. Self-host the community edition or buy ThingsBoard Cloud. It is the "batteries included" option — least assembly of the three.
• Self-hosted open stack — you operate it. Mosquitto for ingest, InfluxDB for time-series storage, and Grafana for dashboards, on your own VMs. Maximum control, minimum vendor dependency, every operational task yours.

None of these is "better." They distribute the same work differently: AWS hands you scale and a meter; the self-hosted stack hands you control and a pager; ThingsBoard hands you a finished product and asks you to live inside its model.

Separate the two costs that everyone conflates

The most common budgeting error is collapsing one-time setup and recurring run cost into one gut feeling. They move in opposite directions across these options, and conflating them is how teams pick the platform that is cheap to start and expensive to keep.

One-time setup effort is what it takes to get the first real device publishing to a dashboard you trust. AWS IoT Core front-loads this: IAM policies, certificate provisioning, the Rules engine, and stitching together storage and dashboarding is a real learning curve even for an experienced team. ThingsBoard front-loads the least — install it, register a device, and you have dashboards and a rule chain in an afternoon. The self-hosted stack lands in between: the install is well-trodden, but wiring TLS, retention, and provisioning correctly is the underestimated part.

Recurring cost model is the shape of the bill over time, and the shape matters more than today's number:

• AWS IoT Core meters usage — connectivity, messages, rules engine, and device shadow are separate line items — so the bill tracks message volume. Double the publish rate and the relevant lines roughly double.
• A self-hosted stack is a step function: nearly flat (a VM or two plus bandwidth) until a node saturates, then you add or resize hardware. Message count barely moves the invoice; capacity does.
• ThingsBoard inherits whichever model you choose — VM-step self-hosted, per-device subscription on ThingsBoard Cloud.

The failure this separation prevents is the budget surprise: a platform that is cheap during a 50-device pilot quietly becoming a five-figure monthly line at fleet scale, found only when finance asks why. Model recurring cost against your real publish interval and payload size, across the fleet you expect in two years.

The third axis nobody prices: operational burden

Setup and recurring cost are visible on a spreadsheet. Operational burden ambushes teams, because it never shows up as a line item — it shows up as your senior engineer's weekend.

On AWS IoT Core, the broker, its scaling, patching, and availability are AWS's problem. Your operational job is configuration: getting IAM and topic policies right, and watching the bill.

On a self-hosted stack, everything is your problem: broker uptime, TLS certificate rotation before certs expire and silently drop the whole fleet, OS and dependency patching, InfluxDB retention and downsampling so the disk does not fill, Grafana upgrades, and backups you have actually tested by restoring. None of this is exotic, but all of it is real, recurring work — and the failure it prevents, the one that bites teams who priced only the VM, is the 2am outage with no vendor to call. When the broker falls over, you are the escalation path: fine if you have the people and the runbooks, a slow-motion disaster if "self-hosted" was chosen purely to dodge a cloud invoice.

ThingsBoard self-hosted carries most of that burden plus its own database and clustering to operate; ThingsBoard Cloud lifts it the way any managed offering does — you trade the pager for a subscription.

The comparison table

Read each row as a trade you are accepting, not a score.

Mapping the table to your fleet

The rows resolve differently at the two ends of the scale, so anchor the decision to where you are.

1. The 50-device pilot. You want to validate the product, not operate a platform. AWS IoT Core's per-message billing is negligible here, but its setup tax is real and the IAM learning curve can eat the sprint. A single-node ThingsBoard or a self-hosted box gets you to a trustworthy dashboard fastest. Pick by team: if someone already runs Linux comfortably, self-host; if you want dashboards and rules out of the box, ThingsBoard.
2. The growth phase (hundreds to low thousands). Operational burden starts to bite, and a self-hosted stack either proves it has an owner with runbooks or reveals that it does not. If your broker node is nearing saturation and nobody has tested a restore, that is the signal to invest in operating it properly or move toward managed.
3. The 50,000-device production fleet. Now AWS IoT Core earns its price. Fleet provisioning, device shadows, elastic scale, and an availability SLA you do not staff yourself are exactly the problems that get punishing to self-operate at this size. The metered bill is real, but usually cheaper than the headcount to run an equivalent stack at equal reliability.

Most products pilot on something simple, then graduate the cloud layer as the fleet and stakes grow — painless only if you planned the move, and that planning lives in the device layer.

Lock-in is decided at the device, not the cloud

What determines whether "we'll switch later" is a config change or a recall: the lock-in that actually traps you lives in the firmware, not the cloud console.

If your gateways speak plain MQTT over mutual TLS to a topic structure you defined, the cloud is replaceable — repointing a fleet from AWS IoT Core to a self-hosted Mosquitto broker is a new endpoint and certificate, no firmware rewrite, no recall. But if device firmware depends on AWS-specific shapes — shadow semantics, proprietary message formats, SDK-only behaviors — switching means re-flashing every unit in the field, the most expensive operation in this business.

So spend your portability budget at the device boundary: keep firmware speaking standard MQTT, and push proprietary cloud features behind a thin server-side adapter you can rewrite without touching a deployed device. Then you get the best of the framework — start on whatever fits the pilot, and graduate the cloud layer as the fleet grows without opening a firmware ticket.

How to actually choose

Walk the framework in order and the answer falls out.

1. Estimate the two-year fleet, then model AWS IoT Core's metered bill and the self-hosted VM-step curve against your real publish interval and payload — not the pilot's.
2. Audit your team honestly. If nobody will own backups, certificate rotation, patching, and on-call, self-hosting's lower invoice is a trap and managed buys back the engineer-hours.
3. Pick by fleet size and burden tolerance. Small fleet with Linux skills: self-host. Small-to-mid fleet wanting a finished product: ThingsBoard. Large fleet needing elastic scale and provisioning: AWS IoT Core.
4. Protect portability at the device. Standard MQTT, your own topic structure, proprietary features behind a server-side adapter — so the cloud stays replaceable.

There is no universal winner, only a fit — and the worst outcome is choosing on vibes and finding the mismatch after the fleet is in the field.

GizanTech builds across all three: gateway firmware whose MQTT contract stays portable on purpose, self-hosted Mosquitto, InfluxDB, and Grafana stacks for cost-sensitive fleets, ThingsBoard deployments, and AWS IoT Core fleets with provisioning and least-privilege topic policies. If you want the cost model and lock-in risk validated before you commit firmware, talk to our team.

Frequently asked questions

Should I use AWS IoT Core, ThingsBoard, or a self-hosted stack for my IoT product?

Match the layer to your fleet size and your team. A 50-device pilot rarely justifies AWS IoT Core's per-message billing and IAM learning curve, so a self-hosted Mosquitto, InfluxDB, and Grafana stack or single-node ThingsBoard stands up faster and cheaper; a 50,000-device fleet is where AWS earns its keep with provisioning, shadows, and elastic scale you do not operate. ThingsBoard sits in the middle — a finished platform you can self-host or buy as managed cloud. The deciding factor is whether you have the people to run infrastructure, not which logo is trendiest.

Is a self-hosted MQTT + InfluxDB + Grafana stack cheaper than AWS IoT Core?

At rest, almost always yes — you pay for one or two VMs and bandwidth regardless of message volume, while AWS IoT Core meters connectivity, messaging, the rules engine, and device shadow separately. But "cheaper" only counts the invoice; the self-hosted stack moves the real cost onto your team — backups, TLS rotation, patching, retention tuning, and being the on-call engineer at 3am. For a small fleet with someone who already runs Linux, self-hosting wins on cost. For a large or compliance-bound fleet, the managed bill often buys back more engineer-hours than it costs.

How much does an IoT cloud platform cost as the device fleet grows?

The shape of the cost curve matters more than today's number. A self-hosted stack steps up — flat until a node saturates, then you add or resize a VM. AWS IoT Core scales smoothly but the bill tracks message volume and feature use, so doubling your publish rate roughly doubles the relevant line items. ThingsBoard self-hosted follows the VM-step curve; ThingsBoard Cloud a per-device subscription. Model cost against your real publish interval and payload size across the fleet you expect in two years, because the platform cheapest at 50 devices is rarely cheapest at 50,000.

How do I avoid vendor lock-in when choosing an IoT cloud platform?

Keep the device contract portable. Have firmware speak plain MQTT over mutual TLS to a topic structure you define, and keep proprietary cloud features behind a thin server-side adapter rather than baked into the device. Then you can repoint gateways from AWS IoT Core to a self-hosted broker by changing an endpoint and a certificate — no firmware rewrite, no recall. The lock-in that hurts lives in the device layer, where re-flashing the fleet is the only escape, so spend your portability budget there and treat the cloud as replaceable.