Running applications in production means maintaining an “always-on” posture through disruptions. Infrastructure fails; dependencies slow down, and networks partition, not as rare exceptions but as a normal condition of running at scale. Withstanding and recovering from those disruptions is a core requirement, not an afterthought.

In practice, that requirement shows up as a set of moments you may already know. A customer notices an outage, or a page fires, and the underlying cause could be any number of things: a GPU throwing hardware faults that fail the tasks on an instance, an Availability Zone having a networking event, or a logging backend you depend on slowing down and quietly dragging your application with it. None of this is unusual, and none of it waits for a convenient time. What matters is what happens next, and how much of it falls to you.

“Infrastructure fails; dependencies slow down, and networks partition, not as rare exceptions but as a normal condition of running at scale.”

On Amazon ECS, we aim to handle most of it for you. Failure recovery is a key consideration in how we design and build ECS features. That means you shouldn’t need to build your own detection loops and remediation runbooks for failures ECS can handle itself. For more ambiguous cases, where the right response depends on your workload, we expose the same controls so you can make that call yourself.

This builds on the resilience principles behind ECS that we covered in A deep dive into resilience and availability on Amazon ECS : static stability across Availability Zones, pre-scaling capacity, and isolating workloads.

Source link