AWS Fault Injection Simulator

Why it exists

Production failures are inevitable, yet most teams only discover resilience gaps during real customer-impacting incidents. Waiting for nature to break your system is slow and expensive. AWS Fault Injection Simulator was built to let engineers create real failure conditions on demand, so they can find and fix weak links before those weaknesses become outages.

The mental model

Think of FIS as a fire drill for your infrastructure. Instead of hoping your sprinklers work when a blaze starts, you trigger a small, controlled burn in a safe room and watch the response. You are not trying to cause damage; you are trying to confirm that your automated defenses, runbooks, and architecture actually behave the way your diagrams claim they do.

How it works

You build an experiment template that selects targets, such as EC2 instances, ECS tasks, EKS pods, or RDS clusters, and defines actions to inject against them. Actions include terminating instances, injecting latency or errors into API calls, failing over a database, or stressing CPU and memory. You attach stop conditions, usually CloudWatch alarms, that act as emergency brakes. If the alarm breaches during the experiment, FIS halts automatically. The service executes actions through AWS APIs using IAM roles, so it respects existing security boundaries and leaves no agents to install on your workloads.

When to use it

Use FIS when you have implemented automated recovery and want proof it works, not just code review approval. It is ideal before high-traffic events like product launches or sales, and it fits well into CI/CD pipelines for continuous resilience validation. It is especially powerful for testing Auto Scaling responses, multi-AZ failover, circuit breaker behavior, and alerting thresholds.

When not to use it

Do not use FIS in production if you lack observability, runbooks, or stop conditions, because an uncontrolled experiment becomes an unplanned outage. It is also not a substitute for load testing; FIS breaks components but does not generate user traffic. Avoid experimenting on resources you do not fully control or where you cannot contain the blast radius to a specific environment.

One canonical example

An e-commerce team runs a weekly FIS experiment in staging that randomly terminates thirty percent of EC2 instances in their checkout service. They set a stop condition tied to the checkout error rate alarm. The test confirms that the load balancer reroutes traffic, new instances launch within minutes, and the error rate stays below threshold. Once the pattern is proven, they promote the same template to production during low-traffic windows with tighter guardrails, giving them confidence that a real instance failure will not become a revenue loss event.