CDN and Edge Computing Architecture

The Problem This Blueprint Solves

Your IoT deployment has 15,000 devices pushing telemetry data, but your cloud-only architecture cannot handle the ingestion rate without throttling, edge processing latency exceeds 200ms making real-time alerting useless, and a 30-minute internet outage at one facility caused 2 hours of data loss. You need to process data at the edge while maintaining centralized visibility and control.

This blueprint is the edge computing architecture I deployed for an energy company monitoring 22,000 sensors across 14 remote facilities, processing 850,000 telemetry events per second with sub-50ms edge response times and zero data loss during connectivity outages lasting up to 4 hours.

What You Get

• Architecture diagrams — Edge-to-cloud data flow, local processing topology, store-and-forward pipeline, device fleet management hierarchy, and OTA update distribution (Draw.io)
• Terraform modules — IoT Core with device provisioning templates, Greengrass v2 component definitions, Kinesis Data Streams for cloud ingestion, S3 data lake for telemetry storage, and TimeStream for time-series analytics
• Edge deployment packages — Greengrass component recipes for local data filtering, anomaly detection, store-and-forward buffering, and device shadow synchronization
• Fleet management runbook — Device provisioning at scale, certificate rotation procedure, OTA deployment strategy, and edge health monitoring dashboards

Key Architecture Decisions

• AWS IoT Greengrass v2 over custom edge software — Custom MQTT brokers and edge agents require ongoing maintenance for security patches, protocol updates, and device compatibility. Greengrass v2 provides managed OTA updates, local Lambda execution, stream management with store-and-forward, and device shadow sync — all maintained by AWS.
• Edge-first processing with cloud aggregation — Sending all raw telemetry to the cloud wastes bandwidth and increases latency. Edge components filter noise, detect local anomalies, and aggregate data before transmission. Only significant events and 1-minute aggregates reach the cloud, reducing data transfer costs by 85%.
• Store-and-forward over fire-and-forget — IoT environments experience connectivity drops. Greengrass Stream Manager buffers data locally during outages and replays it in order when connectivity restores. Zero data loss without application-level retry logic on each device.
• X.509 certificates per device over shared API keys — A compromised API key exposes your entire fleet. Per-device X.509 certificates with Just-In-Time Registration mean compromising one device affects only that device, and you can revoke individual certificates without rotating credentials fleet-wide.

Who This Blueprint Is For

• IoT Architects designing edge computing platforms for industrial or facility monitoring
• Embedded Engineers integrating devices with cloud backends for the first time
• Platform teams building centralized IoT management for multi-site deployments
• Operations Managers who need real-time alerting from remote facilities with unreliable connectivity

Your First 48 Hours

Deploy IoT Core and a single Greengrass core device (use a Raspberry Pi or EC2 instance as a simulated edge device) using the Terraform modules. Publish telemetry from the simulated device and verify it appears in the IoT Core MQTT test client. On day two, deploy the local anomaly detection Greengrass component and simulate a sensor spike. Verify that the edge component triggers a local alert within 50ms while also forwarding the anomaly event to the cloud pipeline for centralized logging.

Limitations and Trade-offs

Greengrass v2 requires a minimum of 256MB RAM and 1GHz CPU on edge devices — low-power microcontrollers (ESP32, Arduino) need FreeRTOS with IoT Core direct connection instead. The store-and-forward buffer is limited by local disk space — at 1,000 events/second, a 16GB buffer lasts approximately 4 hours. TimeStream costs scale with data ingestion volume; at 100,000 writes per second, expect $2,000-4,000/month. The blueprint does not cover MQTT v5 features — it uses MQTT 3.1.1 which is the Greengrass default.