AWS IoT Core hands you a clean set of building blocks. Device ingestion, a rules engine, a device registry, and the rest of the AWS catalog sitting right next to it. For a system integrator or a small product team, the first proof of concept is genuinely fast. You wire up a few devices, push messages through, route them with a rule, and you have something to demo by the end of the week. It feels like you just saved yourself the cost of a managed platform.
And then the demo works, the customer is happy, and you sign the contract.
But the bill nobody put on the slide starts arriving the month after. Not the AWS invoice. That part is usually manageable. The bill is the years of operating work you just signed up for. Authentication, dashboards, alerting, device management, firmware updates, multi-tenancy, scaling, patching, monitoring, on-call, incident response, and the security and compliance evidence your customers will eventually ask for. AWS gave you the parts. It did not give you the product, and it did not agree to run the product for you.
Therefore the honest move, before you commit, is to count the real operating burden. Not the week-one demo cost. The three-year cost in roles, hours, and ongoing responsibility. Then decide build or buy with your eyes open.
What AWS IoT Core actually gives you
It helps to be precise about where the managed service stops. AWS IoT Core covers ingestion, a rules engine, and a device registry. Those are real and useful. They are also raw building blocks.
A product is not raw building blocks. A product is the thing your customer logs into, trusts, and pays for every month. Between Core and that product sits a long list of things you now build and, more importantly, run.
What you maintain when you build on AWS
This is the part that does not show up in the proof of concept. Each item below is something you assemble once and then own forever.
The application layer you have to build
- Authentication and access control. User accounts, roles, password resets, session handling, and the audit trail behind all of it.
- Data storage. Choosing the stores, modeling the data, managing retention, and paying attention to cost as volume grows.
- Dashboards. The visual layer your customers actually use. This is rarely a one-time build. It changes every time a customer asks for a new view.
- Alerting and automation. Thresholds, notifications, escalation logic, and the rules that turn raw data into action.
- Device management UI. A way for non-engineers to see, provision, and troubleshoot devices in the field.
- Firmware and OTA updates. Pushing updates to devices safely, with rollback when an update goes wrong, because eventually one will.
- Multi-tenancy. Keeping one customer’s data and users cleanly separated from another’s. This is hard to add later and easy to get subtly wrong.
The operations you have to run, every day, for years
- Scaling. When a customer adds ten thousand devices over a weekend, the system stays up without you babysitting it.
- Patching. Dependencies, base images, and libraries that need updates the moment a vulnerability is disclosed.
- Monitoring. Knowing something is wrong before the customer calls.
- On-call and incident response. Someone carries the pager. When ingestion stalls at 2 a.m., someone wakes up and fixes it.
- Security and compliance evidence. When an enterprise customer sends a security questionnaire, or asks whether you are certified, you need answers and proof, not promises.
Read that list again as a system integrator with a small team. Every hour spent on platform plumbing is an hour not spent on a customer. The platform is not what your customers pay you for. It is the floor you have to keep building and re-building so you can do the work they actually want.
The three-year reality, measured in people
The honest way to size this is not in dollars you cannot know yet. It is in roles and hours over the life of the contract.
Building the application layer is a project. Running it is a job that never ends. Over a three-year horizon, the running is what dominates. You need people who can carry on-call. You need someone who owns patching and stays current on security advisories. You need someone who can answer a compliance questionnaire without a week of scrambling. On a small team, those are not three people. They are the same one or two people you also need building features and serving customers.
That is the trap. The platform does not fail loudly. It fails as a slow tax on the team you already have. Velocity on customer work drops because the same engineers are now also the operations team, the security team, and the first line of support when the dashboard is slow.
When building still makes sense
Building on AWS is not a mistake. For some teams it is clearly the right call, and pretending otherwise would be dishonest.
Build when the platform is your core product and your differentiator. If what you sell is the platform, and the way you ingest, store, and present data is the thing that beats your competitors, then owning every layer is the point. Outsourcing it would mean outsourcing your edge.
Build when you have a dedicated platform engineering team. If you can staff a team whose only job is running the platform, separate from the people serving customers, the operating burden has a home. It stops being a tax on customer work.
Build when you have hard requirements no managed vendor meets. Specific data residency rules, an unusual protocol, an air-gapped environment, a regulatory constraint that rules out every off-the-shelf option. If you have truly checked and nothing fits, building is the honest answer.
If none of those describe you, the burden is real and it is yours.
How a managed platform changes the math
For a small team that does not fit the build case, a managed application layer changes who owns the long list above.
This is where TagoIO fits. It sits as a managed application layer on top of the ingestion and device connectivity, so a small team ships dashboards, alerts, device management, and APIs without operating the underlying stack. The on-call, the patching, the scaling, and the monitoring move to someone whose full-time job is running that platform. TagoIO is ISO 27001 certified and GDPR-aligned, which also offloads part of the compliance evidence you would otherwise assemble yourself, including some of the answers to those enterprise security questionnaires.
For integrators specifically, there is a second angle. Through TagoRUN you can resell or white-label the platform, which turns the application layer from a cost center you have to operate into a recurring revenue line under your own brand. That flips the question from “how do we afford to run this” to “how do we sell this.”
None of this makes the build case wrong. It just means that if your edge is your customers rather than your infrastructure, buying lets you spend your hours where the money is.
The summary, plainly
AWS IoT Core gives you every building block, and the first proof of concept comes together in a week. But the bill nobody budgets is the years of on-call, patching, scaling, multi-tenancy, and customer support you now own, paid in the time of a team you cannot spare. So before you commit, count the real operating burden in roles and hours over three years, be honest about whether you are a build case, and choose build or buy with your eyes open.
