IoT hydrant sensors can preprocess readings at the edge or ship raw streams centrally. When is edge processing the cost-sensible architecture choice?
Select an answer to reveal the explanation.
Short Explanation
Edge processing isn't a trophy—it's a savings play when it chops expensive central data hauling or latency. If it doesn't buy you that, keep the brains in the Region and skip the cargo cult.
Full Explanation
Edge filtering is the cost-sensible architecture choice when it meaningfully cuts costly central egress, storage, or latency for IoT hydrant sensors—not as a cargo-cult default—because edge preprocessing only pays off when it reduces expensive central ingest or enables local decisions that matter. Municipal IoT should follow measured trade-offs between device complexity and cloud data costs. Always processing at the edge even when it increases device cost without reducing egress or latency pain fails because edge compute then adds CapEx/OpEx without benefit. Never using edge processing because Regions cannot receive filtered data fails factually: Regions routinely receive filtered or aggregated telemetry; the claim invents a false limitation. Using edge only when AWS Outposts is unavailable in every firehouse fails conceptually: Outposts availability is unrelated to the general edge-versus-central cost trade-off for sensor filtering. Exam caveat: choose edge when it reduces egress/storage/latency cost; reject always/never dogma and Outposts-as-proxy logic. Operational check: measure raw versus filtered data volumes and egress cost for hydrant telemetry; pilot edge filtering on a subset; compare device ops cost versus cloud savings; and keep Regional analytics for aggregates the city still needs centrally.