Our IoT asset tracking system uses an event rule to write device location updates to DynamoDB, but updates are failing intermittently during large fleet movements (100+ vehicles updating simultaneously). The rule SQL is SELECT deviceId, latitude, longitude, timestamp FROM 'fleet/+/location' with a DynamoDB action.
CloudWatch metrics show about 60% of location events successfully trigger the rule (TopicMatch incrementing), but only 30% result in DynamoDB writes. The DynamoDB table has sufficient write capacity (1000 WCU provisioned) and isn’t being throttled according to CloudWatch metrics.
IoT Core logs show DynamoDB write failed errors but don’t provide specific details. The IAM role attached to the rule has dynamodb:PutItem permission for the table ARN. DynamoDB schema uses deviceId as partition key with String type. Why would DynamoDB writes fail when capacity is available and permissions are configured?
The rule action configuration looks correct - it maps deviceId to the partition key, and latitude/longitude/timestamp to regular attributes. All are defined as String type in the mapping. Could there be an issue with the actual data format coming from devices? Like if latitude is sent as a number instead of string?
Data type mismatches are a common cause of DynamoDB write failures from IoT rules. If your table schema expects String but the rule is sending Number, the write fails. Check your device payload - IoT Core might be parsing latitude/longitude as numbers from JSON.
Also, verify the timestamp format. DynamoDB expects specific formats for timestamp attributes. If your device is sending Unix epoch as a number but your attribute mapping expects ISO 8601 string, that would cause failures.
Use the IoT Core test client to inspect the actual message payload and data types being sent.
Converting in the rule SQL is cleaner than changing your table schema (which would require data migration). You can use the cast() function in IoT SQL to convert types. However, for coordinates, storing as Number in DynamoDB is actually better for range queries and precision. I’d recommend updating the table schema and rule action to use Number type for latitude/longitude.
Check if your rule action is using the correct attribute mapping for DynamoDB. The action configuration needs to map IoT message fields to DynamoDB attribute names and types. If the mapping is wrong or the data types don’t match the table schema, writes will fail silently.
Makes sense to use Number type for coordinates. I’ll need to update the table schema and the rule action configuration. For the IAM permissions, do I need anything beyond dynamodb:PutItem for the rule to write successfully? Want to make sure I’m not missing any other permission requirements.