Your Factory Cloud Bill Is Much Higher Than You Think

Here's the problem, most manufacturers don't talk about. The IoT architecture diagram always looks clean. Senses sit at the bottom, a gateway in the middle, one neat arrow up to the cloud, and then dashboards and AI at the top. Storage looks cheap, so the plan feels obvious. Just send it all. But then dashboards multiply, analysts start exporting data, someone adds a second region for disaster recovery, remote teams pull files back to the plant, and pretty soon the bill starts carrying charges that nobody put in the first budget. It's not because the cloud failed, it's because that data path was never treated as part of the architecture in the first place. So the question isn't, can this data go to the cloud? It's what data earns that trip. Let's put a real cost model around it and build an edge first pattern that actually scales. Start with the charge most diagrams leave out. Egress is a boundary charge, not a storage charge. People often mix up storage cost and data movement cost because both show up on the same invoice, but they're completely different things. Ingress means data enters a cloud provider's network. A sensor gateway in the factory sends a payload to a cloud endpoint and that payload crosses into the provider. Major cloud providers commonly charge little on nothing for this direction, which is why cloud first data collection feels cheap at the start. Egress on the other hand means data leaves a network boundary. Maybe a cloud server sends a file to a plant server, a report goes to a user's browser or a data set travels to another region. And that movement may carry a per gigabyte charge that word boundary matters. Your factory boundary is one. The cloud provider boundary is another. A cloud region can be a boundary and separate availability zones inside one region can be boundaries too. Even a routing service in the middle may process every byte and charge for doing it. Picture a plant connector sending machine data into a cloud tenant. That's one path. Later, an engineer downloads raw data for root cause work to an on-prem tool so data travels back out. A disaster recovery setup copies the same data to a second region. Another path. A service deployed in a different zone reads it from a database replica crossing yet another boundary. The original telemetry didn't get more useful just because it crossed four places but it may have become more expensive four times. This catches teams because storage has a simple mental model. You store one terabyte for a month, you pay a price for one terabyte for a month. Network traffic doesn't behave like that. It follows use, routing, retries, replicas, exports, and architecture choices made by teams who may never see the network line items. A low storage bill can sit beside a high transfer bill, and that isn't strange. It's a normal result when data moves often and storage stays relatively cheap. Think of the network as a set of meter pipes. Each pipe has a source, a destination, a root, and a rate. The diagram line between an IoT platform and a data lake isn't just an integration. It's a pipe carrying bytes all day, whether those bytes support a decision or not. Internet egress is the familiar case. Data leaves the provider and moves across the public internet, perhaps to an office, supplier, customer portal, or plant network. Private connectivity changes the root and may change the commercial terms but it doesn't mean movement becomes free. You still need to understand the circuit, the traffic direction, and the price plan. Cross-region transfer happens when data moves from one cloud region to another. Teams use this for recovery, geographic access, or data residency plans. Those can be good reasons, but they still need an explicit traffic model because a continuous stream replicated across regions becomes a continuous charge. Cross-zone transfers it's closer to the workload. You might deploy services across zones for resilience, which is sensible, yet a broker in one zone, a processor in another, and storage in a third can create constant internal traffic. The cloud may look like one place on the slide, but physically and commercially, it isn't one place. None of this means you should avoid redundancy, private links, cloud analytics, or remote access. It just means each path needs a reason. Resilience has a cost, shared access has a cost, central analytics has a cost, those costs may be worth paying, but only after you know what crosses the boundary and why. In practical terms, stop asking only where data is stored. Start asking where it travels after storage, who consumes it and how often they need it. A data flow without a destination and a decision is just an open meter, so let's follow one machine signal through that meter. The factory data path is rarely one way. Take a normal machine signal, maybe a spindle vibration reading, or a simple state tag from a packaging line. An edge gateway publishes it to the cloud through MQTT and the project team checks the box, connected, but connected to what exactly. That first message might land in an IoT service, which roots a copy into time series storage for dashboards, another copy into a data lake for engineering work, and a third into an event stream for alerts. Each destination has a different team, a different retention rule, and usually a different idea of what the data is actually for. The stream keeps branching. A production manager opens a dashboard from the plant, a reliability engineer queries history from a laptop, a data team pulls a training set into a notebook, a supplier receives an extract through an API because their service agreement requires machine evidence. None of those uses sound unreasonable on their own. They put them together and one sensor feed turns into several active data flows. This is where the phrase, "We only send one MQTT stream becomes misleading." MQTT describes a message path between a publisher and a broker. It doesn't describe every subscriber, storage ride, replication job, export process, or downstream tool that touches the message after it arrives. The connection may be one stream from the factory, while the cloud estate creates many copies from that stream. Think about a line that produces status events, the cloud stores the events, then a reporting workload reads them, another job joins them to MS order data. A data science team copies a subset to another workspace. Later, somebody exports an investigation file because a customer asks why a batch was delayed. The machine generated the data once. The architecture moved it many times. Return traffic is easy to miss because it often starts later after the original IoT project has already gone live. The plant may retrieve cloud hosted reports each shift. A local application may pull reference data, thresholds, or model packages from a central service. Remote support staff may download logs and evidence files. A cloud dashboard viewed on a large screen in the control room is still a data path back into the site. Backups create their own return path. You may send plant data to the cloud for attention. Looks tidy during normal operation. Then a restore test begins, or a real incident forces the team to retrieve a large archive back to the factory or another environment. Recovery needs that data to move in the opposite direction at the moment when people are already under pressure. That's not an argument against backup. It's an argument for treating recovery like a real workload instead of a sentence in a policy document. Separate projects create another problem. The maintenance group installs a condition monitoring platform. The quality team builds a vision archive. Corporate IT creates a data platform for enterprise reporting. Each project connects to the same shop floor, often through its own collector, gateway, or vendor portal. Nobody intended to duplicate the data. Nobody sat in a room and chose to pay for the same machine state three times. Yet the result can be three parallel paths, each with its own credentials, cloud storage, exports, and support burden. Picture a plant with one PLC network and three teams asking for real time visibility. One collects tags for OEE, one pulls them for maintenance, one forwards them for a digital twin pilot. If they don't share a data model and a governed route, the plant becomes the source for three separate pipes. The cloud bill isn't the only cost. You also lose confidence when the three systems disagree. This is the part that gets uncomfortable. Data duplication rarely comes from bad intent or poor engineering in a single team. It comes from local success without shared architecture. Each team solves its immediate problem. And the full path only becomes visible when finance asks why network charge is climbed. So don't count connections, count movement. For every signal, list the original source, each processing hop, every copy, and every consumer. Include the dashboard, someone refreshes all day, the scheduled export that runs overnight, the data set copied for analysis, and the recovery workflow nobody has tested recently. That becomes the real unit of analysis, not a device, not a topic, not even a data lake. Each copy, each hop, and each consumer. Once you see the path that way, public pricing stops looking like a minor technical detail. Put those rates next to the actual volume, and the numbers start changing the design conversation set. Public pricing is only the starting point. Before we turn this into a spreadsheet exercise, use public prices for what they are, a warning sign, not a forecast. For a common reference point, AWS Internet egress from some regions starts around nine cents per gigabyte in its first volume tier. Azure Zone one lists roughly 8.7 cents per gigabyte beyond its included allowance. Google Cloud uses tiered rates too, and the rate depends on where the data starts and where it lands. Those numbers look small because they are small at the unit level. A single gigabyte at nine cents won't trigger an executive meeting, but factory data doesn't arrive as a single gigabyte. It arrives every second through every shift across every connected asset, and often it keeps moving long after the machine created it. Take a stream that sends 100 gigabytes per day out of a cloud environment to plant users a supplier or another external system. At a simple nine cents per gigabyte reference rate, that one path reaches about nine dollars per day. Over 30-day months, that's about $270. Then add another plant, another data consumer, another region, or an export job that nobody sees as a network workload. The unit rate didn't change, the architecture did. And that is only internet bound traffic. You may pay a different rate when traffic moves between cloud regions. You may face a separate rate when services exchange data across availability zones within a region. A private connection can change the commercial model again. A managed service may include its own data transfer rules and a gateway can introduce a processing charge on top of the underlying network route. So don't take a generic public rate, multiply it once and call it the budget. The actual price depends on the source region destination, service involved, monthly volume tier, currency, and the commercial agreement your company signed. Enterprise contracts may change the rate, credits may hide it for a while. One service may include a transfer path that another service builds separately even when both sit in the same provider. Cloud pricing has a talent for looking simple from 30,000 feet. You see data transfer out on a rate card. Then the invoice arrives with service names, region codes, usage types, and charges that don't resemble the clean architecture diagram from the project kickoff. That's not because someone is trying to make the invoice unreadable, although it can feel that way. It's because the provider meters real routes and real routes have detail. Your invoice and contract terms decide what you actually spend. That means your finance and cloud teams need to look at both. Public pricing helps you ask the right early questions. It helps you spot when a proposed design could become expensive at scale. But it cannot tell you the final cost of your environment without the actual route, the actual volume, and the actual agreement. There is another point that often confuses project teams. Inbound data commonly looks free. While the data leaving later carries a charge, that creates a very predictable behavior. A team begins by sending raw factory data into the cloud because the first transfer doesn't hurt the budget. Storage also looks manageable. Months later, users want dashboards outside the cloud boundary, engineering wants extracts. Another environment needs a copy and operations needs data back at the site. The cost appears when the data starts serving people and systems in other places. Free inbound transfer is not proof that the full data lifecycle is cheap. It only means the first leg has a favorable rate. For a manufacturing architecture, that distinction changes how you plan. You don't ask only, what does it cost to ingest this telemetry? You ask, who reads it later? From where, in what form, and how often? If the answer includes a daily export of raw records, or frequent retrieval of high rate files, the low cost ingest path tells you almost nothing about the total network cost. This is why provider arguments often start too early. Teams compare AWS, Azure, and Google Cloud rates before they have measured the data. They debate whether 7.8 or 9 cents per gigabyte is better, while the architecture still sends a stream that no named user needs in raw form. Saving a fraction of a cent on unnecessary movement is still unnecessary movement. If you first calculate the volume, then calculate the shape of that volume over time. Only after that should you compare providers, contracts, routes, and services. The unit error, counting devices instead of samples. When teams estimate factory data volume, they almost always start with the wrong number. They count devices. We have 400 machines, or we're connecting 12,000 tags. That tells you something about scope, but it tells you almost nothing about the actual bytes your architecture will move in store. Start with the signal itself. What's the sample rate? How big is each payload? How many channels sit behind that device? Does the signal run all day, only during production, or only when an event happens? Then ask how long you keep it at each layer? Those inputs determine your real volume. A status bit once per minute is practically free from a data point of view. You might record whether a conveyor is running, stopped, starved, or blocked. That record can carry a timestamp and asset ID, a state value, and a quality flag. Useful data, but low volume. Now compare that to a vibration sensor capturing a waveform at kilohertz rates. That sensor may look like one device in your asset list, right beside the conveyor status tag. Yet it produces a continuous stream of samples, often across several channels, with a very different storage and network profile, same number of devices, completely different data volume. That's why device count is a dangerous planning unit. A factory with 100 low rate state signals may produce less traffic than one machine fitted with high rate condition monitoring. If you use device count as the basis for a cloud budget, you can be wrong by several orders of magnitude before the project even starts. Here's the basic formula. Samples times bytes times times assets, that's the first calculation. You can expand it when you need more detail, but don't skip it. For each signal, take the number of samples per second. Multiply that by the payload size in bytes. Multiply again by the number of seconds the signal runs, then multiply by the number of assets that produce it. If one device has several channels, include them too. A three axis accelerometer isn't one stream in practical terms, it is three measurements, often sampled at the same rate. Let's keep this grounded. A machine state signal might send one record every few seconds, or only when the state changes. A temperature reading might arrive once each minute. Those are time series records, but they usually stay manageable because their cadence is low. High rate waveform capture is different. It records the shape of a signal over time. That matters when you need to see a bearing defect, a resonance pattern or a transient event that an average value would hide. The data can be useful, but you must budget it as a continuous stream, not as another tag. Then you have images in video. A vision station might create one image for each inspected part, perhaps more than one camera angle. A camera used for continuous observation creates a very different pattern. Video carries a sustained payload, and the file size depends on frame rate, image size, codec, and scene activity. Calling both camera data tells you nothing useful for capacity planning. Logs create their own surprise. Normal application logs may stay small until a fault, a debug setting, or a loop starts generating far more records than expected. Network captures can become large very quickly because they preserve raw traffic. Model artifacts matter too. A trained model, a model update, or a data set used for testing doesn't behave like telemetry. It tends to move in bursts, but those bursts can still be large. Data type changes the question you ask. For event data, ask how often events occur and how much context each event carries. For time series data, ask about rate and retention. For images, ask about count, resolution, and compression. For video, ask about duration encoding and whether anyone needs continuous footage. For logs, ask what happens during an incident, not just on a normal day. For model files, ask where the model needs to run and how often it changes. The raw signal calculation also isn't the final number. Real systems add overhead. Every message needs more than the sensor value. You may attach a timestamp, topic name, device ID, asset hierarchy, unit, quality code, schema version, and security data. For very small payloads, that surrounding information can outweigh the measurement itself. Protocols add bytes as well. Headers, framing, encryption, acknowledgments, and keep alive messages all consume network capacity. This doesn't make the protocol wrong. It simply means a spreadsheet that counts only the raw sensor value will understate the traffic. Retrieves matter when a plant network or one link drops. Store and forward systems should retry because lost production records are not acceptable. But if the receiving side can't identify a duplicate correctly, one interruption can create repeated cloud rights for the same data. Duplicate collectors cause the same effect in a quieter way. Two systems read the same source, package it differently, and both send it onward. You need to measure payloads where they actually move. Not only where they originate, take a representative hour from a real line, capture the records by class, count messages, bytes, retries, and duplicate deliveries, then project that data across a day, a production week, and the number of assets you plan to connect. That gives you a starting point that architecture and finance can both use. And once you run that formula against vibration monitoring, the numbers move very fast. Vibration data turns small signals into terabytes. Let's put real numbers on one type of signal because vibration data exposes the planning mistake very quickly. Assume one accelerometer captures a single channel at 32 kilohertz, that means 32,000 samples every second. Assume each sample uses 16 bits or two bytes. The raw stream works out to 64,000 bytes per second before you add timestamps, message headers, encryption, asset context, or any other system overhead. Over a day, that one channel produces roughly 5.5 gigabytes of raw waveform data. One sensor, one channel, one day. That number doesn't sound extreme in isolation. You can store 5.5 gigabytes without much trouble. But vibration monitoring rarely stops at one sensor, and it rarely stays limited to one asset once a pilot proves useful. Put sensors on 10 motors across one production line using the same capture rate and format and you're already near 55 gigabytes per day of raw data. Expand that pattern across several lines, then across a full site, and you move into hundreds of gigabytes or terabytes per day without adding vision systems, PLC logs, quality images, or anything else. The arithmetic isn't the point. Not every plant samples at 32 kilohertz, not every sensor runs continuously. Some systems use lower rates, event capture, or device side processing. The point is that a small physical sensor can create a large digital stream when it samples fast enough. This is where people get misled by the word telemetry. A machine state tag and a raw vibration waveform both get called telemetry, yet they don't belong in the same capacity discussion. A state tag answers a simple question, running stopped, faulted, or idle. A waveform preserves the actual motion of the machine across thousands of points each second. That raw waveform can be exactly what you need during an investigation. Say a maintenance engineer suspects a bearing issue. A broad health score may tell you something changed, but it may not show the frequency, pattern, impact behavior, or transient condition that helps narrow down the course. Raw evidence gives engineers a chance to inspect the signal, compare it against an earlier capture, and test whether the apparent fault is real or just noise from the process. For fault work, raw data earns its place. But during normal operation, the same question needs more discipline. If the motor runs within its expected range for weeks, what does a full permanent copy of every healthy waveform enable that a smaller record cannot? If no person, model, or maintenance process will inspect that raw stream, then sending it continuously to remote storage turns a possible diagnostic asset into a standing cost. You don't need to pretend raw data has no use. That's not the right argument. Raw waveform data can support failure analysis, model development, warranty review, and occasional engineering work. It can also help when a new monitoring method needs a baseline. But those are bounded needs. They do not automatically justify a permanent cloud journey for every second of normal machine behavior. Think about what an operator or maintenance planner needs most days. They may need a current condition score and alarm when the score crosses a limit, the asset identity, the time of the event, and enough context to act. They might need a short waveform window before and after the event. Those records can support a real maintenance decision without moving an entire continuous stream away from the machine. The distinction changes the architecture. Instead of treating the cloud as the first home for raw vibration, keep a local rolling buffer, near the asset or at the site, process the stream where it appears. When the system detects an unusual pattern, retain the bounded evidence window and transfer that package with the score, the time, and the operating context. Now the cloud receives something a person or another system can use. It receives evidence when evidence is needed, not an endless recording of normality. There's a practical reason for this beyond cost. Fault investigations often need local machine context as well. Speed, load, product type, tool state, maintenance history, and machine mode help explain a waveform. A raw file sitting alone in remote storage may look complete while the actual conditions that gave it meaning remain somewhere else. So don't ask whether vibration data belongs in the cloud as one broad category. Ask which part of the vibration data supports which decision and when. Because the answer depends on whether the signal changes a decision. Not all factory data has the same half-life. Here's a practical way to decide where data belongs. Look at how long it stays useful. I'm not talking about radioactive decay. I mean, the time before a piece of data loses most of its operational value, some data matters for milliseconds, some matters for a month. Treating both the same way creates bad architecture because the people, systems, and decisions around them are completely different. Start with the fastest class. Data tied to safety, control, interlocks, and local alarms. A machine detects an unsafe condition. A guard opens, pressure moves outside an allowed range, a drive reports a fault that needs an immediate reaction. That data belongs close to the machine because the decision belongs close to the machine. A cloud round trip might be fast on a good day. It still depends on a one-link, rooting service health, identity checks, and a number of components outside the control cell. None of that belongs in the path for a safety response or deterministic control. The PLC safety controller and local OT systems own that job. The cloud can receive a record that the event occurred. It can support later analysis, but it shouldn't sit between a dangerous condition and the action that protects people or equipment. That's a clean boundary. Now look at data with a half-life measured in minutes or shifts. Machine state production counts, downtime reasons, material consumption, and job progress fit here. You don't need each value, the instant it appears to make a safe machine decision, but the people running the line needed while the shift still has time to react. Picture a supervisor looking at a line that has stopped four times since lunch. They need to know whether loss occurred, what state the machine entered, which work order ran at the time and whether the same pattern keeps returning. That information supports real-time visibility without pretending every raw tag value needs long-term storage. This is where context starts doing more work than volume. A stop event with a timestamp, duration, reason code, asset ID and order context can tell a production team far more than a massive list of unchanged state values. The event becomes a usable operational fact. It explains something that happened and gives the next person a place to start. Then you have data whose half-life stretches into weeks and months. OEE trends, scrap patterns, energy baselines, throughput by product family, and recurring failure modes sit in this group. These records support planning, continuous improvement and cross-site comparison. They don't need a millisecond response, but they need consistency. This is a good place for shared cloud analytics because the question often reaches beyond one machine or one shift. Are two plans losing time for the same reason? Did a process change alter scrap rates over several months? Is energy used changing after a new product mix came online? Those questions need history, governance, and a common way to describe the work. A well-run cloud data platform can help connect the dots between IT and OT here, as long as the records arriving there mean the same thing across sites. Now, don't confuse age with value. All data can still matter. A production record may need to remain available for traceability, quality claims, warranty work, customer obligations, or internal audit. Its operational half-life may have passed, but its business retention period may continue for years. That distinction matters. Raw evidence is one category. It preserves the detailed signal, image, log, or machine context needed when someone must investigate a specific event. The rife facts are another. They turn that detail into a condition score, downtime event, count, aggregate, or quality result that people can use repeatedly. Long-term business records are different again. They preserve what was produced when it was produced, which material and work order applied, and what quality outcome the process recorded. Those records don't need the same data rate as raw evidence, but they need traceability and clear ownership. So a mature architecture doesn't ask one blunt question, cloud or edge. It asks how long the data stays useful in its current form, who needs it during that period, and what decision it supports. A local alarm may have seconds of operational value. A downtime event may matter across a shift. A monthly energy trend may support a planning decision long after the original readings disappear. Once you see those different half-lives, you can start placing data by its actual value, rather than by the fact that a sensor happened to produce it. That builds a hierarchy of data value. A data value hierarchy for the shop floor. Once you sort factory data by the decision it supports, a practical hierarchy starts to appear. It isn't a vendor model, and it won't look identical in every plant. But it gives you a disciplined default, instead of treating every bite as equally worthy of cloud storage. T-R-1 is raw, high-rate data. This includes continuous waveforms, unfiltered vision input, detailed diagnostic traces, and similar streams where the value sits in the fine detail rather than a simple result. Keep this local by default close to the source and close to the people who may need to inspect it. That doesn't mean deleted immediately. It means keep it where it can support local diagnosis without creating a permanent remote data burden. The data may be useful, but its useful form is often short-lived and site-specific. T-R-2 is filtered events and short interval aggregates. A condition score changes, a machine enters a fault state, a temperature trend crosses a limit, a one-minute record captures cycle count, runtime, energy use, and data quality for a defined asset. This tier often earns selective transfer because it has already become smaller and more meaningful. You aren't moving every measurement. You're moving a record that describes a change, an exception, or a bounded operational period. The receiving system also needs enough context to trust the record. An event without an asset ID timestamp unit, quality state, and production context can look precise while telling you very little. Small data isn't automatically good data. tier three is the part most enterprise systems should be very comfortable receiving. Shift KPI is a completed production records, traceable order facts, quality outcomes, downtime events, and material genealogy fit here. These records support reporting, planning, traceability, and coordination between functions that don't sit next to the same machine. Cloud storage and shared data services make sense for this tier because the consumer often sits outside the site. A central team may compare output across plants. A planner may need confirmed production facts, quality may need to trace a finished lot back through the process. These aren't just summaries for a dashboard. They are business records and they need clear definitions. If one plant records a microstop is downtime, while another ignores it, sending both records to the same cloud platform won't fix the disagreement. You get a polished report built on two different meanings. Tier four contains data where cloud use has a clear case, cross-plant trend work belongs here. So do carefully curated model training sets, shared reference data, and fleet level analysis where the question cannot be answered from one site alone. A cloud environment can bring together years of governed records from many plants, then let teams compare patterns across product families, equipment types, and operating conditions. That is a different job from reacting to what a machine does right now. It needs broad access, a common data model, controlled retention, and compute that can grow when the analysis grows. Model training belongs in this tier two with a bit of care. Training data should not mean copy every raw signal from every plant forever. A useful training set needs labels, known operating context, lineage, and a reason for each sample. More unfiltered data doesn't automatically produce a better model. Sometimes it just produces a larger storage account and a harder problem. So the hierarchy looks like this. Raw, high-rate streams stay local unless a defined case pulls them upward, filter events and aggregates move selectively. Traceable operational facts move into shared enterprise systems, cross-plant analysis and curated learning data justify cloud scale because they need a view beyond the site. The rule behind all four tiers is simple. Move data only when a named consumer needs it to make a named decision. Not someone might use it later, not the platform can ingest it. A real consumer, a real decision, and a minimum data form that supports that decision. If nobody can name those things, the transfer has not earned approval. Most cloud first diagrams reverse this logic. They begin with a broad arrow from every source into central storage. Then hope somebody finds a use for it later. Why send everything became the default. So why did so many factory architectures end up with that broad sensor to cloud pattern in the first place? Here's how it usually starts. Cloud services practically give away the first step. Sending data upward carries almost no direct cost. So a project team sees a simple path. Connect the gateway, publish the data, land it in storage, and sort out the use cases later. The first month looks fine. The first pilot looks even better. That leads to a false conclusion. If it's cheap to send data in, it must make sense to keep sending all of it. But here's the thing. Nobody flags at that point. A factory data stream doesn't end when it enters a cloud endpoint. It starts a life there. People query at services copy at reports pull from it, and new teams find it because it's available. A low friction ingest decision quietly becomes a long term data placement decision, often without anyone ever making that choice on purpose. IoT reference diagrams helped create this habit too. You've seen the diagram. Devices and PLCs at the bottom are gateway or broker in the middle cloud services at the top, with clean arrows moving upward through a neat stack of icons. It communicates connectivity well enough, but it leaves out the things an operating team actually has to deal with. Byte volume, retention windows, consumers, duplicate collectors, and the real path a record takes after it arrives. An arrow on a slide doesn't show a monthly meter. It also doesn't show who owns the data once the pilot team moves on. The diagram implies all source data follows the same path, because that makes the architecture easy to explain. Yet a machine state event, a camera frame, a diagnostic log, and a high-rate waveform don't have the same purpose, rate, or useful life. Drawing them all with one arrow makes them look equivalent when they aren't. This gets harder because pilot projects start small. A team connects a few machines and keeps every record because storage feels cheap and because having more data seems safer than having less. At that scale, even an inefficient route might not show up as a serious problem. The team proves the connection works, builds a dashboard, and gets approval to expand. Then the same pattern rolls out to the next line. Nothing changes in the design except the number of assets. The gateway configuration gets copied. The topic structure gets copied. The data route gets copied. Every signal travels upstream at the same cadence. Even when the new line has a different process, different failure modes, or no defined cloud consumer for most of the data. Success at pilot scale can hide a bad default at planned scale. I've seen this mindset in plenty of technical conversations. Someone asks why raw records need to stay available forever. And the answer is usually just in case. That answer comes from a reasonable fear. Nobody wants to delete evidence before an engineer discovers they need it. The issue isn't caution. The issue is leaving caution without an owner, a time limit, or a decision rule. If no one owns retention, every project keeps its raw data. The maintenance group keeps condition records. Quality keeps images. The platform team keeps message history. An external vendor retains a portal archive. Each group can explain its own choice, but nobody can explain the total amount, the overlap, or when the data should stop existing. Just in case turns into forever by default. That isn't a storage policy. It's the absence of one. There's also a cultural reason. Cloud teams often get measured on how fast they can connect systems and expose data for reporting. O.T. teams get measured on stable production. Neither group naturally owns the question of whether an unchanged sensor value should cross a site boundary every second for the next five years. So the broad arrow survives because nobody has a reason to challenge it during delivery. A fire hose looks tidy in the slide deck. It's less tidy when someone needs to explain why the same data appears in four places, why the raw archive keeps growing, or why an engineering request now involves retrieving files from a remote platform that the plant doesn't control directly. The better default starts with restraint. Collect what you need locally, turn it into the form the next decision needs, and move only that form when there's a clear reason to share it. You can always define an exception for a fault capture, a model study, or a traceability record. Those exceptions should be explicit, though. They shouldn't become the design pattern for everything else. Once data leaves the plant, it starts attracting more systems. Data gravity changes the architecture over time. Once data starts accumulating in the cloud, it changes the shape of the system around it. That's data gravity. Large data sets pull compute, tools, copies, and teams toward the place where the data lives. It's not magic. It's just friction. If six months of high rate machine data sits in a cloud store, the next analyst will naturally run a notebook near that store. The next dashboard team will point its model at the same data. An external platform will ask for a connector. Pretty soon somebody creates a replica because another workload needs better response time or a separate environment. The data attracts work because moving the work looks easier than moving the data. That can be a sensible choice when the data genuinely needs enterprise scale. If you are comparing performance across many plants, joining production records to supply chain data or preparing a control data set for model training, central compute near central data is often the right pattern. But raw factory data creates a different problem. Take a large high rate archive that started as a condition monitoring pilot. It may sit in cloud storage because nobody wanted to lose it. Then more consumers arrive, one team wants access for diagnostics. Another needs samples for a maintenance model. A third builds a dashboard. Each new use tends to create a new permission path, data pipeline, workspace or copy. That original stream becomes part of the enterprise estate. And that's when the cost of a casual early decision starts showing up, not just in storage or network charges, but in ownership, who defines the asset names, which timestamps are trusted, what happens when a sensor configuration changes? Who decides whether a downstream data set still has the right to exist? The cloud didn't create those questions. It exposed them at a much larger scale. Picture a reliability engineer who now needs historical waveform data back at the site because a machine issue needs hands-on diagnosis. The data might be technically available in the cloud, but getting it back can involve access approvals, a retrieval process, transfer time, local storage capacity, and proof that the restored files match the original record. By that stage, just bring the data back is no longer a small task. It becomes a program. Someone has to map dependencies, find every copy, validate schemers, check retention rules, deal with vendor tools, and confirm which system holds the authoritative version. The more teams build on the remote data, the more carefully you need to unwind it. That's why data gravity needs to be a design choice. You decide where data should accumulate based on its real use, not because a connector made the first route easy. Some data should pull work toward the cloud, enterprise reporting, fleet analysis, governed business records, and shared models all have a reason to live where many teams can reach them. Other data should remain near the plant because the operational needs stays near the plant. A high-rate history used mainly for machine diagnosis should stay close to the maintenance process that gives it meaning. The source of truth for that history can sit at the edge or site layer with defined windows and controlled access. You can still send selected evidence upward when a specific case needs wider review that is not isolation, it's proper placement. The factory keeps the data that supports local operation and local investigation. The cloud receives the data that supports shared analysis and enterprise decisions. Both layers can work together, but neither needs to pretend it owns every bite. This also gives you more freedom later. If a cloud analytics tool changes, you can move curated operational facts without dragging years of raw signals through a migration. If a site needs to investigate an event, the detailed evidence stays available where the process and people already are. Keep the source of truth close to the operational need. Move the derived facts to the shared need. Once that placement becomes deliberate, the next issue comes into view. Even inside one cloud provider, network topology can add charges that never appear in the first architecture diagram. Cross-zone traffic can tax your own architecture. Here's something that catches even experienced cloud teams off-guard. Data can move between two workloads you own inside one provider region and still create a transfer charge. A common public reference rate for cross-availability zone traffic runs about one cent per gigabyte in each direction. That sounds too small to worry about. And most per gigabyte numbers do right up until the traffic runs continuously between services that were never placed with their conversation pattern in mind. Availability zones exist to separate power, networking and failure domains within a cloud region so a service can survive a problem in one location. That's a sound resilience goal. The mistake comes when teams spread every part of a high volume data path across zones without looking at where the bytes actually travel, picture a factory telemetry workload after it reaches the cloud. Your message broker lives in zone A, the stream processor lives in zone B, and the time series database sits behind a replica arrangement that stretches into zone C. Every single message crosses zone boundaries before anyone even opens a dashboard. Nothing is broken. It may even meet the availability design. But here's the catch, the data is no longer moving once. It's moving through a distributed system where each hop has a physical placement and sometimes a charge attached to it. Message brokers make this easy to overlook, a factory gateway publishes a record. The broker accepts it, then copies it to another broker for replication. A processing service reads it from a different zone, writes a transformed result to a database, and that database may replicate the change again. The original payload might be small, but the system repeats that path thousands or millions of times. Replication isn't free just because it's internal. Database is create the same pattern. A service in zone A writes a record to a primary database in zone B, the response travels back to zone A, then the database sends changes to a replica in zone C. If another workload reads from that replica, the next request and response may cross zones again. You can end up paying for a round trip, a replication path, and a second request path around one operational fact. Processing jobs add more movement, a scheduled job reads a day of telemetry from storage in one zone, processes it in compute somewhere else, then writes the output into a database or lake house that sits across another boundary. The job may only run once per day, but the data volume can be large enough that placement matters more than the schedule, then retries enter the picture. A consumer loses its connection, times out, or can't confirm a right completed, so it tries again. That's correct behavior for reliable delivery, but each retry repeats request data, response data, and downstream replication. If the workload lacks idempotent handling, you may also create duplicate records starting another chain of reads, writes, and copies. The bill follows the bytes, not your intent. This is why I separate resilience from careless placement. Multisone design can protect services that need continuity through a zone failure, and for many enterprise systems, that's a justified cost. You shouldn't remove redundancy just to make a billing chart look better, but resilience has to match the workload. You need to ask whether this high-rate stream needs every component active across zones at all times. Can the processing path remain close to the broker that receives the message, while the system keeps a controlled fail-over plan elsewhere? Can readers prefer a local replica without weakening recovery? Can asynchronous workloads process data near the storage that holds it? Those questions don't weaken the architecture. They force you to state what it protects against. A lot of cloud diagrams use multiple zones as a visual signal that the system is serious, and fair enough, yet high availability isn't achieved by scattering components randomly and hoping redundancy sorts itself out. It comes from understanding failure modes, data consistency, recovery targets, and the traffic created while the system operates normally. For factory data, this matters because the volume often begins at the edge, but grows inside the cloud. You may have already filtered the raw stream correctly, then lose the benefit because the reduced data bounces between broker, processor, database, and analytic service across zone boundaries all day. So inspect the call path, not just the deployment count, for each high volume workload, map where messages land, where processing runs, where rights occur, and where replicas live. Look at the normal path first, failure handling matters, but normal traffic is what you pay for every day. And even a carefully placed workload can take an expensive detour when it passes through certain managed network components. NAT, gateways, and the cost of taking the long route. Sometimes the expensive path isn't caused by a large sensor stream. It comes from rooting. A common public AWS reference rate for NAT gateway processing is about four and a half cents per gigabyte. That charge applies to every byte the NAT gateway processes, and it sits on top of the normal data transfer charges for the path beyond it. So a road can cost more, not because the payload changed, but because the packet took an extra stop. This matters in factory connectivity patterns because edge connectors often sit on a private subnet. That's usually the right security posture. You don't want a gateway on the shop floor exposed directly to the public internet just to publish machine data, but private subnet design has a rooting consequence. Picture an industrial connector that needs to reach a cloud IoT endpoint. The connector sits in a private network segment, and its outbound traffic routes through a NAT gateway then reaches the cloud service. Every telemetry record, acknowledgement, configuration request, certificate check, and retry passes through that component. The route works, but the meter runs too. Now at the usual factory behavior, the edge connector publishes operational records, pulls down a new configuration, a central service sends a model package or rules update. A local system asks for a small reference file. Each exchange looks minor when viewed as an individual request, but the NAT gateway processes the total volume, not just the part that caught your attention. The same issue appears with what I call a hairpin path. A workload may need to reach a cloud service that sits logically close, perhaps in the same provider environment, but the route still sends traffic out through a NAT device and then back to what a service endpoint. You end up paying to route internal cloud traffic as though it needed a general outbound path. That is a design problem, not a sensor problem. For certain provider services, a private endpoint or service endpoint can give the workload a more direct route. The exact option depends on the service and your network design, so don't treat this as a universal configuration change. The point is simpler. Before you accept NIT processing as a permanent cost, verify whether the traffic genuinely needs to go through NAT. I've seen teams start with the correct security pattern, then leave the first route in place as the architecture grows. A connector goes through NAT because that was the fastest way to get a pilot working. Later, object storage, monitoring, identity services, logging and internal APIs all use the same route. The gateway stays in the middle because nobody revisits the network path. Then, finance sees a growing NAT line and somebody starts asking whether the factory sends too much data. Maybe it does, but trace the route first. You need packet level and flow level evidence, not a guess based on service names. Find the source subnet, identify the destination, check the route table, firewall path, NIT processing, private endpoints and the return path. Measure bytes in both directions, then map the traffic to the workload that created it. A NIT charge tells you traffic passed through NAT, but it doesn't tell you whether that traffic came from vibration data, log uploads, dashboard refreshes, image transfers, or a service that keeps downloading the same file because its cache is wrong. That distinction saves a lot of wasted effort. Think about a plant where the OT team spends weeks reducing telemetry payloads by a few percent while a cloud platform service sends large diagnostic archives through a NAT path every night. Both activities involve data movement, but only one of them may explain the cost increase. Without route tracing, the team optimizes the visible source and misses the expensive route. This is why your architecture diagram needs another job. It shouldn't just show trust boundaries, protocols, and service names. It should show the billing path. Draw the edge connector, the private subnet, the NIT gateway if traffic uses it, the endpoint, the region, and the systems that pull data back. Put expected byte volume on the arrows. If an arrow crosses a meter at service, label that too. An architecture diagram is a billing diagram. The symbols may look different, but the bills follow the same path. Once you see the route clearly, you can decide whether to keep it, replace it with a more direct private path, cache data locally, or change the workload itself. None of those choices require weakening security. They require treating network design as part of the operating cost and routing is only one multiplier. Replication can turn one stream into several streams before anyone notices. Replication and backup, the copy problem. Replication sounds straightforward. Take data from one place and keep another copy somewhere else. In a factory setting, that copy might support availability, disaster recovery, or a rule that requires data to live in a specific geography. Those are all valid reasons, but they aren't the same reason and mixing them up is where the trouble starts. Cross-region replication usually appears when a team wants protection from a regional outage, needs a recovery copy closer to another business location or has to meet data residency requirements. A cloud storage service can automatically copy new objects from one region to another, and that feels reassuring. It should, but every object copied is also data moving out of the source region, and that movement has a cost. Public examples for S3 cross-region replication can fall somewhere around two to nine cents per GB, depending on the source and destination regions. Don't use that range as your budget number, your provider, regions, service tier, and contract decide the real charge. Use it as a reminder that replication is an active data path, not a free setting you tick once and forget. For a small set of curated production records, that cost may be entirely reasonable. For raw images, continuous waveforms or large local diagnostic buffers, copying everything to a second region can double the movement before a single person has used the data. The same confusion shows up with backup. A retention policy answers one question. How long should this data remain available? A replication policy answers a different one. How many copies need to exist? Where should they live? And how quickly must one replace the other after a failure? Those policies often get mixed together because both involve copies, but they solve different problems. You might retain a local raw waveform buffer for a short diagnostic period then deleted when the window expires. That is retention. You might keep a curated set of anomaly records in a second cloud region, so a regional incident doesn't remove your ability to investigate a serious quality event. That is replication. One does not imply the other. A common failure pattern starts when teams decide to retain raw data for a long time, then replicate it because long term data feels important, then add another backup because the replicated copy doesn't meet the recovery rule. Soon, one stream exists in primary storage, secondary storage, a backup vault, an export location, and perhaps a vendor managed archive. Every copy has a purpose on paper. Few teams can explain the whole set. Backup exports can create a similar problem, a side sends data to a cloud backup service, then a scheduled process exports it to another environment for compliance or independent recovery. Again, that may be justified, but the export itself moves bytes, and a restore can move even more. The restore path deserves special attention because it often remains theoretical until a drill begins. Picture a recovery test after a production incident. The team needs a historical data set back at the plant or in a recovery environment, so they can rebuild the service and validate the records. Suddenly, data that sat quietly in remote storage must travel back across the network under time pressure. The question is no longer just, do we have a backup? It becomes, can we retrieve the required data within the recovery target at an acceptable cost and in a form the plant can use? That is why disaster recovery drills matter. They expose the difference between a backup object and a recoverable system. They also reveal whether a large restore produces a transfer charge that nobody included in the annual plan. You don't need fewer copies by default, you need intentional copies. For every replica, backup and export require four answers. What risk does this copy protect against? What recovery target does it support? Who owns the decision to keep it? When should the copy expire or move into a lower cost retention state? If the team cannot answer those questions, the copy has no operational contract. It may still exist for a good reason, but nobody has proven it. The aim isn't to make recovery cheap by weakening it. The aim is to avoid replicating data that doesn't support a defined recovery need while protecting the records that do. That gives IT, OT, security and finance a shared way to talk about what each copy actually does. And replication is only part of the movement story. The factory also pulls data back for daily work. The return path reports, exports and remote access. A lot of cloud cost discussions stop at ingestion. Data leaves the factory, lands in the cloud, and the project team counts that as the root. But people still need to use the data. A production manager opens a Power BI dashboard from the plant network. An engineer exports a data set to investigate a quality issue. A supplier receives a file through an API. A local tool pulls records from a cloud database because someone connected it that way during a pilot. Each of those actions creates a return path. The cloud does not just collect factory data, it serves it back out. Take a normal analytics pattern. A central data platform processes production and quality records, then sends a scheduled extract to an on-premises reporting tool every morning. The file might contain a day of machine events, production facts and quality results. That sounds harmless. And for the right data set, it probably is. The problem begins when the extract includes raw records because nobody decided what the receiving tool actually needs. A local report may only need downtime events by asset and shift. Instead, it receives high detailed telemetry for every machine because the source query selects everything available. The report still shows one chart, the network still moves the full file. And when the report refreshes every day, that path becomes a recurring operating cost. The same pattern appears with suppliers and external services. A supplier may need evidence tied to a defect, a batch or a maintenance claim. That is a defined request with a defined data set. But APIs often grow without discipline. Somebody starts with a useful integration, then adds more fields, more history, more frequent calls, and a retry process that asks for the same records again. Soon the API becomes an export route nobody owns. Remote dashboards deserve the same attention. When people at the plant view a cloud dashboard, the browser requests data, visuals, filters, and refresh results across the site connection. One person looking at a shift report isn't likely to concern anyone. A control room wallboard repeated browser sessions, auto refresh pages, and multiple teams checking the same detailed view create ongoing traffic. That traffic may be worth it. Real-time visibility often is. Still, ask what the screen must show. Does an operator need years of raw history rendered in a chart? Or do they need the current machine state, the active alarm, the last stop reason, and a clear next action? Those are different workloads. For local operational use, a local cache can help. If the same site users repeatedly read the same approved data set, keep a controlled copy near the consumer, rather than asking every browser session to pull the same content across the wall. That cache needs a refresh rule, a clear source, and a known limit. Otherwise, it becomes another unofficial database, which nobody enjoys discovering during an incident. Scheduled extracts can work the same way when they match the decision cadence. If a planning team reviews yesterday's output each morning, provide one defined extract at the right time in the smallest useful form, don't keep a live stream open all day because the architecture happened to make it possible. A scheduled data product gives the consumer what they need and makes the network path visible. There is also a human habit behind this. When cloud data is easy to access, people often assume more detail produces a better answer. Sometimes it does. For investigation work, raw evidence may be exactly what an engineer needs. For daily operations, excess detail can slow the decision down. Imagine a line lead responding to a machine stop. They don't need to download a large history file and inspect every signal trend before they can act. They need to know the asset, the condition, the order context, the duration, and who needs to respond. Give them that first. Make deeper evidence available when the case calls for it. This is not an argument for hiding data from people. It is an argument for serving data in forms that match the job. The operator needs a current decision. The reliability engineer may need a bounded evidence package. The central improvement team may need a govern trend set across sites. One broad export cannot meet all three needs efficiently, even if it technically contains everything. So map every return path with the same care you apply to ingestion. Who consumes the data? Where are they? How often do they read it? What level of detail do they need? Can a cache, a smaller view, or a scheduled extract meet the need without repeated full transfers? Once you start looking, cloud charges stop appearing in one need category. They hide across storage reads, network transfer, gateways, reporting services, backup tools, and application integrations. Read the invoice as a data flow map. Once charges start appearing across several services, the invoice becomes more than just a finance document. It becomes a partial map of how data actually moves through your architecture. Sure, start with the obvious labels, but don't stop there. You need to look for things like data transfer, out regional transfer, interzone traffic, natty processing, private endpoint processing, and charges tied to APIs, reporting tools, backup services, or managed connectors. The label names vary by provider and service, which is annoying but perfectly normal. And your job is to translate each billing line into a real technical route. When you see a line called regional data transfer, it should lead to a specific question, which workload moved data between regions, from where, and for what purpose. A natty processing charge needs to point to a subnet root table and set of destinations. Zone traffic should map to workloads that talk across availability zones. And if you can't connect a billing label to an architecture component, you still don't know what you're paying for. Don't accept the platform as an answer. For every material transfer charge, tag it with the same context you use to run the plant, which plant created it, which line or cell produced the data, which workload used the path, what class of data moved, machine events, images, engineering files, logs, MES facts, and who owns the cost decision. That last part changes the conversation. Here's the thing, an OT engineer may own the source signal, a platform team may own the gateway and root, and a data team may own the cloud pipeline. Finance sees one invoice, while four teams each see only their own piece. Cost attribution gives those teams a shared object to discuss instead of a vague complaint about cloud spend. Use tags where the platform supports them, but don't assume resource tags solve everything. Network charges often attach to shared infrastructure. One in Attic Gateway may carry traffic for several workloads, and one message broker may serve several plans. To split shared costs in a way people can trust, you'll need billing exports, flow data, application metrics, and architecture records altogether. That takes effort, but it's still less effort than arguing from guesses every quarter. A good review starts by linking billing account labels to actual things, not product names, but actual things, like this charge comes from the route used by LineForce edge connector, or this charge comes from a cross-region copy of defect images, or this one comes from a dashboard data set pulled by the site reporting tool, and this one belongs to a shared platform service with cost divided across the plants that use it. Once you can speak that clearly, the invoice stops being mysterious. Then compare bytes moved with bytes that served a named use case. This is where many data paths fail the test. You might find that a large volume of records supports an active maintenance process, a traceability requirement, or a cross-plant quality study. Fine, that movement has a stated purpose. Then you can decide whether the route, retention, and cost match that purpose. But you may also find traffic with no named consumer at all. Data arrives because a collector was configured years ago. A duplicate pipeline still runs after a migration or a service exports more detail than the receiving system reads. The bytes exist in the bill, but nobody can name the decision they support. That is the traffic to challenge first. I'd set up a monthly data flow review with IT, OT, finance, and security in the same room, or at least on the same call. Keep it practical. Bring the top transfer charges, the routes behind them, the data classes involved, and the owners who can explain them. OT can confirm whether a stream still supports production or maintenance. IT can explain topology and service behavior. Security can check whether an easier route creates unacceptable exposure. And finance can show the trend and make sure the charge reaches the right budget owner. Nobody needs a two-hour governance ceremony. They need a repeatable review where unexplained traffic gets an owner in the next action. That's how cost control becomes part of architecture work rather than an emergency exercise after the invoice arrives. And the first real step isn't a vendor meeting, but it's a model. It's a workload inventory. Inventory the data before you move it. Before changing a route, buying more edge hardware or negotiating with a cloud provider, build an inventory of the data you already collect. Most plants don't lack data. They lack a clear list of what exists, where it starts, and why it keeps moving. Started the sources list the PLC tags collected from each machine or cell, including the historian feeds, vibration sensors, cameras, machine logs, each application logs, and MS events. Don't stop at the systems your central ITT modes. Include data from condition monitoring vendors, quality systems, maintenance tools, and any portal that pulls data from the plant. The list will get longer than expected, and that's useful. For each source, record its rate. A tag may change once per shift, every second, or many times per second, and capture payload size as well. A simple state value and an image frame shouldn't sit in the same column with the same assumed cost. Then record burst behavior. Some sources produce a steady stream, while others stay quiet until a machine fault, network issue, recipe change, or inspection failure, causes a sudden spike. A camera system may send little during normal work, then upload a sequence of defect images after an event. A log collector may remain modest until an application starts failing, and turns into a very enthusiastic writer. Those bursts shape storage, network capacity, and cost, and they also shape recovery planning. Add the retention rule next, even when the honest answer is unknown. How long does the rule record remain at the source? How long does it stay in the historian, the local server, the cloud platform, or a vendor portal? If a stream has no clear retention period, market. That stream needs attention, because no rule usually means it will continue accumulating. Sensitivity belongs in the inventory, too. Some data exposes machine settings, recipes, product detail, customer orders, or process knowledge that shouldn't travel freely, while other data may appear harmless until you combine it with MES context and production schedules. The inventory needs to describe the data as a business asset, not just as a technical payload, and name the consumer who reads this data today, align supervisor, maintenance, quality, a central engineering group, an external equipment supplier, or a data scientist. The cloud platform isn't a consumer, and neither is analytics. Name the role, system, or process that uses the record, that one field cuts through a surprising amount of noise. Next, identify the streams that already pass through an edge gateway, industrial PC, or historian. In many plants, local processing already exists, even if nobody calls it edge architecture. The historian may collect tags, apply compression, and retain detailed records locally, while an edge gateway may translate protocols, buffer messages, or calculate a basic condition result before anything leaves the site. Don't ignore those layers just because they predate the current IoT project. They may already hold the right place to filter, shape, or retain data, or they may create an extra collector that sends the same value somewhere else. You need to see both cases before you add another component. Now look for duplication. This is where inventories get uncomfortable. One PLC tag may feed the historian, an MES connector, an IoT gateway, and a maintenance application. Each connection might have started with a valid purpose, but over time, teams often create parallel routes because it feels faster than finding and reusing the existing one. The same problem shows up outside the formal architecture. Someone exports a spreadsheet each day, and uploads it to a shared site. An engineer downloads data from a vendor portal because the central system doesn't expose it in the right form, or a supplier tool keeps its own archive, while the plant retains another copy locally. These are shadow exports. They're often invisible until a data quality issue, security review, or invoice forces someone to trace them. Don't treat the people behind those workarounds as the problem. They usually created them because the approved path didn't meet a real need. The job is to capture that need, then decide whether the workaround should become a supported data product or disappear. For every stream, document the decision it supports, and keep the wording plain. Like, detect the developing bearing fault, explain a quality reject, confirm production against a work order, review energy used by shift, or provide remote support evidence. If you can't write a sentence like that, flag the stream for review. It may still deserve to exist, but it hasn't earned automatic movement, storage, or replication. Once the inventory is real, the next question gets much easier. Where should the processing actually happen? Edge is a processing layer, not a smaller cloud. So you've got that inventory of what exists, and now you need to decide where the first useful work should actually happen. When I say edge, I mean compute and storage placed near the source of the data, usually inside the plant or at the side boundary. It might run on an industrial PC, a gateway, a local server, or an existing historian environment, and the hardware matters less than the role it plays in the data path. Its job starts where the raw signal appears, which is usually in formats that enterprise systems don't understand directly. You may have OPC UA from a newer controller, a vendor protocol from an older machine, Modbus values from utility meter, or files from an inspection station, and the edge layer handles that local mess before it becomes someone else's integration problem. That's exactly where protocol handling should live. The edge can do the work of reading local signals, normalizing timestamps, attaching an asset identity, converting units where needed, and keeping the context that tells you what a value actually means. A temperature reading, without a sensor location, unit, tag definition, and quality state is just a number, traveling through expensive infrastructure. That context is what turns a raw number into operational data you can actually use. Now, the edge also buffers data, when the outside connection drops, slows down, or becomes unavailable. The plant continues producing because machines don't pause politely when a one-rowed or cloud service has a bad afternoon, and local storage gives the system somewhere safe to hold records until the connection returns with a defined limit and a clear rule for what happens when that limit approaches. That's plant continuity, not some optional extra feature. Then the edge can apply the first processing step, removing duplicates, detecting a state change, combining related signals, creating a local event, or retaining the most detailed form where the site can actually use it. This work happens near the machine context, before a generic cloud pipeline tries to infer what a stream meant after the fact. Local state matters here too, because a machine doesn't exist as a set of disconnected values. It runs through states, transitions, recipes, changers, alarms, pauses, and recovery actions. An edge service can retain the current state of a machine or cell and interpret the next input against that state, which lets it tell the difference between a brief sensor glitch and a real operating change because it has seen the sequence locally. That's a much better starting point for real-time visibility, but let me separate two things that often get mixed together. Edge processing is not a replacement for PLC control. The PLC, safety system, and deterministic OT layer still own the machine behavior they were built to own. An edge system can observe in rich and support local applications, but it shouldn't casually insert itself into parts where predictable control behavior protects people, equipment, or product. Keep that boundary clear, it matters. At the other extreme, the edge isn't a miniature enterprise data center either. You don't need to copy every central platform service into every plant and then spend the next five years operating a distributed version of the same complexity. The edge should run only the services that need local data, local response, and local continuity. Not just because a container can run there, think of the edge as the first place where raw factory data becomes usable operational data. Before that point, you have signals, packets, files, and protocol-specific records. After that, you can have a machine state event, a time bound production fact, a condition result, or a controlled local record that other systems can understand. That conversion is the real job. The cloud still has a strong role. Use cloud scale where you need shared history across sites, broad access for enterprise teams, governed reporting, long-running analysis, or larger compute workloads that don't sit in the immediate plant path. Those workloads benefit from central services because their users and questions reach beyond one line or one factory. The edge and cloud aren't competing destinations. They perform different parts of the same system. A good design lets the edge deal with the physical world in the form it arrives, then sends well-formed operational data to shared platforms when those platforms have a defined job to do. That's how you connect the dots between IT and OT without forcing every raw signal to become an enterprise record, and filtering at the edge does more than drop rows. Filter at the edge without throwing away evidence. Filtering doesn't mean throwing data away blindly. It means deciding, while the machine context is still close, which records need to travel and which only need to remain available locally for a defined time. Start with the simplest rule. Threshold filtering, where a temperature, pressure, current, or vibration score stays within its expected band, so the edge records it locally and sends a compact health record at the agreed interval. When it crosses a limit, the edge creates an event immediately with the measured value and the context needed to understand it. That works for clear limits, but many manufacturing signals need a different rule. Change filtering sends data when the value changes by a meaningful amount. A tank level, drifting by a fraction of a percent, every few seconds may not need an upstream record each time, but a rapid change or a change beyond a defined dead band does. You keep the local history, but the shared system receives changes that might lead someone to act. State change filtering is often even more useful. A machine can sit in a running state for an hour, and sending running over and over adds little operational meaning. Instead, send the transition from running to blocked, blocked to faulted, faulted to running, and attach the time in any reason code available at that moment. The event tells you what changed, and duration comes from the next transition. This is where filtering needs some engineering judgment. A filter should remove repetition, not remove the signal that explains a problem. If a machine state changes for half a second and then returns, that may look like noise in a dashboard, but it could also be the start of a fault pattern that maintenance needs to see. So keep the local record even when you choose not to send every detail upward. Event window filtering handles this well. Instead of sending a continuous high-rate signal all day, the edge maintains a rolling raw buffer. When an anomaly, fault, quality, reject, or defined process condition occurs, it preserves a time window around that event. You might retain a period before the trigger and another period after it. The exact window depends on the process, but the principle stays the same. Capture the lead-up, the event, and the recovery, rather than only the point where a limit was crossed. A single alarm value rarely explains a failure. The useful evidence often sits just before it. Did the vibration trend rise gradually? Did motor current jump first? Did the machine change recipe? Did the sensor quality flag become uncertain before the fault? A local event window keeps that sequence available without turning every normal minute into a permanent cloud record. Stable signals can also move through rolling aggregates. The edge can calculate a minimum, maximum, average, count, duration, or rate over a defined interval, then publish that smaller record for shared reporting. But don't send an aggregate without its data quality markers. If the edge lost communication to a sensor, detected a bad timestamp saw a missing sample range or changed configuration during the interval, the aggregate needs to say so. Otherwise, a clean-looking average can quietly mix valid measurements with a broken source. Data quality is part of the record. The same applies to derived events. Every event or aggregate that leaves the site should retain its timestamp, asset ID, unit, and the configuration context that produced it. If a condition score comes from a model, include the model version. If a threshold generated the event, retain the rule version or configuration reference. Six months later, someone will ask whether the event means the same thing it meant when it was created. Without context, you can't answer that question reliably. Time also needs care. Keep the event time from the source where possible, distinguish it from processing time and upload time, and make sure the site clock stays under control. A record arriving late because the one link failed is not the same as a machine event that happened late. Those distinctions matter during root cause work. Local raw buffers need a defined retention period. Long enough for the team to investigate normal issues and long enough to upload approved evidence when a case needs wider review. The buffer cannot grow forever, and it cannot disappear before anyone has a realistic chance to inspect it. Set the duration based on how the plant actually works. If fault reviews happen each shift a short buffer may work, but if quality investigations often begin days later, the local window needs to support that cadence. Write down the rule, monitor available disk, and alert before the buffer starts overwriting data you intended to keep. That gives you a better pattern, retain detailed local evidence, trigger bounded captures when something changes, and send records that carry enough meaning for shared systems to use. The next step turns those filtered streams into operational facts through aggregation. Aggregate for the decision, not for the database. Once the edge decides something matters, aggregation turns those raw tags into facts people can actually use. We're converting machine signals into records like machine state by minute, completed cycle count, stop duration, stop reason, and energy used over a defined period. You're not trying to build the smallest possible database. You're creating a record that supports a real decision. Think about a line supervisor checking the last hour. They don't need a long list of every PLC value sample during that hour. They need to see that station 12 ran for 43 minutes, waited on material for 9, stopped for a fault for 8 and produced 186 good parts with 2 rejects. That's operational information. The aggregation window should match the cadence of the decision. If someone manages a line, minute by minute, a per shift total shows up too late. If a central operations team reviews performance each morning, second by second records just add noise without improving the conversation, so choose the time window from the job backward. For a live production view, you might need current state plus a short rolling period. For OEE review, a minute-level event record often works well because it preserves run time, stop time, and reason codes without transferring a dense stream of raw values. For energy reporting, a 15 minute or hourly total may suit the meter and the decision much better. There's no universal interval. Here's a packaging line example. The PLC publishes machine status, speed, cycle pulses, alarms, and energy readings at a fast cadence. The edge layer interprets those inputs against the local machine state and produces a minute record. Running time, plan, stop time, unplanned stop time, count produced, reject count, energy used, and the dominant stop reason where one applies. That minute record feeds an OEE event model. OEE needs availability, performance, and quality context. It does not need a million copies of a running bit. When the machine changes from running to blocked, the edge records the transition. When it resumes, the duration becomes clear. When a reject counter changes, the system links that outcome to the active order and machine state. The cloud receives a production fact with context, not a raw signal dump, but aggregation has a failure mode. People average away the very thing they later need to explain. A short voltage dip, a brief motion fault, or a half second mismatch between two sensors can disappear inside a one-minute average. The average looks normal, but the machine didn't behave normally. For maintenance or quality work, that difference matters. So use more than one aggregation method when the process calls for it. A temperature signal may need minimum, maximum, an average rather than average alone. A machine state needs duration by state, not a numeric average of codes that mean nothing once blended. A vibration score might need peak count, threshold crossings, and event duration. The record should preserve the characteristics that indicate instability, not just describe a calm-looking midpoint. This is where domain knowledge enters the model. Ask the process engineer which short events affect product quality. Ask maintenance which signatures appear before a failure. Ask the line team, which stops, count against plant production, and which do not. The aggregation logic should encode those answers in a visible version rule rather than bury them inside a no-pake dashboard calculation. The record also needs its quality status. If a minute included missing samples, a lost device connection, a clock issue, or an invalid source value, keep that status beside the aggregate. Don't let a partial count look like a complete count. Don't let a zero-energy reading look like efficient production when the meter simply stopped reporting. A number without its data condition invites the wrong decision. For each aggregate, retain enough information to answer simple questions later. Which asset produced it? Which time window does it cover? Which source values contributed? Did the system see a complete interval? Which rule set converted the raw inputs into this operational fact? Those fields matter when two teams compare results and discover their totals disagree. Aggregation should reduce volume and improve meaning at the same time. If it only reduces volume, you may have created a smaller data set that nobody can trust. If it only adds meaning, but sends every raw point as well, you haven't changed the cost or the architecture. The aim is a deliberate data product for a clear decision. Compression can reduce the size of whatever you decide to transfer. It can't fix a bad decision about what should travel in the first place. Compression, batching, and store and forward. Compression comes after placement, not before it. If a data stream has no reason to leave the plant, compressing it only creates a smaller unnecessary transfer. But once you've decided the cloud needs a record, compression can reduce the bytes on the root without changing the meaning of that record. Text-heavy payloads usually respond well. JSON event records, CSV extracts, structured logs, and repeated tag names often contain a lot of redundant text. A suitable compression method can reduce that overhead before the edge connector sends the batch upstream. Binary data needs a different expectation. A JPEG image, video stream, compressed archive, or encoded waveform file may already sit close to its practical size. Trying to compress it again can consume CPU and add delay without reducing the transfer enough to justify the work. The edge should know the payload type before it applies a generic, compress everything policy. That sounds obvious, but it often isn't. I've seen systems wrap a compressed file inside a text envelope at base64 encoding, then compress the whole thing and wonder why the network build didn't improve. The data path became more complicated while the useful payload barely changed. Keep binary data binary where you can and measure the actual result. Batching also helps when the data doesn't need an immediate response. A stream of low priority operational records can collect locally for a short controlled interval, then move as a batch rather than as thousands of tiny requests. That reduces connection setup, protocol headers, acknowledgements, and repeated encryption overhead. It also gives you a smoother use of the site connection. The batch window must fit the use case. If a record supports a shift report sending it every few minutes or at a scheduled time, it may work well. If it supports a local intervention that needs central escalation quickly, waiting too long defeats the purpose. Batching is not a blanket setting, it's a delivery cadence tied to the consumer's decision window. A plant network also benefits when transfers avoid unnecessary peaks. Picture several edge systems, all finishing a local task at the same time, each opening a connection and pushing its backlog across the one. The data volume may be acceptable across a full day, but the burst can compete with other site traffic and make troubleshooting harder. Control-batch scheduling gives the network some breathing room. Now consider what happens when the connection fails. A factory cannot assume that every cloud route stays available. One links fail, certificates expire, DNS does odd things, and sometimes the remote service simply refuses to cooperate. The edge needs store and forward behavior. It writes approved outbound records to local storage, then sends them when the route returns. That local store needs limits. Always define how much disk space the queue can use, how long records can remain there, which records take priority, and what the system does as capacity approaches its limit. Without those rules, store and forward becomes store forever until the disk fills, which is not a recovery strategy. The edge should expose its backlog as an operating signal. How many records wait? How old is the oldest record? Is the queue growing or clearing? Has the system dropped anything because a defined retention limit expired? If you're monitoring, cannot answer those questions. The buffer is invisible until it becomes an incident. Reliable delivery creates another issue, retries. When a connection drops after the edge sends a message, but before it receives confirmation, the edge cannot always know whether the cloud stored that message. Retrying is the correct choice. Yet the receiving system must handle the retry without creating a second production event, another alarm, or a duplicate energy total. That's where idempotent delivery matters, give each event a batch a stable identity. The cloud consumer records that identity and treats a repeated message as the same business record, not as new data. You can use sequence numbers, event IDs, source timestamps combined with asset context, or another stable identifier that fits your design. The point is that delivery attempts and business events are not the same thing. De-duplication needs the same discipline. Don't did duplicate only after data reaches a dashboard or a lake house. Detect duplicate messages as close as practical to the ingestion point, retain enough delivery history to identify repeats and make sure the rules survive the connector restart or a local queue replay. Otherwise, a short outage can turn into a quiet data quality problem that lives for years, compression, batching, and store and forward reduced transfer waste. They don't decide whether the data deserves transfer in the first place. You still need a named consumer, a clear purpose, and a record form that supports the decision. For some workloads though, the strongest filter does not come from a rule or a batch. It comes from running the first inference close to the machine. Put real-time inference near the machine. Here's the thing about high-rate data like vibrational vision. A rule engine can handle some filtering, but the real value is putting a model right at the edge, scoring the input before it ever leaves the machine. Otherwise, you're shipping noise across the network. Take vibration monitoring. The edge system reads the signal, preps the sample the way the model expects, and calculates a condition score right there. A healthy pattern gets a normal score, but once the pattern starts drifting, that triggers an event, and the raw waveform stays local unless someone specifically asks for it. Vision works the same way, even though the payload is different. A camera might inspect every part, but the cloud doesn't need every frame from every good product. The local system classifies the result, records the defect type or confidence score, and keeps a limited set of images when it finds something that needs a closer look. That's not AI magic. It's a specific model applied to a specific stream, right where the data is generated. The record you send upstream needs enough context for someone else to trust it. That means the score, the event time, the asset or inspection station, the model version, and the outcome. And when that result triggers an exception, send along a limited evidence package, the relevant waveform window, selected images, or derive features that explain the classification. Now, that limited part is important. If every score automatically drags a big raw payload into cloud storage, you've only moved the filter a few inches downstream. You need a rule that defines what evidence travels with each event, how much and how long the full local record stays available in case an engineer needs to dig deeper. Model version needs to be in every result, because a score from one model isn't automatically comparable with a score from another, even if they are looking at the same asset and same input. If you change pre-processing a threshold, a camera setting, or the model itself, you need to know which logic produced that outcome. Otherwise, your trend chart can look perfectly stable while the meaning of every number changed underneath it. Now, the cloud still has its place here. It just doesn't do the work that has to happen before the machine context disappears. Use central compute to train models on approved data sets, test them against known cases, control which version gets approved for production, push that version to the right sides, and compare results across lines or plans. That separation makes the model life cycle transparent. A central team can test a new model before it ever hits production. They can track which sides run which version and compare event patterns without needing every side to constantly upload all raw sensor data. And when a model needs new training data, you request a controlled set of labeled cases instead of treating every normal production cycle as training material. That gives you a feedback loop without turning the factory into a permanent data upload service. But here's a boundary that has to stay firm. Local inference can support condition monitoring, inspection and operational guidance, but safety functions and deterministic machine control should never depend on a remote cloud response. A one connection is not a safety-rated control path and no model score changes that. The PLC safety controller and established OT safeguards keep authority over anything that protects people, equipment and product. An edge model can raise an alert, block a suspect item through an approved local workflow or ask for a human review of that workflow exists. It should never wait for a cloud service to decide a critical machine action. The same rule applies when the one link fails. Your edge system needs a clear fallback mode. If the cloud gets slow, goes down or becomes unreachable, the local model keeps running with the last approved version, records results locally, and queues only the records that are approved for later upload. If local capacity or model health drops below a threshold, you've defined the system should signal that clearly and follow the site's operating procedure. Silence is not a fallback mode. You also need to decide what happens when the edge model itself can't run. The local hardware fails, an input source drops out, or the model package can't load after an update. The answer might be a simpler local rule, a manual inspection step, or a controlled stop. Depends on the process. What it can't be is an undocumented assumption that the cloud will save the day. The three-layer factory data pattern, let's zoom out for a second. A hybrid design only works when each layer has a clear job. The simplest way to make that job clear is to break it into three layers. The edge, the site, and the cloud. The edge layer sits right next to the physical process. It captures data from controllers, sensors, cameras, and local applications, and turns those inputs into something the rest of the system can use. This layer normalizes timestamps and asset IDs, buffers records when the connection drops, filters out repetitive signals, and runs local inference where it's needed. Its focus is immediate operational context. It knows which machine produced the signal, what it was doing at the time, and whether a local system needs to react before any external service has time to respond. Above that, you've got the site layer. This is the layer that most IoT diagrams skip because drawing a line from gateway straight to cloud looks so clean, but it rarely matches how a plant actually works. Most factories already have shared systems at the site level. A historian, MES, local reporting tools, engineering workstations, quality systems, and applications that connect production records to order context. The site layer gives data a shared factory context before it ever becomes enterprise data. A historian holds site-wide process history. MES provides the order, operation, material, and status that turn a machine event into something meaningful. A local application can combine a quality result with a specific batch and machine state then expose that result to teams inside the plant without needing a round trip to a remote platform. That middle layer also helps when multiple production cells need the same data. Instead of every edge device leaving its own direct path to the cloud and every local consumer pulling records back down, the site layer provides a controlled shared service close to the people and equipment that actually use it. This cuts down duplicate integration work, and more importantly, it lets the plant stay coherent when that external connection gets spotty. Then you have the cloud layer. The cloud is the right place for work that reaches across sites or needs long term, governed access. That means fleet analysis across many factories, enterprise reporting, model training, when it needs big data sets in central compute and retained business records that need controlled access across teams or regions. Think about it this way. A maintenance engineer investigating one machine needs immediate site context and detailed evidence. A central reliability team looking for failure patterns across a fleet needs comparable records from many assets over time. Those are different questions and they deserve different layers. The cloud should receive data shaped for that shared purpose. It can also hold governed data products that enterprise teams trust, cross-plant OEE review, quality trends, energy comparison, planning analysis, and approved model training sets. But it shouldn't have to decode every protocol detail or reconstruct every local machine state from raw messages that showed up without any context. That is expensive detective work and it usually produces arguments. The architecture gets a lot easier to run when each handoff between layers has a real contract. Not a vague promise that data will show up somehow. A real contract. The contract defines the schema. What fields arrive, what each one means, what units apply, how timestamps work, and how the record identifies the asset and process context. It also defines the cadence. Whether the edge sends an event as it happens, a minute record, a shift record, or a scheduled batch. The receiving layer needs to know what the layer to expect and what counts as late or missing. Retention goes in the contract too. The edge holds detailed evidence for a defined local window. The site layer keeps operational history for a different period. The cloud holds approved aggregates and business records for much longer. If each layer silently keeps everything forever, that's not a retention design. It's just a storage habit. And every contract meets an owner. Someone owns the source meaning, someone owns the site service, someone owns the cloud data product. Without named ownership, schema changes drift through the pipeline, local teams lose trust in reports, and the cloud becomes a big pile of records that nobody feels responsible for explaining. This is why edge-to-cloud is often too simple for a real factory. It skips the layer where raw equipment data meets the shared operational context of the plant. That middle layer contains the historian, the MES relationship, and the local services that tell you whether an event relates to an active order, a plan stop, a quality hold, or a machine fault. Skipping it doesn't remove complexity. It just moves the complexity into cloud pipelines where it costs more and arrives later. Once you see these three layers clearly, placing common data types becomes a lot less ideological. You stop asking whether everything belongs at the edge or in the cloud, and you start asking which layer can turn that data into the right record for the next user. Keep these data types at the edge by default. Some factory data should never leave the edge, unless someone makes a specific case for moving it. But I'm not saying cloud services are bad. It's that the original form of that data either has a short local use, a large volume or both, usually both. Start with high frequency waveforms, vibration captures, acoustic signals, high speed current traces, that kind of detail pours out quickly. A reliability engineer needs it when investigating an unusual condition, but during normal operation, shipping every healthy waveform to a remote platform creates a massive transfer and retention burden with almost no daily decision behind it. Images and video fall into the same category. A vision station might inspect every part, a camera might record a process continuously. Those raw files can help explain a defect, train an inspection model or support and audit, but they don't automatically need a permanent cloud route just because the camera keeps producing them. Here's what I recommend. Keep the raw material near the process with a defined local retention window. Move selected evidence only when a reject, anomaly or approved engineering request gives it a purpose. That's it, debug logs and packet captures deserve the same treatment. They become useful almost exclusively after something breaks, and they can get huge when a system is already under stress. Sending every detailed log or network capture offsite by default means you pay to store a lot of normal behavior, then still have to dig through the noise to find the few minutes that mattered. A controlled local buffer works much better. Control-related data also belongs close to the machine. I'm talking about tags that describe immediate machine state, interlock context, local alarm behavior, and the signals local applications need to understand what the equipment is doing right now. That doesn't mean you hide operational state from enterprise systems. It means the detailed, low latency view stays where the equipment and people needed first. The enterprise receives an approved event or state record, while the edge keeps the signal sequence that explains how that state developed. The difference matters during an incident. A cloud dashboard can tell you that a cell entered a faulted state at a given time. The local system shows the interlock sequence, sensor quality, command state, and related inputs around that moment. One supports fleet visibility, the other supports diagnosis. Short-lived local buffers give you that diagnostic depth without turning every fault investigation into a data retrieval project. Keep the buffer long enough for how your plant actually works, whether reviews happen during the shift at the next morning meeting or after quality links several events together. Then let the buffer expire by rule. There's one more category where local retention should be the default. Sensitive raw production evidence with unresolved data residency or access rules that may include process images, recipe-related signals, detailed machine settings, customer-specific product evidence or records that become sensitive when joined with order context. If the legal location access model supply access or customer terms aren't clear, don't treat cloud storage as a temporary answer. Temporary cloud storage has a habit of becoming permanent. Keep the raw evidence under site control until the ownership and policy questions have actual answers. None of this means never send raw data to the cloud. There are valid exceptions. A central engineering team may need a bounded set of fault records, a model training effort may need selected labeled samples. A quality investigation may require evidence from several sites. Those are real cloud use cases when the request names the consumer defines the data set and explains what decision or work it supports. But the transfer needs a plan. Define the exact data range, not just all history. Set a cost owner who accepts the full route including copies and later retrieval. Set a retention period, access rules, and a deletion action before the upload begins. If the request can't meet those conditions, the data hasn't earned the trip. So here's the practical default. Keep detailed, fast, local and sensitive factory data close to where it starts. Send it out with only when a bounded purpose requires it. Other data earns a cloud destination much more easily. Send these data types to the cloud by default. Some factory data gains more meaning when it leaves the site because its consumer sits beyond one line or one plant. The cloud earns its place when it holds shared facts that people need to compare, govern, retain or use across a wider operation. Start with shift and order facts from MES. A completed operation, a produced quantity, a reject count, material consumption, a work order status, a traceable lot relationship, all of that carries business context. It tells a story that reaches past the machine that produced it. Planning, quality, finance, supply chain, and central operations may all need the same record,