Moving Industrial Telemetry Processing to an AWS Event Path

An anonymous industrial IoT engagement combining gateway filtering, Kinesis ingestion, Lambda processing and separate operational and historical data responsibilities.

Move the telemetry responsibilities that a facility needs

An industrial IoT company used a Kafka and Spark pipeline to process sensor observations from manufacturing facilities. Workload variation and infrastructure operation shaped the redesign. The project also had to retain historical analysis and existing dashboard integrations while facilities moved incrementally.

Ampity designed an AWS processing path using Kinesis for ingestion, Lambda for processing, DynamoDB for hot data, S3 for historical storage and Athena for queries. Gateways filtered and aggregated observations before cloud ingestion. The customer remains anonymous. The case covers those recorded responsibilities and the migration approach, without publishing event scale, anomaly-detection performance or a savings result.

Keep the observation's meaning across the edge boundary

Gateway filtering was part of the design alongside cloud processing. That division affects which observations remain available for later inspection. An aggregate can be useful for a dashboard while leaving a different question unanswered, such as whether an individual sensor reading was missing or excluded.

For a comparable facility, define the sensor identity, unit, event time and filtering revision before comparing gateway output with a cloud result. Distinguish a raw observation, an aggregate and an anomaly output. A repeated aggregate should not be interpreted as a new physical observation merely because another processor received it.

Existing device protocols and customer freshness requirements constrained the transition. They did not authorize changing manufacturing controls or treating a predicted anomaly as an instruction to operate equipment. The responsible facility owner must define the permitted use of an output separately from the data-processing path.

Choose the processing model without assuming its economics

The alternatives were to retain and adjust Kafka/Spark, move those responsibilities to managed services, or adopt the selected Kinesis/Lambda path. Familiar tools and available operating skills mattered as well as the work caused by changing the model. The new approach still needed ownership of ingestion, transformation, stored results and consumer behavior.

Kinesis has a separately declared capacity mode. Its StreamModeDetails API reference distinguishes provisioned and on-demand modes. A service name in an architecture cannot identify the mode or effective capacity settings of a particular stream. Inspect those settings before estimating a new workload or planning its recovery.

A current comparison should include the selected services, retained data, reads, repeated processing and operating work within the same declared boundary. Measure a representative quiet period, busy period and recovery workload before claiming a cost relationship. This case provides no price inputs, comparison denominator or assumption that an idle processing path has no cost.

Separate successful processing from a usable output

The design used DynamoDB for hot data and S3 with Athena for historical analysis. Anomaly processing formed part of the Lambda work. Those roles describe the system's scope without specifying a table key, connector, retention policy or downstream action mechanism.

AWS's Lambda and Kinesis documentation states that event source mappings can process records more than once. For a comparable path, define what a repeat means at each destination before using a successful invocation as evidence that the output is correct. The reference does not establish that this engagement implemented a particular duplicate-handling protocol.

The operational view and historical view may serve different decisions. Record the permitted age and correction behavior for each consumer. A delayed observation could revise a historical result without being appropriate for a current operational display. The processor's completion status cannot decide that policy on the consumer's behalf.

Move facilities against an explicit comparison boundary

The recorded approach introduced the new processing infrastructure alongside the existing path, compared outputs and moved facilities in stages. Historical access and dashboard integration remained part of the migration scope. No rollout duration, complete facility inventory or decommissioning result is published here.

For another migration, compare the same accepted input scope and transformation meaning. A gateway summary and a raw-event calculation can differ legitimately because they represent different information. Agree the expected relationship first, including excluded observations, late arrivals and the consumer's view of a partial result.

Returning a dashboard to an earlier path changes what it reads next. It cannot retract an alert already delivered or reverse an operational decision already taken. The recovery owner needs to identify those effects and the data that would be missing from either view. Do not retire the earlier path solely because an ordinary processing run completes.

Review a facility observation without replaying production

Start with authorized read-only definitions, permitted observation samples and existing processing records. The worksheet is a proposed review aid, not an executed engagement test or permission to export production telemetry.

A later rehearsal needs separate authorization for an isolated target, synthetic or approved sanitized telemetry and scoped test identities. Make alerting, notifications, work orders and equipment-control receivers inert or disconnected. Bound input volume, storage, runtime and spend. Stop on unexplained differences, out-of-scope disclosure or any route capable of live effects. Source export and production changes require their own approval.

Next action: define the facility's first accepted output

The approach is useful to consider when a facility's observation, processing and consumer responsibilities can be stated independently and the team can operate the selected services. A workload with complex state, a constrained downstream destination or different recovery needs may call for another division of work. The historical service combination is not a default architecture.

Choose a permitted facility observation and identify its gateway representation, cloud output and intended consumer. Ask the responsible owners to explain a missing or repeated observation before expanding a rollout. Keep an unresolved rule assigned to an owner rather than hiding it behind a service-level processing status.

Use the batch-versus-stream processing playbook for the broader mode-selection and recovery task. This industrial case concerns its recorded edge and AWS responsibilities; it supplies neither a general stream-processing runbook nor evidence of a completed manufacturing action.

Technical reference

AWS's StreamModeDetails and Lambda/Kinesis documentation were checked on 18 October 2026 for the bounded capacity-mode and repeated-processing statements linked above. The references do not identify this engagement's settings, accepted outputs, operating scale, cost or model effectiveness.