In this post we are explaining the proper replacement for the ISMS log-storm anti-pattern described in the previous post. We are identifying specific infrastructure aspects that need adjusting and we come up with a general rule that allows avoiding log storms in different implementations.

This post presents a problematic pattern that I encountered in the infrastructure of one of my clients. I am calling this pattern "log storm", simply because I haven't encountered a more appropriate name. In practice this architectural anti-pattern leads to the creation of unnecessary amount of log entries in a security system which in turn incurs unnecessary usage costs. It can probably be encountered in various platforms and setups, but in this post I am focusing on AWS-based set-up.