Resilient and well-architected apps with chaos
summary
Covers using AWS Fault Injection Simulator to run concrete experiments against a single EC2 + RDS in one AZ app behind an ALB: stop/start a lone instance, observe outage, and find no existing alarms for user-facing failures. Adds a CloudWatch synthetic canary and then moves to an ASG with multiple EC2s; repeating the stop/start shows the ALB fails over and the app keeps serving. Shows exact actions, targets, stop conditions and that the remediation (canary + scaling) actually restores resilience.
AI-written summary · about
chapters (11)
- 0:00intro
- 0:22preamble
- 0:53agenda
- 1:13aws well-architected
- 1:58pillars of aws well-architected
- 4:00chaos engineering is...
- 4:49phases of chaos engineering
- 7:49aws fault injection simulator
- 8:53components
- 10:00scenario / demo
- 19:15summary
related talks
42mChaos Engineering: Why Breaking Things Should be Practiced
43mBest practices for continuous testing and observability
26mA proactive approach to resilience in modern apps
35mImprove resilience with automated chaos engineering
26mImprove application resilience with chaos engineering
29mImprove Resilience with automated chaos engineering
39mResilience & Chaos Engineering in the Cloud
57mChaos Engineering Primer