Backend & Connected Devices
AWS Connected-Device Backend & Telemetry
Backend and telemetry engineering within an existing connected-device product: APIs, aggregation, recovery, and cloud performance work.
Connected-device product (anonymized) · Product team · Ongoing product work
My role & contribution
Substantial backend/cloud engineering within an existing product team. I did not build the entire IoT platform alone.
Backend, telemetry, and authenticated AI access
The Claude/MCP integration exposes scoped read tools over existing application and telemetry data, using the product's account and access model.
The problem
A connected-device product needed application/backend workflows and useful history on top of incoming device telemetry. I contributed backend/cloud engineering across device and property APIs, time-series aggregation, alerts, historical recovery, and performance/cost optimization. This was work within an existing product and engineering team.
The existing workflow
Raw device updates needed to serve both immediate application behavior and historical questions. APIs, aggregation jobs, and recovery paths had to fit the platform's existing identity and infrastructure.
System flow
01
Device telemetry
MQTT/device updates enter the existing AWS IoT/backend environment.
02
Processing
Lambda and backend workflows validate and process account/device context.
03
Historical layers
Telemetry is aggregated into reporting intervals and exposed through existing APIs.
04
Interfaces
Application APIs and authenticated Claude access through MCP read tools.
Key engineering decisions
Aggregate for the questions being asked
Raw updates and reporting buckets serve different purposes. Layered aggregation exposes useful history without requiring every interface to process the raw stream.
Work within existing ownership boundaries
Backend changes used the platform's account/property/device model and established cloud services rather than replacing the whole product.
Expose a bounded interface
The MCP integration uses authenticated, scoped read access to account, property, device, and telemetry data through the existing backend.
Authenticated Claude access to application data
I implemented a Claude/MCP connection over existing application and telemetry APIs. It uses the product’s account and access model to expose selected read operations. This was an additional interface within the existing product, alongside my wider backend engineering work.
- Implemented an OAuth-based connection using the existing backend identity and permission model.
- Exposed scoped read tools for account, property, device, and telemetry questions.
- Verified an end-to-end Claude connection and multiple read-tool calls over the existing API paths.
Difficult problems
- Turning frequent device updates into useful historical reporting at multiple aggregation levels.
- Maintaining account/property/device boundaries across backend APIs.
- Balancing write volume and handler execution with telemetry usefulness.
- Recovering historical data and exposing bounded read access through a new interface.
Work contributed
- Built and maintained application, property, device, and integration workflows.
- Worked on telemetry aggregation across minute, 15-minute, hourly, and daily reporting paths.
- Contributed batching, write-volume reduction, handler refactoring, and runtime/memory tuning.
- Worked with account authentication, operational monitoring, and historical backfills.
- Implemented authenticated Claude/MCP access to existing application and telemetry APIs.
Validation
- Telemetry handlers define interval-specific aggregation rules and historical reporting paths.
- Account/property/device identity and aggregation are explicit parts of the backend implementation.
- Verified an end-to-end OAuth connection and multiple read-tool calls through Claude.
- MCP read tools use the existing backend identity and access model.
Supported outcome
- Supported backend and application workflows on the existing connected-device platform.
- Built and maintained aggregation and historical reporting paths.
- Worked on batching, handler/runtime tuning, and DynamoDB access patterns.
- Connected Claude to existing application and telemetry data through authenticated MCP read tools.
Technologies in context
AWS IoT Core · MQTT · Lambda · DynamoDB · SQS · Cognito · TypeScript / Node.js · CloudWatch
Related services & work
Working through a similar problem?
Share the workflow and the output your team needs. We can identify a focused starting point.
Discuss your workflow