We’re provisioning 2,000-3,000 new edge devices monthly into our Greengrass v2 deployment, and the device registration process is taking 8-12 hours to complete. Each device registration call to the Greengrass v2 device registry API is taking 2-4 seconds, which seems excessive.
Our current approach registers devices sequentially through a Python script that calls CreateDevice for each unit. We’re hitting API rate limiting intermittently (TooManyRequestsException), which forces us to back off and retry. The provisioning delay is creating a backlog where devices sit idle for days waiting to be activated in the field.
Looking for strategies to speed up bulk device registration in Greengrass v2. Are there API rate limiting considerations we should be aware of, or better patterns for parallelizing these requests without overwhelming the service?
We process 5k devices monthly. Key insight: batch your CreateDevice calls with exponential backoff when you hit rate limits. Use boto3’s built-in retry logic with custom config: config = Config(retries={'max_attempts': 10, 'mode': 'adaptive'}). This handles transient throttling gracefully. Also, consider if you really need individual device registration - can you use fleet provisioning templates instead?
Start with 8 parallel workers and monitor CloudWatch metrics for ThrottledRequests. If you see less than 5% throttle rate, gradually increase to 12-15 workers. The key is staying below the API’s burst capacity while maximizing throughput. Also, spread registration across multiple AWS regions if your deployment supports it - rate limits are per-region.
One more tip - use asynchronous I/O (asyncio) instead of threading if you’re on Python 3.7+. The GIL in Python threads can limit actual parallelism, while async gives you true concurrent API calls with better resource efficiency.