109  Cloud Platforms & Queues

In 60 Seconds

AWS IoT Core handles billions of messages/day with pay-per-message pricing ($1/million); Azure IoT Hub offers built-in device twin management and edge runtime (IoT Edge); Google Cloud IoT targets AI/ML workloads with tight BigQuery and TensorFlow integration. For message brokers, use MQTT (lightweight, pub/sub, best for constrained devices), AMQP (reliable enterprise messaging), or Kafka (high-throughput stream processing at 100K+ msg/sec).

109.1 Learning Objectives

By the end of this chapter, you will be able to:

• Compare Cloud Platforms: Evaluate AWS IoT, Azure IoT Hub, and alternatives for specific requirements
• Select Message Brokers: Choose appropriate message queue technologies for IoT workloads
• Design Message Architecture: Apply pub/sub patterns with appropriate QoS levels
• Estimate Capacity: Calculate message broker requirements for IoT deployments

For Beginners: Cloud Platforms & Queues

This chapter covers foundational concepts for designing IoT systems at scale. Think of IoT system design like city planning – you need to consider where devices go, how they communicate, where data is stored, and how everything stays secure. Reference architectures and design principles help you create systems that work reliably and can grow over time.

109.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• Cloud Computing Fundamentals: Understanding of NIST cloud model
• Cloud Service Models: Knowledge of IaaS, PaaS, SaaS
• MQTT Protocol: Basic MQTT concepts

Sensor Squad: Cloud Helpers for Your Smart Devices!

Hey there, young inventor! Imagine you have a robot pet that needs to talk to your tablet. But your robot is in the backyard and your tablet is in your bedroom. How do they communicate?

Meet the Cloud - Like a Super Smart Post Office!

Think of the cloud as a magical post office in the sky:

• Your Robot writes a message: “I’m hungry! Battery at 50%”
• The Cloud receives the message and holds onto it
• Your Tablet picks up the message whenever it’s ready

Why is this cool?

• Your robot doesn’t need to find your tablet directly
• Messages wait safely even if your tablet is sleeping
• Many devices can send messages at once without getting confused!

Real-World Example: When you ask a smart speaker “What’s the weather?”, it sends your question to the cloud. The cloud figures out the answer and sends it back. All in seconds!

Fun Fact: AWS, Azure, and Google Cloud are like different post office companies - they all deliver messages, but some are better for certain jobs!

109.3 Cloud IoT Platform Architecture Overview

109.4 Major Cloud IoT Platforms

Platform	Strengths	Best For
AWS IoT Core	Most features, largest ecosystem	Enterprise, complex needs
Azure IoT Hub	Best Microsoft integration	Existing Microsoft shops
ClearBlade	Best ML/AI integration (Google partner)	Data analytics focus
IBM Watson IoT	Industry-specific solutions	Manufacturing, logistics

Note (2025): Google Cloud IoT Core was discontinued in August 2023. Google recommends ClearBlade as the migration path for IoT device management. Google Cloud services like Pub/Sub, BigQuery, and Vertex AI remain available for data processing and analytics.

109.4.1 Platform Selection Decision Flowchart

109.5 AWS IoT Core vs Azure IoT Hub

109.5.1 Platform Feature Comparison

Tradeoff: AWS IoT Core vs Azure IoT Hub

Option A (AWS IoT Core): Largest IoT ecosystem with 200+ integrated services. Pricing at $1.00 per million messages plus $0.08 per million connection-minutes. Best-in-class rule engine with SQL-like filtering. Free tier: 250,000 messages/month for 12 months.

Option B (Azure IoT Hub): Tightest integration with Microsoft ecosystem (Active Directory, Power BI, Dynamics 365). Tier-based pricing starting at $10/month (S1: 400,000 messages/day). Built-in device twin synchronization. Superior hybrid cloud support with Azure Stack.

Decision Factors:

• Choose AWS when: Your team has AWS experience, you need maximum service breadth (200+ services), cost optimization at scale is critical, or you require advanced rule engine capabilities.

• Choose Azure when: Your organization uses Microsoft 365, Active Directory, or Dynamics 365, you need hybrid on-premises deployment, or predictable tier-based pricing is preferred for budgeting.

• Cost comparison at scale: 100,000 devices sending 10 messages/day = 30M messages/month. AWS: ~$462/month. Azure S2: ~$400/month. At this scale, Azure is 13% cheaper with predictable costs.

Putting Numbers to It

MQTT Broker Capacity Planning for Smart City Parking

A smart city deploys 50,000 parking sensors using MQTT. Each sensor publishes occupancy status on change (average 10 times/day) and keeps a persistent connection. Can a mid-range MQTT broker like EMQX handle this load?

Given data:

• Sensors: 50,000
• Status updates: 10/day per sensor (non-uniform, peak at 8am and 5pm)
• Peak factor: 30% of daily messages occur in 2 hours (commute times)
• MQTT broker: EMQX on 8-core server (rated 1M concurrent connections, 100K msg/sec)

Step 1: Calculate average and peak message rates

Daily messages: \[M_{\text{daily}} = 50,000 \times 10 = 500,000 \text{ messages/day}\]

Average TPS (transactions per second): \[\text{TPS}_{\text{avg}} = \frac{500,000}{86,400 \text{ sec}} \approx 5.79 \text{ msg/sec}\]

Peak TPS (30% of messages in 2 hours): \[M_{\text{peak}} = 500,000 \times 0.30 = 150,000 \text{ messages}\] \[\text{TPS}_{\text{peak}} = \frac{150,000}{7,200 \text{ sec}} \approx 20.83 \text{ msg/sec}\]

Step 2: Check concurrent connection capacity

EMQX capacity: 1,000,000 concurrent connections Required: 50,000 persistent MQTT connections

\[\text{Utilization}_{\text{conn}} = \frac{50,000}{1,000,000} = 5\%\]

Step 3: Check message throughput capacity

EMQX capacity: 100,000 msg/sec Peak load: 20.83 msg/sec

\[\text{Utilization}_{\text{msg}} = \frac{20.83}{100,000} = 0.02\%\]

Step 4: Calculate memory requirements

Per-connection overhead: ~4 KB (MQTT session state, buffer) \[\text{Memory}_{\text{required}} = 50,000 \times 4 \text{ KB} = 200,000 \text{ KB} \approx 195 \text{ MB}\]

Server RAM: 8 GB = 8,192 MB Memory utilization: \(195/8192 = 2.4\%\)

Result: The system is massively over-provisioned! The 8-core EMQX broker uses only 5% of connection capacity, 0.02% of message capacity, and 2.4% of memory. This deployment could scale to 1 million sensors (20x growth) before reaching even 50% utilization. For cost optimization, downsize to 2-core instance or consolidate multiple cities onto this broker.

Key insight: IoT MQTT deployments are often connection-bound (many long-lived connections) rather than throughput-bound (low message rates). Size brokers based on concurrent connections, not messages/sec.

109.6 Managed Services vs Self-Hosted

Tradeoff: Managed IoT Services vs Self-Hosted Open Source

Option A (Managed Services): AWS IoT Core, Azure IoT Hub, or HiveMQ Cloud. Zero infrastructure management, automatic scaling, 99.9% SLA, pay-per-use pricing.

Option B (Self-Hosted): EMQX, Mosquitto, or VerneMQ on your own infrastructure. Full control, no per-message fees, data sovereignty guaranteed. Requires DevOps expertise and 24/7 operations.

Decision Factors:

• Choose Managed Services when: Team lacks Kubernetes/infrastructure expertise, time-to-market is critical, device count is under 100,000, or you need global distribution without building multi-region infrastructure.

• Choose Self-Hosted when: Message volume exceeds 100M/month where managed pricing becomes prohibitive, regulatory requirements mandate data residency on specific infrastructure, or custom protocol extensions are needed.

• Break-even calculation: At 50M messages/month, AWS IoT Core costs ~$50. Self-hosted EMQX on 3x m5.large ($210/month) handles 500M messages/month. Self-hosted becomes cheaper above 200M messages/month, but add DevOps engineer time.

109.6.1 Cost vs Scale Comparison

Cost Break-Even Analysis

Message Volume	AWS IoT Core	Self-hosted EMQX	Winner
10M/month	$10	$210	AWS
50M/month	$50	$210	AWS
100M/month	$100	$210	AWS
200M/month	$200	$210	~Equal
500M/month	$500	$420	Self-hosted
1B/month	$1,000	$630	Self-hosted

Note: Self-hosted costs include 3x m5.large instances. Add $5K-15K/month for DevOps engineer time in TCO calculations.

109.7 Message Queue Selection for IoT

109.7.1 Message Queue Categories

Category	Examples	Best For
MQTT Brokers	Mosquitto, EMQX, HiveMQ	Device-to-cloud, pub/sub
General Message Queues	RabbitMQ, ActiveMQ	Enterprise integration
Streaming Platforms	Apache Kafka, Pulsar, Kinesis	High-throughput analytics

109.7.2 Selection by Connection Scale

109.7.3 Selection by Throughput

Throughput	Recommended Technology
< 1,000 msg/sec	Mosquitto, RabbitMQ
1K - 100K msg/sec	EMQX, Kafka (3-node)
100K - 1M msg/sec	Kafka (5+ nodes), Pulsar
> 1M msg/sec	Multi-region Kafka, Pulsar

109.7.4 Latency Profiles

# Typical end-to-end latencies (publish to subscribe)

latency_profiles = {
    "mosquitto_local": {
        "p50": "0.5 ms",
        "p99": "2 ms",
        "use_case": "Local gateway aggregation"
    },
    "emqx_cluster": {
        "p50": "3 ms",
        "p99": "15 ms",
        "use_case": "Regional IoT platform"
    },
    "kafka_cluster": {
        "p50": "5 ms",
        "p99": "50 ms",
        "use_case": "Analytics pipeline (batch-friendly)"
    },
    "cloud_mqtt_service": {
        "p50": "20 ms",
        "p99": "100 ms",
        "use_case": "Global consumer IoT"
    }
}

For real-time control (<10ms required): Use local MQTT broker at edge.

For monitoring (<1 second acceptable): Cloud MQTT services work well.

For analytics (seconds to minutes acceptable): Kafka/Pulsar provide better throughput.

109.8 Message Broker Selection Flowchart

Message Broker Selection Flowchart

Figure 109.1: Message broker selection flowchart for IoT use cases.

109.9 MQTT Broker Comparison

Broker	Connections	Throughput	Clustering	License
Mosquitto	100K	50K msg/s	Bridge only	EPL/EDL
EMQX	1M+	1M+ msg/s	Native	Apache 2.0
HiveMQ	10M+	1M+ msg/s	Native	Commercial
VerneMQ	1M+	500K msg/s	Native	Apache 2.0

109.9.1 Message Lifecycle in Cloud IoT Platform

Understanding how a message flows from device to application helps in debugging and optimizing IoT systems:

Key stages in the message lifecycle:

1. Device publishes: Sensor sends data using MQTT with appropriate QoS
2. Broker acknowledges: Confirms receipt (QoS 1/2) for reliability
3. Rules engine filters: Applies SQL-like conditions to route messages
4. Message queued: Buffered for downstream processing
5. Processor handles: Applies transformations, aggregations, or ML inference
6. Data stored: Written to time-series DB or data lake
7. Application notified: Real-time alerts or dashboard updates

109.10 QoS Trade-offs

QoS Level	Delivery	Broker CPU	Latency	Use Case
QoS 0	At most once	Low	Lowest	Telemetry, non-critical
QoS 1	At least once	Medium	Medium	Commands, events
QoS 2	Exactly once	High	Highest	Financial, safety-critical

Rule of thumb: 90% of IoT traffic should use QoS 0 or QoS 1. QoS 2 overhead is significant.

Common Pitfalls: Cloud IoT Platform Selection

Pitfall 1: Ignoring Total Cost of Ownership (TCO)

Many teams compare only message pricing, missing:

• Data egress costs (can exceed message costs at scale)
• Storage costs for device shadows/twins
• Rule engine execution costs
• Support tier costs

Pitfall 2: Vendor Lock-in via Proprietary Features

Avoid deep integration with platform-specific features if portability matters:

• AWS IoT Rules SQL syntax differs from Azure IoT Hub message routing
• Device twin schemas are not portable between platforms
• Certificates and authentication schemes differ

Pitfall 3: Underestimating Connection vs Message Costs

AWS charges separately for connection-minutes and messages. A device connected 24/7 sending 1 message/hour costs more in connection fees than message fees.

Pitfall 4: QoS 2 Overuse

Using QoS 2 “for safety” when QoS 1 + idempotent processing would suffice. QoS 2 can reduce throughput by 50%.

109.11 Capacity Planning Example

Scenario: Smart city with 500,000 parking sensors

Requirements:
  devices: 500,000
  message_rate: 2 msg/device/hour (state changes)
  message_size: 128 bytes (JSON payload)
  peak_multiplier: 5x (morning/evening rush)

Calculations:
  avg_throughput: 500,000 x 2 / 3600 = 278 msg/sec
  peak_throughput: 278 x 5 = 1,390 msg/sec
  bandwidth: 1,390 x 128 = 178 KB/sec = 1.4 Mbps

  # Session memory (persistent sessions)
  session_memory: 500,000 x 2 KB = 1 GB

Recommendation:
  technology: EMQX cluster (3 nodes)
  node_spec: 8 vCPU, 16 GB RAM, SSD
  estimated_cost: ~$500/month (cloud VMs)

Alternative:
  technology: AWS IoT Core
  pricing: $1.00 per million messages + $0.08 per million minutes
  estimated_cost: ~$1,728/month

109.11.1 Interactive: MQTT Capacity Planning Calculator

viewof num_devices = Inputs.range([1000, 1000000], {value: 500000, step: 1000, label: "Number of Devices"})

viewof msg_per_hour = Inputs.range([1, 240], {value: 2, step: 1, label: "Messages per Device per Hour"})

viewof peak_mult = Inputs.range([1, 10], {value: 5, step: 0.5, label: "Peak Multiplier"})

avg_tps = (num_devices * msg_per_hour) / 3600
peak_tps = avg_tps * peak_mult
session_mem_mb = (num_devices * 2) / 1024
aws_monthly = ((num_devices * msg_per_hour * 24 * 30) / 1e6) * 1.00 + ((num_devices * 24 * 60 * 30) / 1e6) * 0.08

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #3498DB; margin-top: 0.5rem;">
  <p><strong>Average Throughput:</strong> ${avg_tps.toFixed(1)} msg/sec</p>
  <p><strong>Peak Throughput:</strong> ${peak_tps.toFixed(1)} msg/sec</p>
  <p><strong>Session Memory (2 KB/device):</strong> ${session_mem_mb.toFixed(0)} MB</p>
  <p><strong>Estimated AWS IoT Core Cost:</strong> $${aws_monthly.toFixed(2)}/month</p>
  <p style="font-size:0.85em; color:#555;">Broker recommendation: ${num_devices < 10000 ? "Mosquitto (single node)" : num_devices < 100000 ? "EMQX (single node)" : num_devices < 500000 ? "EMQX (3-node cluster)" : "EMQX (5+ node cluster) or HiveMQ"}</p>
</div>`

109.12 Recommended Architecture Patterns

109.12.1 Pattern 1: Edge MQTT + Cloud Kafka

Best for: High-volume analytics with local buffering

109.12.2 Pattern 2: Cloud MQTT with Database Sink

Best for: Serverless, simple telemetry storage

109.12.3 Pattern 3: Federated MQTT Cluster

Best for: Global deployments with regional data sovereignty

Minimum Viable Understanding: Message Queuing for IoT

Core Concept: A message queue is an intermediary buffer that decouples message producers (IoT devices) from consumers (backend services), enabling asynchronous communication where senders and receivers operate independently.

Why It Matters: IoT devices send data in bursts while backend systems process at constant rates. Message queues absorb traffic spikes, handle network interruptions gracefully, and enable system components to fail independently.

Key Takeaway: Choose MQTT brokers for device-to-cloud pub/sub (Mosquitto for <10K devices, EMQX for 10K-1M), Kafka for high-throughput analytics requiring replay, and managed services when operational simplicity matters more than cost.

109.13 Hands-On Exercise: Platform Selection Workshop

Exercise: Design a Cloud Architecture

Scenario: You are architecting an IoT solution for a smart agriculture company with:

• 25,000 soil moisture sensors across 50 farms
• Sensors report every 15 minutes (100 bytes per message)
• 5% of sensors require real-time alerts (< 1 second latency)
• Data must be stored for 2 years for yield analysis
• Budget: $2,000/month for cloud infrastructure
• Team: 1 part-time DevOps engineer

Tasks:

1. Calculate message volume: How many messages per month?
2. Estimate costs: Compare AWS IoT Core vs self-hosted EMQX
3. Select architecture pattern: Which of the 3 patterns fits best?
4. Design the solution: Draw the data flow diagram

Solution Hints (click to expand):

Solution Approach

1. Message volume: 25,000 sensors x 4 messages/hour x 24 hours x 30 days = 72M messages/month

2. Cost comparison:

   • AWS IoT Core: 72M x $1/1M = $72 + connection costs (~$150) = ~$222/month
   • Self-hosted: Below break-even, managed service preferred

3. Pattern selection: Pattern 2 (Cloud MQTT + Database Sink) - simple, fits budget, low DevOps overhead

4. Recommended architecture:

   • AWS IoT Core for MQTT connectivity
   • IoT Rules to route 5% alerts to Lambda for real-time processing
   • Kinesis Data Firehose to S3 for 2-year storage
   • Athena for ad-hoc yield analysis

Worked Example: Cost Analysis for 100K Smart Meter Deployment (AWS vs Self-Hosted)

Scenario: A utility company deploys 100,000 smart electricity meters that report power consumption every 15 minutes (96 readings/day per meter). Each reading is 50 bytes. The system must handle peak demand (morning/evening) with 5x average throughput. Calculate total cost for AWS IoT Core versus self-hosted EMQX over 3 years.

Given Data:

• Devices: 100,000 smart meters
• Message frequency: 96 messages/device/day
• Message size: 50 bytes
• Peak multiplier: 5x average
• Time horizon: 3 years (36 months)

Step 1 - Calculate Message Volume:

Daily messages: 100,000 devices × 96 messages/day = 9,600,000 messages/day
Monthly messages: 9.6M × 30 days = 288,000,000 messages/month
Annual messages: 288M × 12 = 3,456,000,000 messages/year (3.46 billion)
3-year total: 3.46B × 3 = 10.37 billion messages

Step 2 - Calculate Throughput Requirements:

Average TPS: 9,600,000 / 86,400 seconds = 111 TPS
Peak TPS: 111 × 5 = 556 TPS
Bandwidth: 556 TPS × 50 bytes = 27.8 KB/sec = 0.22 Mbps (negligible)

Step 3 - AWS IoT Core Pricing:

Connection minutes (devices connected 24/7):

Connection-minutes per device: 24 hrs × 60 min × 30 days = 43,200 min/month
Total connection-minutes: 100,000 × 43,200 = 4,320,000,000 per month
Cost: $0.08 per million minutes = 4,320 × $0.08 = $345.60/month

Messaging:

Monthly messages: 288,000,000
Cost: $1.00 per million messages = 288 × $1.00 = $288/month

Rules engine (assume 1 rule execution per message for routing to database):

Monthly rule executions: 288,000,000
Cost: $0.15 per million = 288 × $0.15 = $43.20/month

Data transfer OUT (to monitoring dashboard, assume 20% of messages):

Monthly data transfer: 288M × 0.2 × 50 bytes = 2.88 GB
Cost: First 10 GB free, then $0.09/GB = ~$0/month (under free tier)

AWS IoT Core Total:

Monthly: $345.60 (connections) + $288 (messages) + $43.20 (rules) = $676.80/month
Annual: $676.80 × 12 = $8,121.60/year
3-year total: $8,121.60 × 3 = $24,364.80

Step 4 - Self-Hosted EMQX Pricing:

Infrastructure (3-node cluster for redundancy):

Node specs: 8 vCPU, 16 GB RAM, 200 GB SSD
Cloud instances: AWS c5.2xlarge at $0.34/hour
Cost per node: $0.34 × 24 × 30 = $244.80/month
3-node cluster: $244.80 × 3 = $734.40/month

Load balancer:

AWS ALB: $22/month (fixed) + $0.008/LCU-hour
Estimated LCU: 20 LCU-hours/month = $3.60
Total: $22 + $3.60 = $25.60/month

Storage (for message retention/queueing during DB outage):

EBS volumes: 200 GB × 3 nodes × $0.10/GB-month = $60/month

Data transfer (inter-AZ for cluster replication):

Estimated: 50 GB/month at $0.01/GB = $0.50/month

Monitoring/logging (CloudWatch):

Estimated: $30/month

DevOps/operations (1/4 FTE for maintenance, updates, on-call):

DevOps engineer: $150,000/year × 0.25 FTE = $37,500/year = $3,125/month

Self-Hosted EMQX Total:

Monthly infrastructure: $734.40 + $25.60 + $60 + $0.50 + $30 = $850.50/month
Monthly ops: $3,125/month
Total monthly: $850.50 + $3,125 = $3,975.50/month
Annual: $3,975.50 × 12 = $47,706/year
3-year total: $47,706 × 3 = $143,118

Step 5 - Cost Comparison:

Item	AWS IoT Core	Self-Hosted EMQX	Difference
Monthly cost	$676.80	$3,975.50	+$3,298.70 (487% more)
Annual cost	$8,121.60	$47,706	+$39,584.40
3-year total	$24,364.80	$143,118	+$118,753.20

Winner: AWS IoT Core is 5.9x cheaper over 3 years for this deployment.

Step 6 - Break-Even Analysis:

When does self-hosted become cheaper? When DevOps costs are removed or amortized across multiple projects:

Infrastructure-only self-hosted:

Monthly: $850.50 (infrastructure only)
Annual: $850.50 × 12 = $10,206
3-year: $10,206 × 3 = $30,618

Break-even: $30,618 (self-hosted infra) vs $24,365 (AWS IoT Core)
Self-hosted is still 25% more expensive without considering DevOps labor.

At what message volume does self-hosted win?

AWS IoT Core scales linearly with messages. Self-hosted has fixed infrastructure costs. Break-even:

AWS cost = Self-hosted infrastructure cost
($1.00/million messages × M) + ($0.08/million connection-minutes × CM) = $850.50/month

For 100K devices always-connected:
CM = 4,320 million minutes = $345.60/month (fixed)
M (messages) × $1.00/million = $850.50 - $345.60 = $504.90
M = 504.9 million messages/month

Break-even: ~505 million messages/month
Current: 288 million messages/month

Required scale: 505M / 288M = 1.75x current load (175,000 devices)

Self-hosted becomes cheaper at 175K+ devices (infrastructure only, excluding DevOps).

Step 7 - Hidden Costs Not Included:

AWS IoT Core additional benefits:

• No upgrade/patching time (managed service)
• Built-in device registry and shadow service
• Integrated with AWS ecosystem (Lambda, DynamoDB, S3)
• Auto-scaling to handle load spikes
• Global availability and DDoS protection
• Security audit compliance (SOC2, ISO27001)

Self-hosted additional costs:

• TLS certificate management
• Security patching and CVE monitoring
• Disaster recovery testing
• Cluster upgrades with zero downtime
• 24/7 on-call rotation for outages
• Performance tuning and optimization

Recommendation: For this 100K smart meter deployment, AWS IoT Core is the clear winner due to: 1. 5.9x lower total cost over 3 years ($24K vs $143K) 2. Zero DevOps overhead (no on-call, no upgrades) 3. Built-in features (device registry, rules engine, shadows) 4. Elastic scaling for future growth

Self-hosted would only make sense if: - Device count exceeds 175,000 (break-even point) - Regulatory requirements mandate on-premises data (rare for smart meters) - Company already has 24/7 DevOps team managing similar infrastructure - Message volume exceeds 500M/month sustained

109.14 Concept Relationships

Current Concept	Builds On	Enables	Contrasts With	Common Confusion
AWS IoT Core	Cloud computing, MQTT protocol	Device connectivity, rules engine	Self-hosted MQTT brokers	Per-message pricing always expensive (cost-effective <200M msg/month)
Azure IoT Hub	Cloud computing, device twins	Microsoft ecosystem integration	AWS IoT Core	Less capable than AWS (false – different strengths)
Message Brokers	Pub/sub pattern, QoS levels	Decoupled IoT messaging	Request-response APIs	Brokers store messages indefinitely (only with retention config)
QoS 2 Exactly-Once	MQTT protocol, reliability	Safety-critical commands, financial	QoS 0/1 best effort	QoS 2 required for all commands (use only when duplication unacceptable)
Managed vs Self-Hosted	TCO analysis, operational overhead	Platform selection	Cloud-only mindset	Self-hosted always cheaper at scale (ignores DevOps labor cost)

109.15 See Also

• Cloud Computing Fundamentals - NIST model, essential characteristics
• MQTT Protocol - Pub/sub messaging for IoT devices
• Message Queuing and Stream Processing - Kafka, Pulsar for analytics
• Cloud Security for IoT - Per-device certificates, IAM policies
• Production Cloud Deployment - Cost optimization, capacity planning

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

Key Concepts

• AWS IoT Core: Amazon’s managed MQTT broker and device gateway supporting billions of device connections, with rules engine for routing messages to 20+ AWS services without provisioning servers
• Azure IoT Hub: Microsoft’s bidirectional IoT communication service with per-device authentication, cloud-to-device commands, device twin state synchronization, and integration with Azure Stream Analytics
• Google Cloud IoT Core: Google’s device management and MQTT/HTTP ingestion service (deprecated 2023), replaced by Google’s recommendation to use third-party brokers with Pub/Sub for IoT ingestion
• Device Twin / Shadow: A cloud-side JSON document that represents the last-known and desired state of an IoT device, enabling state synchronization even when devices are offline
• Rules Engine: A cloud-side processing component that evaluates incoming IoT messages against SQL-like expressions and routes matching messages to downstream services (databases, queues, Lambda functions) without custom code
• Device Provisioning Service (DPS): A helper service that automates zero-touch, just-in-time provisioning of IoT devices to the correct IoT hub, eliminating manual device registration at scale
• Time-Series Database: A database optimized for storing and querying sequential time-stamped IoT sensor readings (InfluxDB, AWS Timestream, Azure Data Explorer) with efficient compression and time-range queries

Label the Diagram

💻 Code Challenge

109.16 Summary

This chapter covered cloud IoT platforms and message queues:

1. Platform Selection: AWS for breadth, Azure for Microsoft integration
2. Managed vs Self-Hosted: Break-even around 200M messages/month
3. Message Broker Types: MQTT for devices, Kafka for analytics
4. QoS Levels: 90% of traffic should use QoS 0 or 1
5. Capacity Planning: Calculate connections, throughput, and memory requirements

109.17 Further Reading

1. Mell, P., & Grance, T. (2011). “The NIST Definition of Cloud Computing.” NIST Special Publication 800-145.

2. Botta, A., et al. (2016). “Integration of Cloud computing and Internet of Things: A survey.” Future Generation Computer Systems, 56, 684-700.

3. Gubbi, J., et al. (2013). “Internet of Things (IoT): A vision, architectural elements, and future directions.” Future Generation Computer Systems, 29(7), 1645-1660.

109.18 Knowledge Check

Quiz: Cloud Platforms & Queues

109.19 What’s Next?

You’ve completed the cloud computing series. Continue with:

Next Topic	Description
Edge-Fog-Cloud Overview	The complete computing continuum from edge to cloud
Data in the Cloud	Deep dive into cloud data processing and analytics