Cloud IoT Platforms — AWS IoT Core, Azure IoT Hub & Google Cloud IoT
End-to-end IoT cloud architecture connecting embedded hardware to managed cloud services — device provisioning, MQTT ingestion, digital twin, rules engines, and time-series analytics at production scale.
What We Build on This Platform
AWS IoT Core Architecture
Device registry, MQTT broker configuration, topic policy design, and rules engine routing to Lambda, DynamoDB, S3, and Kinesis. AWS IoT Core pricing optimization for large fleets through message batching and topic consolidation strategies.
Azure IoT Hub & Digital Twins
IoT Hub device registration, D2C and C2D message routing, Azure IoT Edge module deployment, and Azure Digital Twins DTDL model design for manufacturing and building automation use cases.
Device Provisioning & Fleet Registration
AWS IoT Fleet Provisioning with JITP (Just-in-Time Provisioning), pre-provisioned certificates, claim certificates, and provisioning template design for factory programming workflows at scale.
IoT Shadow / Device Twin
Device shadow (desired/reported/delta) architecture for offline device state synchronization, shadow conflict resolution, and shadow versioning for multi-client concurrent updates across web, mobile, and automation consumers.
OTA via IoT Jobs
AWS IoT Jobs and Azure Device Update for managed OTA firmware delivery with rollout percentage control, pre-signed S3 URLs, and per-device job status tracking across heterogeneous firmware versions in a fleet.
Device Security & Defender
AWS IoT Device Defender audit checks, behavioral metrics for anomaly detection, X.509 certificate rotation automation, and device certificate revocation via CRL or OCSP for compromised device response.
Edge Computing with Greengrass
AWS IoT Greengrass v2 component deployment for local inference, edge data processing, stream manager for intermittent connectivity, and secure tunnel for remote device access without inbound firewall rules.
IoT Analytics & SiteWise
AWS IoT SiteWise asset model design for industrial telemetry, IoT Analytics pipeline for time-series aggregation, and Grafana dashboard integration for operations and maintenance teams.
How Ankh Uses This Platform
Cloud Platform Selection
AWS IoT Core is evaluated for organizations already running on AWS who need tight Lambda and DynamoDB integration; Azure IoT Hub for Microsoft-heavy enterprise environments requiring Active Directory device identity and Azure AD B2B federation; GCP IoT for teams with existing TensorFlow or Vertex AI ML pipeline investment. Multi-cloud hybrid architectures are evaluated against the operational complexity cost before committing to a primary vendor. The selection process includes a cost model at the target device count and message rate, since per-message pricing differences compound significantly at fleet scale.
Device Identity & Provisioning Architecture
X.509 certificate authority structure is designed for fleet scale, including root CA, intermediate CA, and device certificate chain depth. JITP, pre-provisioned certificates, and Fleet Provisioning claim certificates are evaluated against factory programming capability — specifically whether the contract manufacturer can program certificates into the device at the time of production testing. Device certificate lifecycle management is designed from day one: rotation frequency, revocation mechanism, certificate expiry monitoring, and the fleet-wide expiry risk when a large batch was provisioned on the same day.
Topic Architecture & Message Routing
MQTT topic namespace is designed for the device fleet with telemetry, command, status, OTA, and lifecycle topics carrying device identity in the topic path. IoT Core Rules Engine routing rules are written for each topic pattern with SQL filter expressions. Lambda function architecture handles real-time event processing. Routing targets — S3 for raw archive, DynamoDB for device state, TimescaleDB or InfluxDB for time-series, Kinesis for streaming analytics — are selected based on query patterns and retention requirements.
Shadow/Twin State Model
Device shadow schema is designed for the product's desired/reported state model, with careful attention to which properties belong in shadow versus in time-series telemetry. Shadow delta handler is implemented in both firmware and the cloud Lambda, with version checks to prevent stale delta application. Shadow versioning handles concurrent update scenarios from multiple web or mobile clients. Bulk shadow operations are implemented for fleet-wide configuration pushes that need to reach thousands of devices without one update per device API call.
Security Hardening & Monitoring
Device Defender audit policy is configured for the fleet with checks covering certificate validity, overly permissive MQTT policies, and logging configuration. Behavioral metrics baselines are established from normal device operation before anomaly detection thresholds are set. MQTT policy least-privilege review ensures no device policy permits subscribing to another device's telemetry topic. Certificate rotation automation is implemented before the first certificate expiry deadline. CloudWatch and Azure Monitor dashboards surface fleet health — message rate, connection counts, JITP failures, and rules engine error metrics.
Deep Technical Capability
MQTT Topic Policy Design for Large IoT Fleets
AWS IoT Core enforces MQTT access control through IoT policies attached to device certificates or thing groups. The critical design decision is whether to use per-device policies with hardcoded topic ARNs or policy variables — specifically the ${iot:Connection.Thing.ThingName} substitution — to parameterize a single policy template across the entire fleet. Policy variables are essential at scale: managing 50,000 individual IAM-style policies is operationally untenable. However, policy variable policies introduce a subtle security dependency: the MQTT client ID must exactly match the Thing Name, or the policy variable resolves incorrectly and grants overly broad access. Wildcard topic subscriptions — a pattern that works harmlessly in a 100-device pilot — become a data isolation liability at 10,000 devices where one compromised device certificate could subscribe to every other device's telemetry stream if the topic policy uses a trailing wildcard without a device-scoped prefix. Multi-tenant architectures require a second layer of topic namespace isolation: tenant prefix in the topic path, enforced by a condition block in the policy, so a compromised device in tenant A cannot access tenant B's topics even with a valid certificate. Ankh designs topic policies that enforce per-device and per-tenant isolation from the initial architecture, not as a retrofit after a security audit.
X.509 Certificate Lifecycle Management at Fleet Scale
AWS IoT certificate registration begins with registering a CA certificate in the IoT Core certificate store, which enables JITP: when a device presents a certificate signed by the registered CA for the first time, IoT Core triggers a JITP Lambda that creates the Thing, attaches the policy, and activates the certificate in a single connection attempt. The operational risk in JITP provisioning is the batch expiry problem: if 50,000 devices are manufactured in a two-week factory run and all receive certificates with a 2-year validity period, the entire fleet faces simultaneous certificate expiry 730 days later. A cert rotation campaign that needs to touch 50,000 devices before a hard deadline — with no inbound connectivity, behind NAT, dependent on devices phoning home — is a fleet-wide outage risk if the rotation isn't designed years in advance. CRL-based revocation for IoT fleets is impractical because devices would need to download and parse a CRL that may grow to megabytes as revocations accumulate. OCSP is operationally feasible but adds a network round-trip to every TLS handshake. Ankh designs certificate validity periods with staggered expiry dates, implements proactive rotation triggered by remaining validity time rather than hard expiry, and tests the rotation flow on a canary group before fleet-wide rollout.
AWS IoT Greengrass Edge Computing for Intermittent Connectivity
Greengrass v2 decomposes edge software into components with independent lifecycle management — install, run, startup, shutdown, and recover scripts — which enables rolling component updates across a fleet without full application restarts. The stream manager component solves the intermittent connectivity problem: sensor data is written to a local stream with configurable retention size and time, and stream manager forwards to Kinesis Data Streams, IoT Analytics, or S3 when cloud connectivity is available. When connectivity drops, stream manager continues accepting local writes up to the configured max size, then applies the configured export strategy — oldest-first discard or newest-first overwrite — depending on whether historical completeness or recency matters more for the application. The local MQTT broker allows device-to-edge communication at sub-millisecond latency without a cloud round-trip, which is critical for industrial control applications where cloud connectivity latency is unacceptable for real-time decisions. The operational challenge at scale is component version management: a fleet of 500 industrial edge nodes running different Greengrass nucleus versions and different component versions requires a deployment targeting strategy, canary groups, and automatic rollback on failed health checks — tooling that Ankh builds as part of the initial Greengrass deployment, not after a failed component update corrupts production edge nodes.
Products Built on This Platform
IoT Devices
AWS IoT Core device registry and MQTT ingestion backbone for custom IoT hardware.
View ProductFleet Telematics
IoT Shadow and IoT Jobs for real-time vehicle state and OTA firmware delivery.
View ProductIndustrial Equipment Monitoring
IoT SiteWise asset models and Greengrass edge processing for factory floor telemetry.
View ProductCold Chain Monitoring
Rules engine alerting and TimescaleDB time-series storage for temperature excursion events.
View ProductSmart Agriculture
Greengrass edge inference for field sensors with intermittent LTE connectivity.
View ProductStructural Monitoring
IoT Analytics pipeline for long-term structural vibration and strain time-series archival.
View ProductIoT cloud architectures designed from the device firmware up, not from the dashboard down
Most IoT cloud integrations are designed by backend engineers who treat the device as an abstraction. Ankh designs the MQTT topic schema, shadow model, and rules engine routing simultaneously with the firmware that produces the data, which means the cloud architecture reflects the actual device state machine and failure modes rather than an idealized message model that breaks when a device loses connectivity mid-message. The result is a cloud architecture that handles partial messages, reconnection floods, and shadow conflicts correctly from the first production deployment — not after the first fleet-scale incident.
Certificate lifecycle management that doesn't create a fleet-wide outage on expiry day
Certificate expiry is a known failure mode that is routinely under-engineered because it is invisible until it isn't. Ankh designs certificate validity periods with explicit staggered expiry, implements proactive rotation triggered by remaining validity time, and tests the rotation flow end-to-end on a canary device cohort before the rotation window opens. JITP provisioning templates are designed to support certificate rotation without physical device access. The goal is a fleet where certificate rotation is a routine background operation, not a race against a hard deadline affecting 50,000 devices simultaneously.
Edge computing architectures that function without cloud connectivity
Greengrass deployments designed purely for the connected case fail the first time a site loses internet for two hours. Ankh designs Greengrass stream manager retention policies, local MQTT routing, and edge Lambda logic to handle connectivity gaps gracefully: data is buffered locally with deterministic discard policy, local control decisions are made without cloud round-trip, and cloud sync catches up when connectivity restores without producing a message storm that overwhelms the IoT Core ingest rate. The edge architecture is validated under simulated network partition before production deployment.