Spooky action at a distance, how an AWS outage ate our load balancer

>Our SRE team relies heavily on Glitter – our trusty SRE chatbot – to assist us with many of our operational tasks, so under normal circumstances, it’d be a simple operation to disable these health checks in our Slack channel. However, things aren’t quite as straightforward as we’d expect, and the AWS outage has impacted Slack’s IRC gateway, which our chatbot relies on. This means we have to make all the necessary changes manually… Interesting example of how infrastructure can become tangled in a way that makes crisis management much harder.

Interesting!

I guess I've dealt enough with load balancers that as soon as I saw 'AWS network issues' and 'Many of our clients are hosted in AWS' I immediately jumped to the LB connection pool being full of mostly-dead connections, but this is an important lesson for anyone utilizing LBs. This is a very easy avenue to attack for bad actors, so setting strict timeouts and high connection limits (within reason vs. the capability of your load balancers) is important.

This, if done maliciously, is a valid DOS attack vector known as Slowloris/SlowPost attacks.

I know it’s easier said than done, but there should be active mitigation in place, rather than only monitoring.

Two sentence summary: Slow clients strangled our service. The slow clients were caused by an external AWS networking issue.

There is some kind of redirect loop going on here, can't read it at all.