One of the main pressures around response to incidents is simply being overwhelmed with tasks, the outcome of so many demands and so much context-switching can easily be chaos, or poor quality quick-fixes. As with all real-time response, the key thing is to take a step-back, and triage the incoming requests as they arrive, prioritising those we need to deal with first, and deferring those that we can tackle later.

We need to get security updates onto instances on live AWS services. So, whats the best strategy? If we’re using the Amazon Linux AMI, then we security updates are automatically applied on the initial boot of the AMI. So if we cycle our instances, we get a freshly updated EC2 instance.

The goal here is to implement an instance cycling task, resulting in all current instances being replaced with new instances with no downtime. When working with auto-scaling groups, its important to remember that the auto-scaling group is in control! Simply rebooting will most likely spook the scaling group into replacing the downed instance.

What are the key concepts that define what we mean by a sustainable service on AWS?

While we strive to deliver at pace there can be an over-confidence and a positioning of past policies and frameworks as being too rigid, of failing to allow the freedom with people to get on with their work.