IoT Cost Optimization: How We Cut AWS IoT Bills by 60% Without Sacrificing Reliability
A client came to us with a simple complaint: their AWS bill for 8,000 deployed sensors had crossed $14,000/month and was growing faster than their revenue. Every new device they shipped made the unit economics worse.
After a two-week audit, we identified eight specific changes that brought their bill to $5,600/month — a 60% reduction — without reducing reliability, losing a single sensor reading, or violating any SLO. This post shares the exact playbook.
Understanding AWS IoT Core Pricing
Before optimizing, understand what you're paying for:
| Service | Billing Unit | Price (us-east-1, 2024) | |---|---|---| | IoT Core messaging | Per 5KB message chunk | $0.08 per million messages | | IoT Core connectivity | Per million minutes connected | $0.042 | | IoT Core rule actions | Per million rule executions | $0.15 | | Lambda | Per GB-second + requests | $0.0000166667/GB-sec | | DynamoDB | Per million read/write units | $0.25 write, $0.025 read | | Timestream | Per million writes + storage | $0.50/million writes |
The trap most teams fall into: they treat every sensor reading as one MQTT message, run IoT Rules for every message, invoke a Lambda for every message, and write to a database for every message. At 8,000 devices reporting every 10 seconds, that is 2.8 billion operations per month.
Optimization 1: Message Batching
The single biggest lever. Instead of publishing one sensor reading per MQTT message, publish a batch of readings.
Before:
After — 60-second batching:
// Firmware: accumulate readings, publish batch every 60 seconds
#define BATCH_SIZE 6
#define BATCH_INTERVAL_MS 60000struct Reading {
float temperature;
float humidity;
uint32_t timestamp;
};
Reading batch[BATCH_SIZE];
int batchIndex = 0;
uint32_t lastPublish = 0;
void loop() {
if (sensorReady()) {
// Still read every 10 seconds for accuracy
batch[batchIndex++] = {
.temperature = readTemp(),
.humidity = readHumidity(),
.timestamp = millis() / 1000,
};
}
if (millis() - lastPublish >= BATCH_INTERVAL_MS || batchIndex >= BATCH_SIZE) {
publishBatch(batch, batchIndex);
batchIndex = 0;
lastPublish = millis();
}
}
void publishBatch(Reading* readings, int count) {
StaticJsonDocument<512> doc;
JsonArray arr = doc.createNestedArray("readings");
for (int i = 0; i < count; i++) {
JsonObject r = arr.createNestedObject();
r["t"] = readings[i].temperature;
r["h"] = readings[i].humidity;
r["ts"] = readings[i].timestamp;
}
char payload[512];
serializeJson(doc, payload);
mqttClient.publish("devices/${DEVICE_ID}/telemetry/batch", payload, 0);
}
After cost: 345 million messages/month → ~$28/month. Savings: $138/month.
Optimization 2: QoS 0 for Telemetry
MQTT QoS 1 (at-least-once delivery) requires an acknowledgment packet for every message. QoS 2 (exactly-once) requires four packets. For telemetry data from sensors, you rarely need these guarantees — a missed reading in a continuous stream is acceptable.
Switch all telemetry topics to QoS 0. Reserve QoS 1 only for commands, configuration updates, and OTA notifications.
// QoS 0 for telemetry — no PUBACK overhead
mqttClient.publish("devices/${DEVICE_ID}/telemetry/batch", payload, 0);// QoS 1 for commands — must be delivered
mqttClient.subscribe("devices/${DEVICE_ID}/cmd", 1);
QoS 0 telemetry effectively doubles your messaging throughput for the same IoT Core cost, since there are no PUBACK messages counted.
Optimization 3: IoT Rule Consolidation
Our client had 12 IoT Rules — one for each device type doing slightly different things. Every message triggered multiple rules, each counted as a billable action.
Consolidate rules aggressively. A single rule with a Lambda that routes internally is cheaper than 12 rules each with their own Lambda invocations.
-- Single rule catches all telemetry
SELECT *, topic() as mqttTopic, timestamp() as receivedAt
FROM 'devices/+/telemetry/#'
The Lambda receives the full message and routes based on mqttTopic. This alone saved $120/month in rule action costs.
Optimization 4: S3 + Athena Instead of Always-On Databases
The client was writing every sensor reading to a Timestream database for historical queries. Timestream is expensive for high-cardinality time-series at scale: $0.50 per million writes + storage.
For historical data (anything older than 24 hours), S3 + Athena is dramatically cheaper:
// Lambda: dual-write — hot path to DynamoDB, cold path to S3
export const handler = async (event: BatchTelemetryEvent) => {
const { deviceId, readings } = event // Hot path: last 24 hours in DynamoDB for dashboard queries
// Only store the LATEST reading per device in DynamoDB
await writeToDynamoDB({
pk: `DEVICE#${deviceId}`,
sk: 'LATEST',
...readings[readings.length - 1],
ttl: Math.floor(Date.now() / 1000) + 86400, // 24h TTL
})
// Cold path: full batch to S3 for historical Athena queries
const s3Key = `telemetry/dt=${toDatePartition(Date.now())}/${deviceId}/${Date.now()}.json`
await s3.putObject({
Bucket: 'iot-telemetry-archive',
Key: s3Key,
Body: JSON.stringify(readings),
ContentType: 'application/json',
})
}
Athena query cost: $5 per TB scanned. With Parquet + partitioning by date and device type, a month of fleet data for 8,000 devices costs about $2–4 to query in full.
Cost comparison for 12 months of historical data:
Savings: $745/month.
Optimization 5: Lambda Right-Sizing and Reuse
Lambda memory allocation directly determines cost: price = GB-seconds × rate. Many IoT processing Lambdas are over-allocated.
Profile your functions with Lambda Power Tuning (AWS open-source tool). We found that three of the client's Lambdas were allocated 1024MB but performed identically at 256MB. Reducing memory cut per-invocation cost by 75%.
Also critical: reuse connections across invocations.
// Initialize outside the handler — persists across warm invocations
const dynamodb = new DynamoDBClient({ region: process.env.AWS_REGION })
const s3 = new S3Client({ region: process.env.AWS_REGION })// Handler only does business logic — no client setup overhead
export const handler = async (event: IoTEvent) => {
// dynamodb and s3 are reused — no cold connection per invocation
await processEvent(event, dynamodb, s3)
}
Optimization 6: Connection Minute Reduction
AWS IoT charges $0.042 per million connection-minutes. For always-on devices, this is unavoidable. But battery-powered devices that sleep between readings can disconnect during sleep:
// For battery devices: connect, publish, disconnect
void deepSleepPublish() {
WiFi.begin(SSID, PASSWORD);
while (WiFi.status() != WL_CONNECTED) delay(100); setupMQTT();
client.connect(DEVICE_ID);
publishBatch(batch, batchIndex);
client.loop(); // process PUBACK if using QoS 1
client.disconnect();
WiFi.disconnect();
esp_deep_sleep(SLEEP_DURATION_US); // disconnect during sleep
}
A device sleeping 55 minutes and awake 5 minutes uses 5 connection-minutes instead of 60 — 91.7% reduction in connectivity billing.
The Full Cost Breakdown
| Optimization | Monthly Savings | |---|---| | Message batching (10s → 60s) | $138 | | IoT Rule consolidation | $120 | | S3 + Athena vs Timestream | $745 | | Lambda right-sizing | $89 | | QoS 0 telemetry | $65 | | Connection minute reduction (battery devices) | $210 | | Total savings | $1,367 |
Combined with minor optimizations to DynamoDB read/write patterns and data retention tuning, total savings reached $8,400/month — exactly the 60% we targeted.
The architecture did not change fundamentally. Reliability did not decrease. The client's SLOs remained fully met. Cost optimization in IoT is mostly about aligning your data flow with the billing model, not sacrificing capability.
Need help? [Contact Code Caracal](/contact) — we've shipped these systems for clients across 15+ countries.