We implemented an automated geo-fence alerting system for tracking high-value assets in our supply chain. Previously, we relied on manual dashboard monitoring, which meant geo-fence violations could go unnoticed for 30-60 minutes during off-hours.
The solution uses IoT Rules to detect when GPS coordinates from asset trackers fall outside defined boundaries, triggers a Lambda function to enrich the alert with asset details and location context, then sends SMS notifications via SNS to on-call logistics managers.
Key implementation details:
- Asset trackers publish GPS coordinates every 60 seconds to MQTT topics
- IoT Rule SQL evaluates coordinates against geo-fence boundaries stored as rule parameters
- Lambda integration adds asset metadata from DynamoDB and calculates distance from boundary
- SNS SMS delivers alerts within 10 seconds of violation detection
This reduced our average response time from 45 minutes to under 2 minutes, and we’ve prevented three potential asset losses in the first month of operation. The entire system processes 500+ asset location updates per minute with sub-second latency.
Have you looked at your SNS SMS costs? At scale, SMS can get expensive fast. Consider implementing alert throttling in your Lambda function-if an asset is continuously outside the boundary, you probably don’t need to send SMS every minute. We batch alerts or use exponential backoff (first violation = immediate SMS, subsequent = every 5 min, then 15 min) to reduce noise and costs without sacrificing response time for new violations.
Smart move putting the complex logic in Lambda. One optimization suggestion: implement caching in your Lambda function for the DynamoDB geo-fence lookups. With 500 updates per minute, you’re probably hitting DynamoDB pretty hard. We use ElastiCache or even Lambda environment variables (refreshed every 5 minutes) to cache boundaries, which cut our DynamoDB costs by 80% and improved Lambda execution time from 200ms to 50ms.
This is really impressive! How do you handle the geo-fence boundary definitions in your IoT Rule SQL? Are they hardcoded, or do you have a way to update them dynamically without redeploying the rule? We’re looking at a similar implementation but need to support changing boundaries based on route plans.
Great question. We initially hardcoded boundaries in the SQL but quickly realized that wasn’t scalable. Now the IoT Rule SQL performs a simple range check, and the actual geo-fence logic lives in the Lambda function. Lambda pulls current boundaries from DynamoDB using the asset ID, so we can update geo-fences in real-time without touching the IoT Rule. The SQL just filters for valid GPS coordinates and passes everything to Lambda for detailed evaluation.