6. Create Your Hypothesis
A well-defined hypothesis clarifies what you expect to happen when a fault is injected. To formulate it:- Identify the affected components
Pinpoint services, instances, or containers targeted by your fault injection. - Describe the expected behavior
Determine how your application should respond under fault conditions. - Define success metrics
Choose key indicators—latency, error rate, throughput—to validate resilience.
A precise hypothesis narrows your experiment’s scope and sets clear success criteria.
7. Design the Experiment
Use AWS FIS to control scope, duration, and safety checks. Configure the following:
These settings help you limit blast radius and maintain control throughout your test.
8. Run the Experiment
- Start in lower environments
Validate your hypothesis in development or staging before touching production.
Always begin in a non-production account or VPC to avoid unintended impact.
- Validate resilience
Monitor your application as the fault is injected. Check dashboards and alerts to ensure behavior aligns with your hypothesis. - Promote to production
Once confirmed, rerun the experiment against production workloads with the same configuration. - Mark success
A successful run demonstrates that your architecture can withstand the injected fault without violating SLAs.
9. Conduct a Post-Mortem
A structured post-mortem transforms insights into improvements:Maintain a blameless culture in your post-mortems to encourage transparent learning and innovation.
