Front-End Web & Mobile
Cost Optimization using Amazon Location Tracker Filtering
Introduction
When creating a Tracker resource in Amazon Location Service, you are presented with three options for filtering. Each option has some potential design and cost considerations you should be aware of as they filter out certain updates. We have evaluated the cost and usage of a demo application over time to create some recommendations based on our findings. First, there are some basics you should know before beginning the decision-making process:
- You are billed for every location update and once for evaluating the position update against each linked geofence collection (regardless of the number of geofences in the collection)
- If your tracker is linked to multiple geofence collections, a position update will count as only one location update request but multiple geofence collection evaluations
- Combining your geofences into fewer collections reduces your cost of geofence evaluations.
For this post, we will assume a single stationary device is sending device updates. For each type of accuracy, we create a tagged Amazon Location Service Tracker and Geofence collection containing a single geofence. We are not evaluating enter/exit events, so the geofence is not in the proximity of the simulated device. For each device update, Amazon Location Service trackers will evaluate whether to store it and evaluate it against a geofence, or ignore it, based on the filtering defined.
Our testing uncovered a 46% cost savings when using Distance based filtering and a 43% cost savings when evaluating geofences, and an 85% cost savings on update storage retrieval when using Time based filtering. Read on to learn more about the tests and our results.
Defining the simulations
We will be using the IoT Device Simulator to create our simulations. To deploy the simulator in your account, see the instructions at performing your own tests.
First. for our Distance Filtering device. With Distance Filtering, Amazon Location Service Tracking will only store or evaluate geofences if the device moved 30 meters or greater. IoT Device Simulator has a location field type that allows us to configure a center point, and then a radius (in meters) that the point will be randomly placed. For this example, many of the trackers will have moved less than 30 meters from the previous position, therefore will not be stored or evaluated against our geofences. The deviceId field is also set as static, so every update will update the same device in our Amazon Location tracker resource.
Figure 1. IoT Simulator Location Setup
Next is our Accuracy Filtering. For this, we care about the accuracy. Amazon Location Service will ignore if the update has moved less than the accuracy value. This helps to reduce jitter in tracking updates. For this, our location field stays the same as the Distance Filtering Tracker, but the accuracy field is set as an integer from 0-20. This means we will get evaluations when the device location has moved, and the accuracy value is more than the distance it has moved.
Figure 2. IoT Simulator Accuracy Setup
Finally, we set up our time based tracker. In this case, we will actually run two simulations for the same tracker. In order to keep the device in our Tracker resource the same, we set our deviceId as a static resource with TimeBasedDevice as the default value. This ensures that both simulations update the same device in our tracker resource. Accuracy stays at 0, and location remains the same as our distance based filtering.
Figure 3. IoT Simulator Time Setup
Now we can configure our simulations. In order to make it easier to differentiate between filters, we set up our simulations a few days apart. For distance and accuracy, we configured updates every 5 seconds, for 24 hours. For the time based, we set up two simulations. One sending updates every 45 seconds, and one sending updates every 5 seconds. You will not be billed for the 45 second updates because they will still be within 5 seconds of another update. Because the Device Type points to the same deviceId, we will only get device updates stored every 30 seconds, and not the 5 second updates. However, we will still see a geofence evaluation for every update.
Figure 4. IoT Simulators
Analyzing the simulated results
Since we spaced when we started our simulated trackers, we were able to see results in the billing console approximately 24 hours after each run. First was distance based filtering:
Figure 5. IoT Simulators
In this simulation, we had 17,235 positions written, but only 9,283 positions evaluated against a geofence. This is about 54% of total device updates evaluated against a geofence. We can further confirm our location position history storage by running a simple query in AWS Cloudshell which outputs all our device updates to a file.
Then we can use jq to find the length of the JSON object returned:
This returns 9,282 values which matches with our geofence evaluation. This confirms that many updates were ignored and not stored in our device history, nor evaluated against geofences.
Let’s take a look at accuracy filtering next. For the sake of simplicity, we will need to do some simple subtraction on our usage to get the usage by our resources tagged with Accuracy filtering.
Figure 6. Bill for accuracy based filtering
Subtracting the previous values provides values of 17,233 device positions written, and 9,779 Geofence evaluations. This is approximately 57% of our total device updates. If we run the same AWS CLI and jq command, we also receive 9,778 device updates stored. This confirms that many (43%) of our updates moved less than the accuracy value provided in the update and were therefore ignored by Amazon Location tracking.
Finally for our time based filtering, while it was ran over the same 24 hour period, we added an additional simulation that results in 11% more updates overall. Taking a look at our usage:
Figure 7. Bill for time based filtering
We can see we have 19,151 more device positions written, as well as 19,151 more geofence evaluations. Time based filtering evaluates every update against our geofence collection, however, it only stores if the update was greater than 30 seconds. Since we have different update times, every update was within 30 seconds of the last, and the tracker defaults to storage every 30 seconds. If we take a look at our device history we can see some examples of this:
In this example, because updates were coming in every 5 seconds as well as 45 seconds, it ignored most of them and only stored updates every 30 seconds. This results in 2,881 stored locations which is 15% of the total updates.
Analyzing the cost
Now that we’ve explored how many API calls we made, we can look at how these filtering updates effect cost. If we look at Cost Explorer we can filter by Amazon Location Service, and the BatchEvaluateGeofences API call. Grouping by tag we see the following:
Figure 7. Cost Explorer breaking down cost by filtering
The distance and accuracy filtering both had similar costs for geofencing evaluations, while the time based filtering had 70% higher costs, due to every device update being evaluated against a geofence.
Additional costs are associated with reading device position update histories. For example, Amazon Location Service paginates the results with a page size of 100 by default. Using distance filtering as an example, with 9,283 results, this results in 100 API calls to the GetDevicePositionHistory API in order to retrieve all simulated location values. Looking at our billing we can see we have 231 API calls, which matches up with 100 API calls for Accuracy and Distance filtering a piece, and 29 for the Time based filtering. There are some additional API calls included in that total from testing the procedures in this blog post.
Figure 9. Positions read
Performing your own tests
If you would like to replicate the results for yourself, you can utilize the IoT Device Simulator to simulate three different devices, as well as SAM to configure the Amazon Location Service resources, and associated AWS Lambda functions.
Deploying the Location Resources using SAM
As a prerequisite you should have the AWS SAM CLI configured to interact with your AWS account. The demo application can be found here. To build and deploy the app yourself, use the following commands:
When prompted, use the following options:
With this you will create the following infrastructure:
- 3 Trackers Created
- 3 Geofence Collections Created
- A Lambda Function that tags each tracker and geofence collection with the appropriate filtering tag.
- A geofence created in each geofence collection
Deploying the IoT Device Simulator
We will also deploy the IoT Device Simulator. Follow the directions linked to deploy the IoT Device Simulator into your account.
Cleanup
In order to remove our resources created by SAM, we simply run
And follow the prompts to remove the created infrastructure. To delete the IoT Device Simulator, follow the cleanup steps linked here
Summary
What these results demonstrate is how you can use filtering with Amazon Location Service to control costs associated with geofencing and device position storage. In this example, we only had one geofence per collection that was evaluated on each position update. If you have multiple geofences in a collection, each update is evaluated against all geofences and you will be charged for that single evaluation against the collection.
As we’ve shown, distance based filtering is ideal for customers that do not know the accuracy information of the device position updates. This filtering can help reduce geofence evaluation costs by ignoring jitter caused by small location updates. In our testing, the updates could have been very close to the previous update, or far away. Distance based filtering will only evaluate if the value was over 30 meters from the previous position. In our case, only 54% were more than 30 meters from the previous position, and thus evaluated.
Accuracy based filtering can be used when you know the accuracy of the device position updates and can provide the value during an update. In our testing, the accuracy was varied from 0-20 meters, along with our location being random. What this resulted in was 57% of updates where the position was moved more than the accuracy value from the previous position.
We also saw how time based updates evaluate geofence collections against every device position update, but only store every 30 seconds. If you have multiple geofence collections, this can become costly and you should choose time based if you have a small number of geofence collections linked to the tracker, or many geofences in a single geofence collection. This can be a useful filter where real-time geofence evaluations are important, but when you don’t care about storing device position history, or want to keep your device history retrieval costs to a minimum.
To learn more about Amazon Location Service Tracking, read our getting started guide.
About the authors: