AWS IoT Core gives you a serious set of building blocks: a managed MQTT broker, a device registry, device shadows, and a rules engine that routes messages into the rest of AWS. And the pricing is honest about what it is, you pay per million messages, per million registry operations, per million rules triggered, with no minimum fee. But none of that is the thing your users actually open every morning. The dashboard, the login screen, the alert that wakes someone at 3am, the mobile app, the way one customer cannot see another customer’s data, all of that sits above IoT Core and none of it ships with it. Therefore the real question is not which product is better. It is whether you want to build and operate the platform layer yourself, or buy one that already has it.
What AWS IoT Core actually gives you
AWS describes IoT Core as a way to connect devices and route messages to AWS services without managing connection infrastructure. That description is accurate, and it is also the whole point. IoT Core handles the parts that are genuinely hard to run at scale: a broker that holds millions of concurrent MQTT connections, device identity and certificates, last-known-state storage through device shadows, and a rules engine that forwards or transforms messages on the way to Lambda, S3, DynamoDB, Kinesis, or wherever you send them.
That is the connectivity and ingestion layer. It is solid, and for a lot of teams it is exactly the right foundation. What it is not is an application your customers log into.
What you still have to build on top
Once messages land, the work that users care about has barely started. With IoT Core as your base, your team is responsible for:
- Dashboards. There is no built-in visualization. Teams usually wire up Amazon Managed Grafana with OpenSearch as a data source, or assemble Lambda, API Gateway, RDS, and S3 into a custom frontend. Either way, you are building and styling it.
- A multi-tenant model. If you serve multiple customers, you design how their data stays separated, how accounts map to devices, and how nothing leaks across boundaries. IoT Core does not have a tenant concept.
- User management. Roles, permissions, invitations, and access control come from IAM and Cognito that you configure and maintain, not from a ready user system.
- Alerting and its interface. The rules engine can trigger an action. The screen where a non-technical user defines a threshold, picks who gets notified, and reviews what fired, you build that.
- A mobile app. There is no white-label app. If your customers expect one, it is a separate project.
None of this is impossible. Plenty of teams do it well. The honest part is the second bill: every one of those pieces is something you then own forever. You patch it, you scale it, you stay on call for it, and you pay the engineers who keep it running. The AWS invoice is the small number. The salaries are the large one.
When AWS IoT Core is the right choice
This matters enough to say plainly, because the answer is not always a managed platform.
Choose AWS IoT Core when you have a capable cloud engineering team that can design, build, and operate distributed systems, and you want them spending their time on exactly that. If your organization already lives in the AWS stack, your data lake is in S3, your auth is in Cognito, your compute is Lambda and ECS, then keeping IoT inside that same account removes friction and the integration work is real but contained.
Choose it when your requirements are specific enough that an off-the-shelf platform would fight you. Unusual protocols, custom data pipelines, regulatory setups that demand particular control over where and how every byte moves, or scale so large that you need to tune the infrastructure directly. At the very high end, full control is worth the engineering cost.
And choose it without hesitation when the platform itself is your product. If you are building an IoT platform to sell, you should not be renting the layer that defines your differentiation. You build it, on IoT Core or otherwise, because that layer is the company.
If one or more of those describes you, AWS IoT Core is a good answer and a managed platform would get in your way. Be honest with yourself about which group you are in before you decide.
When a managed platform wins
For most teams whose product is not the platform, the math points the other way. You have devices, you have customers, and you need those customers looking at clear data, getting alerts, and managing their own accounts, soon, without hiring a cloud team to build a frontend stack from parts.
A managed platform ships the application layer as the product. Dashboards, multi-tenant separation, user and permission management, an alerting interface, and a mobile-ready portal are there on day one. Your engineers connect devices and write the logic specific to your business, instead of rebuilding the same platform layer every IoT company rebuilds. You trade some low-level control for time, and for most teams time is the scarcer resource.
Where TagoIO fits
TagoIO is the managed platform answer to this decision. It handles device connectivity and data, and it ships the layer you would otherwise build on top of IoT Core. Multi-tenant accounts are part of the model, not a thing you architect. Dashboards, user management, and alerting come built in. TagoRUN gives you white-label portals so your customers see your brand, not ours. Serverless Analysis scripts let your team write custom logic without standing up and maintaining compute. And TagoCore, our open-source edge runtime, handles processing closer to the device when you need it.
On the parts buyers ask about: TagoIO is ISO 27001 certified and GDPR-aligned, and it offers more than 500 device integrations, so most hardware connects without a custom adapter.
The trade is the same one named above. With TagoIO you give up direct control of the underlying infrastructure in exchange for not building or operating the platform layer. If your product is the platform, that trade is wrong for you. If your product is what runs on top of the platform, it is usually right.
Next steps
If you want to see the platform layer instead of building it, start here:
- Explore the platform: tago.io
- Check the pricing model: tago.io/pricing
- Read the technical docs: docs.tago.io
The decision comes down to one question you can answer today: is operating the platform layer the best use of your engineering team, or is it the part you would rather buy and move past. Both answers are defensible. Pick the one that matches what your team is actually for.
