AWS IoT Core bills separately for connectivity, messaging, Device Shadow operations and Rules Engine triggers, which is genuinely cheap at low device counts but compounds quickly as devices report more often. A self-hosted VPS running Mosquitto and Node-RED has a flat monthly cost regardless of message volume. For most SMB-scale deployments under a few thousand devices, the self-hosted VPS works out cheaper, often substantially so, once device chattiness is factored in honestly.
The problem with comparing these two on price alone
AWS IoT Core and a self-hosted VPS aren’t really the same product wearing different price tags, they’re different cost models entirely. AWS charges per unit of activity: every connection-minute, every message, every Device Shadow read or write, every Rules Engine trigger. A VPS charges a flat monthly fee regardless of how busy it is. This means the “which is cheaper” answer depends entirely on how chatty your devices are, not just how many of them you have, and a comparison that ignores this gives a misleading answer either way.
How AWS IoT Core actually bills
AWS IoT Core unbundles pricing into separate components, each billed independently:
| Component | What it covers | Approximate rate (US East) |
|---|---|---|
| Connectivity | Per-device connection time | From around $0.042 per device per year for 24/7 connection |
| Messaging | Per message, metered in 5KB increments | From around $0.70-$1.00 per million messages, decreasing at higher volume tiers |
| Device Shadow / Registry | Per read/write operation on device state | Billed per million operations, separate from messaging |
| Rules Engine | Per rule trigger plus per action executed | Billed per million rule executions, separate again |
Each of those rows is a genuinely separate line item on an AWS bill. A single device sending one telemetry reading that triggers a rule and updates its shadow is being billed across three of those four categories simultaneously, for what feels like one logical event.
A worked example at three scales
To make this concrete, consider devices each sending one message every 30 seconds (a reasonably typical telemetry interval for the kind of projects covered on this site), with each message also updating a Device Shadow and triggering one rule.
| Device count | Approximate AWS IoT Core monthly cost | VPS-based stack monthly cost |
|---|---|---|
| 50 devices | Often within or close to AWS’s 12-month free tier limits | A few pounds (entry-level VPS, e.g. LumaDock from £3.77/mo) |
| 500 devices | Connectivity, messaging, shadow and rules charges combined typically run to tens of dollars monthly, scaling with message frequency | Still comfortably within a mid-tier VPS, around £10-15/mo |
| 5,000 devices | Costs scale roughly linearly with the table above, commonly reaching low hundreds of dollars monthly at this device count and message frequency | A larger VPS or two split services, still typically well under £50/mo |
These figures are illustrative, not a quote, since actual AWS costs depend heavily on message size, exact frequency, and which specific features you use, and AWS’s own pricing calculator is the authoritative source for a precise estimate of any specific workload. The pattern that holds regardless of exact numbers: AWS’s cost grows with activity, a VPS’s cost doesn’t, so the gap between them widens as either device count or message frequency increases.
What you’re actually trading for that cost difference
This comparison would be dishonest without naming what AWS IoT Core gives you that a self-hosted VPS doesn’t, automatically: effectively unlimited scaling without capacity planning, geographic redundancy across AWS’s global infrastructure, deep native integration with the rest of the AWS ecosystem (Lambda, S3, SageMaker, and so on), and no server to patch, secure or monitor yourself. For a team already committed to AWS for other infrastructure, or building something genuinely planning to scale to hundreds of thousands of devices, that trade is often worth paying for.
What a self-hosted VPS gives you in return: a flat, predictable bill that doesn’t change based on how chatty your devices get, full control over the exact software stack, and no risk of a misconfigured retry loop on a single device quietly generating an unexpected bill, a real and not uncommon AWS IoT Core horror story.
Where the actual break-even sits
For most projects covered on this site, home and small business IoT, a handful of industrial sites, a smart home setup, the device count and message volume stay well within the range where a VPS is clearly cheaper, often by an order of magnitude once Device Shadow and Rules Engine charges are factored in honestly rather than just comparing raw messaging cost. The crossover point where AWS’s managed infrastructure starts justifying its cost tends to sit at a scale (tens of thousands of devices, genuine need for global redundancy, an existing AWS-centric engineering team) well beyond what this site’s guides are written for.
The hidden cost on the VPS side: your own time
It’s worth being honest about the other side of this trade too. A VPS doesn’t manage itself, the security hardening, the updates, the monitoring covered throughout this site’s other guides represent real time, even if it’s modest once the initial setup is done. AWS IoT Core’s higher per-unit cost is partly paying for not having to do any of that. For a solo developer or small team comfortable with the Linux fundamentals covered in this site’s guides, this time cost is usually small. For a team with zero spare capacity for any infrastructure work, it’s a genuine factor worth weighing alongside the raw pricing numbers.
Getting started with the self-hosted alternative
The self-hosted side of this comparison is exactly what the rest of this site covers: Mosquitto for the broker AWS IoT Core’s messaging component replaces, Node-RED for the logic AWS’s Rules Engine replaces, and a small VPS like LumaDock‘s entry tier underneath both. See VPS for IoT: The Complete Guide for the full picture of what to actually run.
Frequently asked questions
Is AWS IoT Core’s free tier enough for a real small project?
For genuinely small projects, often yes for the first 12 months: AWS’s free tier covers 2.25 million connection-minutes, 500,000 messages, 225,000 Device Shadow/Registry operations and 250,000 rule executions monthly. The 12-month limit is the catch, costs begin once that window closes, regardless of whether usage has grown.
Can I migrate from AWS IoT Core to a self-hosted VPS stack later?
Yes, since most devices speak standard MQTT regardless of which broker they’re pointed at. The main work is reconfiguring device connection strings and credentials, plus rebuilding any AWS-specific Rules Engine logic in Node-RED instead, which is more involved than the device reconnection itself but entirely achievable.
What about AWS IoT Greengrass, is that a different comparison?
Greengrass runs compute at the edge, closer to devices, which is a genuinely different architecture and pricing model from IoT Core’s cloud-based approach. Most projects covered on this site don’t need edge compute of that kind, a VPS already sits centrally and reachable, which is the role Greengrass devices play locally for AWS-centric architectures.
Does a self-hosted stack offer the same reliability as AWS’s infrastructure?
Not automatically, AWS’s global redundancy is genuinely hard to replicate on a single VPS. For most SMB-scale projects, a well-hardened single VPS with regular snapshots offers reliability that’s more than adequate for the stakes involved, though it’s a real trade-off worth acknowledging rather than dismissing.
Is there a middle ground between AWS IoT Core and a fully self-hosted VPS?
Yes, this is essentially what ThingsBoard represents: a full-featured platform, self-hosted on your own VPS for a flat cost, without AWS’s per-component metered billing, while still getting more built-in device management than a hand-rolled MQTT/Node-RED stack.
Hidden costs on the AWS side worth knowing about
The headline IoT Core pricing covers connectivity, messaging, shadows and rules, but a real production AWS architecture rarely stops there. Data typically flows onward into other AWS services, Lambda functions processing messages, S3 for long-term storage, Timestream or another database for querying history, each billed separately and easy to underestimate when first sketching out a budget. None of these are hidden in the sense of being undisclosed, AWS’s documentation covers them clearly, but they’re easy to leave out of an initial cost comparison that only looks at the IoT Core pricing page in isolation.
The self-hosted side has an equivalent honesty check: a VPS’s flat monthly fee doesn’t include your own time, and for a team without existing Linux operations experience, there’s a real learning curve, smaller than people often fear, but not zero, covered honestly throughout this site’s other guides.
A note on data egress costs
One AWS cost worth specifically flagging: data transfer out of AWS to the public internet is billed separately and can become a meaningful cost for dashboard-heavy applications with many users pulling data frequently, a cost dimension that doesn’t really have an equivalent on the self-hosted VPS side, where most providers, including LumaDock, include generous or unmetered bandwidth in the base price. For applications with many external dashboard viewers rather than just a handful of internal users, this is worth factoring in specifically rather than assuming it’s negligible.
When the comparison genuinely favours AWS
To be fair to the other side of this comparison: a team building something that genuinely needs to scale unpredictably and rapidly, from a hundred devices to a hundred thousand without warning, benefits from AWS’s elastic infrastructure in a way a fixed VPS simply can’t match without manual intervention. Similarly, a team already deeply invested in AWS’s ecosystem for other parts of their business gains real integration value that’s hard to replicate by self-hosting an isolated IoT stack elsewhere. Neither of these describes most projects covered on this site, but they’re genuine, valid reasons to choose AWS IoT Core specifically rather than a sign the comparison in this guide is wrong.
How accurate are the cost figures in this guide likely to stay over time?
AWS revises IoT Core pricing periodically, and the figures here are illustrative rather than a live quote. AWS’s own pricing calculator, linked from their IoT Core pricing page, is the authoritative source for a current, workload-specific estimate before making a final decision.
Does this comparison apply equally to Azure IoT Hub and Google Cloud IoT alternatives?
The general pattern, usage-based billing across multiple components versus a flat self-hosted cost, applies broadly across major cloud providers’ IoT offerings, though exact pricing structures and rates differ between them. The worked-example approach in this guide is worth repeating against whichever specific platform you’re actually comparing.
Is it possible to use AWS IoT Core for some devices and self-host the rest?
Yes, and it’s not an unusual pattern for organisations transitioning between the two approaches, or with genuinely different requirements across different parts of a fleet. The two systems can run in parallel without conflict, since they’re independent infrastructure.
What’s the realistic time investment to set up the self-hosted alternative from scratch?
For someone following this site’s guides directly, typically a few afternoons to get MQTT, Node-RED and basic security hardening working, covered in detail in VPS for IoT: The Complete Guide‘s realistic timeline section, considerably less than building an equivalent custom AWS architecture with Lambda functions and IAM permissions from scratch.
Does AWS IoT Core charge anything if devices are connected but not sending data?
Yes, connectivity is billed by connection time regardless of message volume, meaning a device that stays connected 24/7 but rarely transmits still accrues connectivity charges continuously, a detail worth factoring in for any deployment with many devices maintaining persistent but low-traffic connections.
Is it worth using AWS IoT Core just for its free tier, then migrating away before charges begin?
This is a reasonable way to validate a prototype at zero cost, though worth planning the migration deliberately rather than waiting until charges actually begin, since rebuilding under time pressure is more error-prone than a planned transition with adequate testing time built in.
Does this guide’s comparison hold up for a non-profit or research project with very limited budget?
Generally yes, and arguably more strongly, since a fixed, predictable VPS cost is particularly valuable for organisations on tight, fixed budgets where an unexpected usage-based bill spike would be a genuine problem rather than a manageable annoyance.