Thanks for the write up. A few thoughts: 1. Build a “live status” dashboard for your processing system so you can see the profile on the IPs or customers bein

Thanks for the write up. A few thoughts: 1. Build a “live status” dashboard for your processing system so you can see the profile on the IPs or customers being affected, so you have more visibility into the issue when it happens 2. Can you just put the system behind cloudfront and process CF log files instead of having to invoke lambdas? 3. Identify the affected customer and put their lambda results in a separate queue, to help limit blast radius if it happens again from other customers 4. Double check there wasn’t throttling because downstream services were throttling lambda (you mentioned SQS?) 5. Make your lambda even faster (if it’s 100ms make it 10ms or less); can you move your logic out of lambda? Can you instead of inserting into SQS log to cloudwatch and then read its data? Or ensure no cross region lambda <> SQS invocations, etc 6. Consider replacing lambda (that cannot batch process invocations) with app servers that can absorb and then batch send many requests to SQS (let them absorb and coalesce a large amount of requests into aggregate SQS messages at the edge); going a step further eg even uploading aggregated data files to S3 for later processing then put a single message on the SQS queue pointing to that file