Everyone talks about cloud-native IIoT like it’s free money. Just lift your shop floor data to the cloud, connect a few APIs, and boom. Instant insights, zero infrastructure, pay as you go.
I’ve been leading IIoT platform evaluations and architecting multi-site implementations for a few years now, across global manufacturing networks. And there’s one thing vendors always get wrong in their pitch decks.
They show you the monthly compute costs, maybe some storage estimates, and call it done.
But that’s not where the real money goes.
Let me tell you what actually happens when you go cloud-native with industrial data.
The Egress Tax Nobody Mentions
Here’s the thing nobody mentions upfront. Once your data is in the cloud, getting it out costs money. A lot of money.
So you stream 50,000 tags from your plant to the cloud. That part is fine. Most providers make inbound cheap, and the vendor will proudly tell you ingestion is “optimized.”
But then you need that data somewhere else.
Maybe back on-premises for your MES. Maybe to another cloud region for compliance. Maybe just to download a few months of historian data for a root cause analysis.
That’s when the egress fees hit.
Cloud providers charge you pennies to put data in. But when you need to move large datasets out, or across regions, or into a different analytics platform, suddenly those pennies turn into real dollars.
Manufacturing data is high-frequency. Millisecond-level timestamps, hundreds of thousands of data points per hour. It adds up fast.
The Integration Tax (AKA “It Integrates With Everything”)
Every vendor will tell you their platform integrates with everything. And technically, they’re not lying. But integration in the cloud world means APIs. APIs mean calls. Calls mean cost.
Your MES needs to query the cloud historian 500 times a day? That’s 180,000 API calls per year.
Your quality system checks real-time values every 30 seconds? More calls.
Your advanced analytics platform pulls batches of data for model training? Even more calls.
Vendors usually show the platform cost and ignore the usage cost. The platform stays flat. The bill does not.
The reality is simple. If your cloud platform becomes the “system of truth,” every other system starts talking to it. Constantly.
Latency Is Still Real (And It Forces Hybrid)
Cloud vendors love to act like latency doesn’t matter anymore. Edge computing solves everything, right? Not quite.
I worked on a project where alarms from a packaging line were sent to the cloud for analytics, then decisions needed to be routed back to the PLC. Round trip was around 180 to 220 milliseconds on a good day. The line needed sub-50ms response for reject logic. So what happened?
The critical loop stayed local, and only telemetry was sent to the cloud.
That sounds reasonable until you live it. Now you have two architectures. Two sets of logic. Two support paths. Two failure modes. Twice the operational complexity.
If your process has real-time safety, quality, or tight control loops, pure cloud-native won’t cut it. You’ll need hybrid.
Hybrid is a great architecture when it’s done intentionally. It’s also a great way to accidentally double your cost if you pretend it will be “simple.”
The Hidden Compute Layers Vendors Don’t Draw
Cloud-native platforms love to talk about serverless and managed services. And yes, they’re convenient. They also tend to be metered in more places than people realize.
In most cloud-native IIoT designs, you’re not running one compute layer.
You’ve got:
- The ingestion layer (MQTT, gateways, buffering)
- The transformation layer (contextualization, mapping raw tags into assets)
- The storage write layer (time-series writes, batch commits, indexing)
- The query layer (serving dashboards and applications)
- The integration layer (APIs and event triggers)
- The analytics layer (jobs, feature engineering, training)
- The orchestration layer (monitoring, retries, routing, rules)
In one evaluation, we mapped the real data flow from edge to dashboard. Seven distinct compute stages. Each metered separately. The vendor estimate covered maybe three.
This is where “managed service convenience” becomes “managed service stacking.”
Everything is pay-per-use. Everything runs somewhere. Everything gets billed.
Retention Reality: Industrial Data Isn’t Like App Logs
Manufacturing data is different from IT data. You don’t just keep “the last 30 days.” In regulated environments, retention is driven by compliance, not preference. 7 years, 10 years, sometimes 25 years.
Cloud storage looks cheap at first. And yes, you can archive to cold tiers.
But cold storage has retrieval fees. Cold storage has restore time. And restore time becomes a problem the moment someone actually needs the data.
Vendor Lock-In by Design (Even When They Say “Open”)
Cloud-native platforms love open standards. Until you try to leave.
Your data is in their proprietary lake.
Your dashboards use their widgets.
Your analytics run on their managed services.
Your APIs are wired into their gateway patterns.
I once helped a site evaluate moving from one cloud IIoT platform to another. The data export worked fine. But the logic, visualizations, and integrations were custom.
We estimated nine months and roughly $400K to rebuild what they already had.
That’s not a migration. That’s a reimplementation! And here’s the problem. Most companies don’t budget for reimplementation because they assume “we own our data.”
You might own the data. But you don’t own the system behavior you built around that data.
The Skills Gap Surcharge (The One That Breaks Your TCO)
This is the one nobody prices in.
Cloud-native IIoT requires a different skill set than traditional on-prem systems.
Your automation engineers know PLCs and SCADA. They don’t know IAM policies, VPC routing, TLS cert chains, token lifetimes, cloud observability, or how to troubleshoot packet drops across segmented zones. So what happens?
Either you train them, which costs time and money.
Or you hire cloud engineers, which costs more money.
Or you rely on vendor professional services, which costs way more money.
That cost never appears in the TCO model. Because running cloud-native industrial platforms requires a real operating team. “Pay as you go” becomes “pay as you grow.” Growth means people.
What You Should Actually Ask (Before You Sign Anything)
Next time a vendor shows you a cloud-native pitch, ask them these questions. Then ask them to answer with real numbers based on your volumes.
- What’s the total monthly egress cost if we need to migrate to a different platform in three years?
- How much do API calls cost, and how many will we make for typical integration patterns?
- What is the real cost of keeping 10 years of high-frequency data in queryable storage?
- What happens to our monthly bill when we add advanced analytics workloads and model training?
- What is the skills gap, and what is your estimate for training or professional services?
- What happens when latency spikes or the connection drops?
- How do we operate this day-to-day across plants, time zones, and support teams?
- What exactly becomes reusable if we switch vendors later?
The vendors who give you straight answers. Those are the ones you can trust.
Final Thoughts
I’m not saying don’t go cloud-native.
I’ve architected systems that genuinely benefit from cloud scale and flexibility. Managed services save you patching nightmares. Analytics tools are better than anything most teams will build internally. Multi-site rollout is easier when you’re not shipping servers.
Cloud has real value. But the vendors are selling it as universally cheaper and simpler. That’s just not true.
For high-frequency data with low-latency requirements and long retention periods, hybrid architectures often make more financial sense.
Edge historian for local storage and fast queries. Cloud for advanced analytics and enterprise integration.
You get the benefits of both without paying full freight on data that does not need to live in the cloud forever. But you have to design hybrid intentionally.
Not as a late-stage “fix” when latency and cost surprise you.
Leave a Comment