Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Chaos engineering in Azure tests how your applications handle controlled failures before an outage exposes a resilience gap. Azure Chaos Studio applies fault injection to simulate disruptions such as resource unavailability or sudden load. Start with Chaos Studio Workspaces to discover resources and run Scenarios in a preproduction environment.
Azure Chaos Studio applies these principles as a managed service. Chaos Studio Workspaces is the current resource model. A Workspace discovers your resources and recommends Scenarios that simulate relevant outage patterns. Experiments (classic) is the legacy model for custom fault compositions that use targets and capabilities. To choose a model, see Choose between Chaos Studio Workspaces and Experiments (classic).
Why resilience testing matters
Distributed cloud applications depend on infrastructure, services, and networks that can fail independently. A disruption in one component can cascade into a system-wide incident if the application wasn't designed to tolerate it. Examples include a database failover, a DNS outage, or an availability zone going offline.
Resilience is a property of the whole system, not individual components. The only way to know whether your application survives a specific failure pattern is to test it under that condition. Chaos engineering provides a structured way to do this in preproduction and production environments.
How Chaos Studio applies chaos engineering
Chaos Studio injects faults against Azure resources in a controlled, time-bounded manner. In Chaos Studio Workspaces, a Scenario defines the Actions, affected resource types, and sequence for an outage pattern. In Experiments (classic), an experiment defines which faults run against which targets and whether they run in parallel or sequentially.
Many continuous faults are time-bounded and remove their temporary changes when the experiment ends. For example, a fault removes the network security group rules it added or restarts the resources it stopped. For Experiments (classic), verify cleanup behavior in the fault and action library.