> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/aws.md).

# Chaos faults for AWS

### Introduction <a href="#introduction" id="introduction"></a>

AWS faults disrupt the resources running on different AWS services from the EKS cluster. To perform such AWS chaos experiments, you will need to authenticate CE with the AWS platform. This can be done in two ways.

* **Using secrets:** You can use secrets to authenticate CE with AWS regardless of whether the Kubernetes cluster is used for the deployment. This is Kubernetes' native way of authenticating CE with AWS.
* [**IAM integration:**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/security-configurations/aws-iam-integration.md) You can authenticate CE using AWS using IAM when you have deployed chaos on the EKS cluster. You can associate an IAM role with a Kubernetes service account. This service account can be used to provide AWS permissions to the experiment pod which uses the particular service account.

Here are AWS faults that you can execute and validate.

<table data-view="cards"><thead><tr><th></th><th></th><th><select multiple><option value="pxfKPnv3" label="availability" color="blue"></option><option value="b3TFjjiD" label="load balancer" color="blue"></option><option value="6F6ilsj6" label="zone" color="blue"></option><option value="AhXy8Ze2" label="blackhole" color="blue"></option><option value="tVSPIglV" label="vpc" color="blue"></option><option value="iNfUc_8a" label="route tables" color="blue"></option><option value="kf99QISl" label="replication" color="blue"></option><option value="2uzU1MDc" label="pause" color="blue"></option><option value="a2fun3Id" label="dynamodb" color="blue"></option><option value="sW8FHuNk" label="loss" color="blue"></option><option value="3SgJocwF" label="id" color="blue"></option><option value="f4AyxQxk" label="tag" color="blue"></option><option value="K4PQA8a6" label="cpu" color="blue"></option><option value="UeY_gIyH" label="stress" color="blue"></option><option value="HIE2qnIg" label="dns" color="blue"></option><option value="FXlzrmmq" label="http" color="blue"></option><option value="eJornFrm" label="latency" color="blue"></option><option value="Qb12NZt9" label="modify" color="blue"></option><option value="4d7Gjb3e" label="body" color="blue"></option><option value="fI0uA4c4" label="header" color="blue"></option><option value="f_HD3FTb" label="reset" color="blue"></option><option value="T6O7XjeF" label="peer" color="blue"></option><option value="6Xx0eIlh" label="status" color="blue"></option><option value="BWjP-MDi" label="code" color="blue"></option><option value="X_5N8Yfj" label="io" color="blue"></option><option value="sQsqm86N" label="memory" color="blue"></option><option value="xsK9fYiL" label="network" color="blue"></option><option value="kIe8f5f9" label="process" color="blue"></option><option value="hGIFpx2x" label="kill" color="blue"></option><option value="Y6Smuq0p" label="stop" color="blue"></option><option value="M629_ea4" label="agent" color="blue"></option><option value="l1Lganm0" label="container" color="blue"></option><option value="H1McG-VU" label="volume" color="blue"></option><option value="617EnvFw" label="detach" color="blue"></option><option value="ptr3Twf8" label="fargate" color="blue"></option><option value="ANRE-FQs" label="instance" color="blue"></option><option value="O4etzum9" label="invalid" color="blue"></option><option value="h7yp3Be4" label="image" color="blue"></option><option value="buMrGqt3" label="restrict" color="blue"></option><option value="uLXkGypK" label="task" color="blue"></option><option value="N_b6FyqE" label="scale" color="blue"></option><option value="fljtACQO" label="update" color="blue"></option><option value="wRWyp_OV" label="resource" color="blue"></option><option value="7_-JNbM1" label="timeout" color="blue"></option><option value="zEUZiZ_h" label="role" color="blue"></option><option value="czo3ZOHg" label="generic" color="blue"></option><option value="2FPVFLZb" label="template" color="blue"></option><option value="b6PFhtiR" label="fis" color="blue"></option><option value="j3CWTZE9" label="lambda" color="blue"></option><option value="ZwTb2s7B" label="tcp" color="blue"></option><option value="tvTvqZKm" label="block" color="blue"></option><option value="MwxcR5TT" label="delete" color="blue"></option><option value="O4D1J7we" label="source" color="blue"></option><option value="maBf6HmN" label="map" color="blue"></option><option value="1R2jnfGJ" label="concurrency" color="blue"></option><option value="mskzdusa" label="function" color="blue"></option><option value="15hZabH8" label="toggle" color="blue"></option><option value="z4JINyQI" label="runtime" color="blue"></option><option value="f9DaQEbA" label="status code" color="blue"></option><option value="AR_cPLKa" label="permission" color="blue"></option><option value="AwSbgEp7" label="reboot" color="blue"></option><option value="8ocCJXUR" label="access" color="blue"></option><option value="VyhPg46D" label="ssm" color="blue"></option><option value="kg1BdESq" label="windows" color="blue"></option><option value="uzVKAWZC" label="ec2" color="blue"></option></select></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>ALB AZ down</strong></td><td>ALB AZ down detaches one or more availability zones from an Application Load Balancer for a configurable duration so you can test how clients, target groups, and AZ-aware routing behave when a zone is taken out of the load balancer rotation.</td><td><span data-option="pxfKPnv3">availability, </span><span data-option="b3TFjjiD">load balancer</span></td><td><a href="#alb-az-down">#alb-az-down</a></td></tr><tr><td><strong>CLB AZ down</strong></td><td>CLB AZ down disables one or more availability zones on a Classic Load Balancer for a configurable duration so you can test how clients and back-end instances behave when an AZ is removed from the load balancer rotation.</td><td><span data-option="pxfKPnv3">availability, </span><span data-option="b3TFjjiD">load balancer</span></td><td><a href="#clb-az-down">#clb-az-down</a></td></tr><tr><td><strong>AZ blackhole</strong></td><td>AZ blackhole isolates network traffic in one or more AWS Availability Zones (optionally scoped to specific VPCs or subnets) for a configurable duration and restores connectivity afterwards, so you can test how multi-AZ workloads handle a zone-level outage.</td><td><span data-option="6F6ilsj6">zone, </span><span data-option="AhXy8Ze2">blackhole</span></td><td><a href="#az-blackhole">#az-blackhole</a></td></tr><tr><td><strong>VPC route misconfiguration</strong></td><td>VPC route misconfiguration temporarily removes specified CIDR routes from one or more VPC route tables for a configurable duration and restores them afterwards, so you can test how the workload behaves when egress to a Transit Gateway, NAT Gateway, VPC peer, or internet gateway disappears.</td><td><span data-option="tVSPIglV">vpc, </span><span data-option="iNfUc_8a">route tables</span></td><td><a href="#vpc-route-misconfiguration">#vpc-route-misconfiguration</a></td></tr><tr><td><strong>DynamoDB replication pause</strong></td><td>DynamoDB replication pause pauses cross-region replication on one or more Amazon DynamoDB global tables for a configurable duration using an AWS Fault Injection Service (FIS) experiment, so you can test how your application handles a brief stop in multi-region consistency.</td><td><span data-option="kf99QISl">replication, </span><span data-option="2uzU1MDc">pause, </span><span data-option="a2fun3Id">dynamodb</span></td><td><a href="#dynamodb-replication-pause">#dynamodb-replication-pause</a></td></tr><tr><td><strong>EBS loss by ID</strong></td><td>EBS loss by ID detaches an EBS volume by volume ID for a configurable duration and reattaches it afterwards, so you can test how a workload behaves when its storage disappears.</td><td><span data-option="sW8FHuNk">loss, </span><span data-option="3SgJocwF">id</span></td><td><a href="#ebs-loss-by-id">#ebs-loss-by-id</a></td></tr><tr><td><strong>EBS loss by tag</strong></td><td>EBS loss by tag detaches EBS volumes selected by tag for a configurable duration and reattaches them afterwards, so you can test how workloads behave when a tagged subset of storage disappears.</td><td><span data-option="sW8FHuNk">loss, </span><span data-option="f4AyxQxk">tag</span></td><td><a href="#ebs-loss-by-tag">#ebs-loss-by-tag</a></td></tr><tr><td><strong>EC2 CPU hog</strong></td><td>EC2 CPU hog stresses a configurable number of CPU cores at a configurable load percentage inside a target EC2 instance for a configurable duration, so you can test how the workload behaves when its host is CPU-starved.</td><td><span data-option="K4PQA8a6">cpu, </span><span data-option="UeY_gIyH">stress</span></td><td><a href="#ec2-cpu-hog">#ec2-cpu-hog</a></td></tr><tr><td><strong>EC2 DNS chaos</strong></td><td>EC2 DNS chaos fails DNS resolution for selected hostnames on a target EC2 instance for a configurable duration, so you can test how the workload reacts when a dependency cannot be resolved.</td><td><span data-option="HIE2qnIg">dns</span></td><td><a href="#ec2-dns-chaos">#ec2-dns-chaos</a></td></tr><tr><td><strong>EC2 HTTP latency</strong></td><td>EC2 HTTP latency adds latency to inbound HTTP traffic on a configurable port of a target EC2 instance for a configurable duration, so you can test how clients react when an HTTP service responds slowly.</td><td><span data-option="FXlzrmmq">http, </span><span data-option="eJornFrm">latency</span></td><td><a href="#ec2-http-latency">#ec2-http-latency</a></td></tr><tr><td><strong>EC2 HTTP modify body</strong></td><td>EC2 HTTP modify body rewrites HTTP response bodies on a configurable port of a target EC2 instance for a configurable duration, so you can test how clients react when an upstream returns unexpected content.</td><td><span data-option="FXlzrmmq">http, </span><span data-option="Qb12NZt9">modify, </span><span data-option="4d7Gjb3e">body</span></td><td><a href="#ec2-http-modify-body">#ec2-http-modify-body</a></td></tr><tr><td><strong>EC2 HTTP modify header</strong></td><td>EC2 HTTP modify header adds, changes, or removes HTTP headers on requests or responses on a configurable port of a target EC2 instance for a configurable duration, so you can test how clients and servers react when headers are missing or malformed.</td><td><span data-option="FXlzrmmq">http, </span><span data-option="Qb12NZt9">modify, </span><span data-option="fI0uA4c4">header</span></td><td><a href="#ec2-http-modify-header">#ec2-http-modify-header</a></td></tr><tr><td><strong>EC2 HTTP reset peer</strong></td><td>EC2 HTTP reset peer resets inbound TCP connections to an HTTP service on a configurable port of a target EC2 instance for a configurable duration, so you can test how clients react when the server tears down connections mid-flight.</td><td><span data-option="FXlzrmmq">http, </span><span data-option="f_HD3FTb">reset, </span><span data-option="T6O7XjeF">peer</span></td><td><a href="#ec2-http-reset-peer">#ec2-http-reset-peer</a></td></tr><tr><td><strong>EC2 HTTP status code</strong></td><td>EC2 HTTP status code rewrites HTTP response status codes on a configurable port of a target EC2 instance for a configurable duration, so you can test how clients react to specific error codes returned by an upstream service.</td><td><span data-option="FXlzrmmq">http, </span><span data-option="6Xx0eIlh">status, </span><span data-option="BWjP-MDi">code</span></td><td><a href="#ec2-http-status-code">#ec2-http-status-code</a></td></tr><tr><td><strong>EC2 IO stress</strong></td><td>EC2 IO stress generates sustained filesystem read and write load on a target EC2 instance for a configurable duration, so you can test how the workload behaves under disk pressure or near-full storage.</td><td><span data-option="X_5N8Yfj">io, </span><span data-option="UeY_gIyH">stress</span></td><td><a href="#ec2-io-stress">#ec2-io-stress</a></td></tr><tr><td><strong>EC2 memory hog</strong></td><td>EC2 memory hog consumes a configurable amount of memory inside a target EC2 instance for a configurable duration, so you can test how the workload behaves when its host is starved of memory.</td><td><span data-option="sQsqm86N">memory, </span><span data-option="UeY_gIyH">stress</span></td><td><a href="#ec2-memory-hog">#ec2-memory-hog</a></td></tr><tr><td><strong>EC2 network latency</strong></td><td>EC2 network latency adds configurable latency and jitter to outbound traffic on a target EC2 instance for a configurable duration, so you can test how the workload reacts when network round-trip times grow.</td><td><span data-option="xsK9fYiL">network, </span><span data-option="eJornFrm">latency</span></td><td><a href="#ec2-network-latency">#ec2-network-latency</a></td></tr><tr><td><strong>EC2 network loss</strong></td><td>EC2 network loss drops a configurable percentage of outbound packets on a target EC2 instance for a configurable duration, so you can test how the workload reacts when network reliability degrades.</td><td><span data-option="xsK9fYiL">network, </span><span data-option="sW8FHuNk">loss</span></td><td><a href="#ec2-network-loss">#ec2-network-loss</a></td></tr><tr><td><strong>EC2 process kill</strong></td><td>EC2 process kill kills one or more processes by PID inside a target EC2 instance for a configurable duration, so you can test how the workload recovers when a critical process disappears without losing the host.</td><td><span data-option="kIe8f5f9">process, </span><span data-option="hGIFpx2x">kill</span></td><td><a href="#ec2-process-kill">#ec2-process-kill</a></td></tr><tr><td><strong>EC2 stop by ID</strong></td><td>EC2 stop by ID stops one or more EC2 instances identified by their instance IDs for a configurable duration and then starts them again, so you can test how the workload behaves when a specific host disappears.</td><td><span data-option="Y6Smuq0p">stop, </span><span data-option="3SgJocwF">id</span></td><td><a href="#ec2-stop-by-id">#ec2-stop-by-id</a></td></tr><tr><td><strong>EC2 stop by tag</strong></td><td>EC2 stop by tag stops EC2 instances selected by tag for a configurable duration and starts them again afterwards, so you can test how a workload behaves when a tagged subset of capacity disappears.</td><td><span data-option="Y6Smuq0p">stop, </span><span data-option="f4AyxQxk">tag</span></td><td><a href="#ec2-stop-by-tag">#ec2-stop-by-tag</a></td></tr><tr><td><strong>ECS agent stop</strong></td><td>ECS agent stop halts the ECS agent on one or more EC2 container instances for a configurable duration so you can test how the ECS cluster behaves when the data-plane bridge between agent and control plane is interrupted.</td><td><span data-option="M629_ea4">agent, </span><span data-option="Y6Smuq0p">stop</span></td><td><a href="#ecs-agent-stop">#ecs-agent-stop</a></td></tr><tr><td><strong>ECS container CPU hog</strong></td><td>ECS container CPU hog stresses CPU inside containers of EC2-backed ECS tasks for a configurable duration so you can test how the application and the host behave under CPU saturation.</td><td><span data-option="l1Lganm0">container, </span><span data-option="K4PQA8a6">cpu, </span><span data-option="UeY_gIyH">stress</span></td><td><a href="#ecs-container-cpu-hog">#ecs-container-cpu-hog</a></td></tr><tr><td><strong>ECS container HTTP latency</strong></td><td>ECS container HTTP latency adds latency to inbound HTTP traffic on a configurable port of containers in an EC2-backed ECS task for a configurable duration so you can test how clients react when an HTTP service responds slowly.</td><td><span data-option="l1Lganm0">container, </span><span data-option="FXlzrmmq">http, </span><span data-option="eJornFrm">latency</span></td><td><a href="#ecs-container-http-latency">#ecs-container-http-latency</a></td></tr><tr><td><strong>ECS container HTTP modify body</strong></td><td>ECS container HTTP modify body rewrites HTTP response bodies on a configurable port of containers in an EC2-backed ECS task for a configurable duration so you can test how clients react when an upstream returns unexpected content.</td><td><span data-option="l1Lganm0">container, </span><span data-option="FXlzrmmq">http, </span><span data-option="Qb12NZt9">modify, </span><span data-option="4d7Gjb3e">body</span></td><td><a href="#ecs-container-http-modify-body">#ecs-container-http-modify-body</a></td></tr><tr><td><strong>ECS container HTTP reset peer</strong></td><td>ECS container HTTP reset peer resets inbound TCP connections to an HTTP service on a configurable port of containers in an EC2-backed ECS task for a configurable duration so you can test how clients react when the server tears down connections mid-flight.</td><td><span data-option="l1Lganm0">container, </span><span data-option="FXlzrmmq">http, </span><span data-option="f_HD3FTb">reset, </span><span data-option="T6O7XjeF">peer</span></td><td><a href="#ecs-container-http-reset-peer">#ecs-container-http-reset-peer</a></td></tr><tr><td><strong>ECS container HTTP status code</strong></td><td>ECS container HTTP status code rewrites HTTP response status codes on a configurable port of containers in an EC2-backed ECS task for a configurable duration so you can test how clients react to specific error codes returned by an upstream service.</td><td><span data-option="l1Lganm0">container, </span><span data-option="FXlzrmmq">http, </span><span data-option="6Xx0eIlh">status, </span><span data-option="BWjP-MDi">code</span></td><td><a href="#ecs-container-http-status-code">#ecs-container-http-status-code</a></td></tr><tr><td><strong>ECS container IO stress</strong></td><td>ECS container IO stress generates sustained filesystem read and write load inside containers of EC2-backed ECS tasks for a configurable duration so you can test how the workload behaves under disk pressure.</td><td><span data-option="l1Lganm0">container, </span><span data-option="X_5N8Yfj">io, </span><span data-option="UeY_gIyH">stress</span></td><td><a href="#ecs-container-io-stress">#ecs-container-io-stress</a></td></tr><tr><td><strong>ECS container memory hog</strong></td><td>ECS container memory hog consumes a configurable amount of memory inside containers of EC2-backed ECS tasks for a configurable duration so you can test how the workload behaves when its container is starved of memory.</td><td><span data-option="l1Lganm0">container, </span><span data-option="sQsqm86N">memory, </span><span data-option="UeY_gIyH">stress</span></td><td><a href="#ecs-container-memory-hog">#ecs-container-memory-hog</a></td></tr><tr><td><strong>ECS container network latency</strong></td><td>ECS container network latency adds configurable latency to outbound traffic from containers in EC2-backed ECS tasks for a configurable duration so you can test how the workload reacts when network round-trip times grow.</td><td><span data-option="l1Lganm0">container, </span><span data-option="xsK9fYiL">network, </span><span data-option="eJornFrm">latency</span></td><td><a href="#ecs-container-network-latency">#ecs-container-network-latency</a></td></tr><tr><td><strong>ECS container network loss</strong></td><td>ECS container network loss drops a configurable percentage of outbound packets from containers in EC2-backed ECS tasks for a configurable duration so you can test how the workload reacts when network reliability degrades.</td><td><span data-option="l1Lganm0">container, </span><span data-option="xsK9fYiL">network, </span><span data-option="sW8FHuNk">loss</span></td><td><a href="#ecs-container-network-loss">#ecs-container-network-loss</a></td></tr><tr><td><strong>ECS container volume detach</strong></td><td>ECS container volume detach detaches EBS volumes attached to ECS task containers for a configurable duration so you can test how stateful tasks behave when their storage disappears.</td><td><span data-option="l1Lganm0">container, </span><span data-option="H1McG-VU">volume, </span><span data-option="617EnvFw">detach</span></td><td><a href="#ecs-container-volume-detach">#ecs-container-volume-detach</a></td></tr><tr><td><strong>ECS Fargate CPU hog</strong></td><td>ECS Fargate CPU hog stresses CPU inside a Fargate task for a configurable duration so you can test how the application behaves when its task is CPU-starved.</td><td><span data-option="K4PQA8a6">cpu, </span><span data-option="UeY_gIyH">stress, </span><span data-option="ptr3Twf8">fargate</span></td><td><a href="#ecs-fargate-cpu-hog">#ecs-fargate-cpu-hog</a></td></tr><tr><td><strong>ECS Fargate memory hog</strong></td><td>ECS Fargate memory hog consumes a configurable amount of memory inside a Fargate task for a configurable duration so you can test how the application behaves when its task is starved of memory.</td><td><span data-option="sQsqm86N">memory, </span><span data-option="UeY_gIyH">stress, </span><span data-option="ptr3Twf8">fargate</span></td><td><a href="#ecs-fargate-memory-hog">#ecs-fargate-memory-hog</a></td></tr><tr><td><strong>ECS instance stop</strong></td><td>ECS instance stop stops one or more EC2 container instances belonging to an ECS cluster for a configurable duration so you can test how the cluster reschedules tasks and how the workload behaves when a host disappears.</td><td><span data-option="ANRE-FQs">instance, </span><span data-option="Y6Smuq0p">stop</span></td><td><a href="#ecs-instance-stop">#ecs-instance-stop</a></td></tr><tr><td><strong>ECS invalid container image</strong></td><td>ECS invalid container image swaps a container image to an invalid value on an ECS service for a configurable duration so you can test how the deployment, rollback, and monitoring react to a failing image pull.</td><td><span data-option="O4etzum9">invalid, </span><span data-option="l1Lganm0">container, </span><span data-option="h7yp3Be4">image</span></td><td><a href="#ecs-invalid-container-image">#ecs-invalid-container-image</a></td></tr><tr><td><strong>ECS network restrict</strong></td><td>ECS network restrict modifies the security group rules of an ECS service for a configurable duration so you can test how the workload behaves when outbound or inbound network access is restricted.</td><td><span data-option="xsK9fYiL">network, </span><span data-option="buMrGqt3">restrict</span></td><td><a href="#ecs-network-restrict">#ecs-network-restrict</a></td></tr><tr><td><strong>ECS task scale</strong></td><td>ECS task scale changes the desired count of an ECS service for a configurable duration so you can test how the workload behaves under sudden scale-up or scale-down.</td><td><span data-option="uLXkGypK">task, </span><span data-option="N_b6FyqE">scale</span></td><td><a href="#ecs-task-scale">#ecs-task-scale</a></td></tr><tr><td><strong>ECS task stop</strong></td><td>ECS task stop stops one or more ECS tasks (selected by service or task ID) for a configurable duration so you can test how the workload behaves when a specific task disappears.</td><td><span data-option="uLXkGypK">task, </span><span data-option="Y6Smuq0p">stop</span></td><td><a href="#ecs-task-stop">#ecs-task-stop</a></td></tr><tr><td><strong>ECS update container resource limit</strong></td><td>ECS update container resource limit re-registers an ECS task definition with reduced CPU or memory limits for a configurable duration so you can test how the workload behaves under tightened resource constraints.</td><td><span data-option="fljtACQO">update, </span><span data-option="l1Lganm0">container, </span><span data-option="wRWyp_OV">resource</span></td><td><a href="#ecs-update-container-resource-limit">#ecs-update-container-resource-limit</a></td></tr><tr><td><strong>ECS update container timeout</strong></td><td>ECS update container timeout re-registers an ECS task definition with modified start and stop timeouts for a configurable duration so you can test how the deployment behaves when container start or stop takes longer than expected.</td><td><span data-option="fljtACQO">update, </span><span data-option="l1Lganm0">container, </span><span data-option="7_-JNbM1">timeout</span></td><td><a href="#ecs-update-container-timeout">#ecs-update-container-timeout</a></td></tr><tr><td><strong>ECS update task role</strong></td><td>ECS update task role swaps the IAM task role on an ECS service for a configurable duration so you can test how the workload behaves when its IAM permissions change.</td><td><span data-option="uLXkGypK">task, </span><span data-option="zEUZiZ_h">role</span></td><td><a href="#ecs-update-task-role">#ecs-update-task-role</a></td></tr><tr><td><strong>Generic experiment template</strong></td><td>Generic experiment template starts a pre-existing AWS Fault Injection Service (FIS) template by ID, so you can fold native AWS-managed faults into a Harness chaos experiment and probe, verify, and report on the result as you do with any other Harness fault.</td><td><span data-option="czo3ZOHg">generic, </span><span data-option="2FPVFLZb">template, </span><span data-option="b6PFhtiR">fis</span></td><td><a href="#generic-experiment-template">#generic-experiment-template</a></td></tr><tr><td><strong>Lambda block TCP connection</strong></td><td>Lambda block TCP connection blocks outbound TCP connections from an AWS Lambda function to one or more target hostnames for a configurable duration, so you can test how the function behaves when a TCP-based dependency is unreachable.</td><td><span data-option="j3CWTZE9">lambda, </span><span data-option="ZwTb2s7B">tcp, </span><span data-option="xsK9fYiL">network, </span><span data-option="tvTvqZKm">block</span></td><td><a href="#lambda-block-tcp-connection">#lambda-block-tcp-connection</a></td></tr><tr><td><strong>Lambda delete event source mapping</strong></td><td>Lambda delete event source mapping deletes one or more event source mappings on an AWS Lambda function for a configurable duration and recreates them afterwards, so you can test how the workload behaves when the function stops receiving events from its source.</td><td><span data-option="j3CWTZE9">lambda, </span><span data-option="MwxcR5TT">delete, </span><span data-option="O4D1J7we">source, </span><span data-option="maBf6HmN">map</span></td><td><a href="#lambda-delete-event-source-mapping">#lambda-delete-event-source-mapping</a></td></tr><tr><td><strong>Lambda delete function concurrency</strong></td><td>Lambda delete function concurrency deletes the reserved concurrency configuration on an AWS Lambda function for a configurable duration and restores it afterwards, so you can test how the workload behaves when the function has to share account-level concurrency with other functions.</td><td><span data-option="j3CWTZE9">lambda, </span><span data-option="MwxcR5TT">delete, </span><span data-option="1R2jnfGJ">concurrency</span></td><td><a href="#lambda-delete-function-concurrency">#lambda-delete-function-concurrency</a></td></tr><tr><td><strong>Lambda function layer detach</strong></td><td>Lambda function layer detach detaches a specified Lambda layer from a target AWS Lambda function for a configurable duration and reattaches it afterwards, so you can test how the workload behaves when a shared dependency layer disappears.</td><td><span data-option="j3CWTZE9">lambda, </span><span data-option="617EnvFw">detach, </span><span data-option="mskzdusa">function</span></td><td><a href="#lambda-function-layer-detach">#lambda-function-layer-detach</a></td></tr><tr><td><strong>Lambda inject latency</strong></td><td>Lambda inject latency adds a configurable amount of latency to every invocation of an AWS Lambda function for a configurable duration, so you can test how upstream callers and downstream consumers handle slower-than-expected responses, cold-start spikes, and resource contention.</td><td><span data-option="j3CWTZE9">lambda, </span><span data-option="eJornFrm">latency, </span><span data-option="xsK9fYiL">network</span></td><td><a href="#lambda-inject-latency">#lambda-inject-latency</a></td></tr><tr><td><strong>Lambda toggle event mapping state</strong></td><td>Lambda toggle event mapping state disables one or more event source mappings on an AWS Lambda function for a configurable duration and re-enables them afterwards, so you can test how the workload behaves when the function temporarily stops receiving events from its source.</td><td><span data-option="j3CWTZE9">lambda, </span><span data-option="15hZabH8">toggle, </span><span data-option="maBf6HmN">map</span></td><td><a href="#lambda-toggle-event-mapping-state">#lambda-toggle-event-mapping-state</a></td></tr><tr><td><strong>Lambda update function memory</strong></td><td>Lambda update function memory lowers the memory allocation of an AWS Lambda function for a configurable duration and restores it afterwards, so you can test how the workload behaves with less memory and a proportionally smaller CPU share.</td><td><span data-option="j3CWTZE9">lambda, </span><span data-option="mskzdusa">function, </span><span data-option="sQsqm86N">memory</span></td><td><a href="#lambda-update-function-memory">#lambda-update-function-memory</a></td></tr><tr><td><strong>Lambda update function timeout</strong></td><td>Lambda update function timeout lowers the configured timeout of an AWS Lambda function for a configurable duration and restores it afterwards, so you can test how the workload behaves when invocations are cut short.</td><td><span data-option="j3CWTZE9">lambda, </span><span data-option="7_-JNbM1">timeout, </span><span data-option="fljtACQO">update</span></td><td><a href="#lambda-update-function-timeout">#lambda-update-function-timeout</a></td></tr><tr><td><strong>Lambda inject status code</strong></td><td>Lambda inject status code overrides the HTTP status code returned by an AWS Lambda function for a configurable duration, so you can test how upstream callers and downstream consumers handle unexpected error status responses.</td><td><span data-option="j3CWTZE9">lambda, </span><span data-option="z4JINyQI">runtime, </span><span data-option="f9DaQEbA">status code</span></td><td><a href="#lambda-inject-status-code">#lambda-inject-status-code</a></td></tr><tr><td><strong>Lambda update role permission</strong></td><td>Lambda update role permission detaches a specified IAM policy from the execution role attached to an AWS Lambda function for a configurable duration and reattaches it afterwards, so you can test how the workload behaves when the function loses permission to call a downstream AWS service.</td><td><span data-option="j3CWTZE9">lambda, </span><span data-option="zEUZiZ_h">role, </span><span data-option="AR_cPLKa">permission</span></td><td><a href="#lambda-update-role-permission">#lambda-update-role-permission</a></td></tr><tr><td><strong>Lambda modify response body</strong></td><td>Lambda modify response body overrides the response body returned by an AWS Lambda function for a configurable duration, so you can test how upstream callers and client applications handle unexpected payload shapes and corrupted data.</td><td><span data-option="j3CWTZE9">lambda, </span><span data-option="z4JINyQI">runtime, </span><span data-option="mskzdusa">function</span></td><td><a href="#lambda-modify-response-body">#lambda-modify-response-body</a></td></tr><tr><td><strong>NLB AZ down</strong></td><td>NLB AZ down detaches one or more availability zones from a Network Load Balancer for a configurable duration so you can test how clients, target groups, and AZ-aware routing behave when a zone is taken out of the load balancer rotation.</td><td><span data-option="b3TFjjiD">load balancer, </span><span data-option="pxfKPnv3">availability</span></td><td><a href="#nlb-az-down">#nlb-az-down</a></td></tr><tr><td><strong>RDS instance delete</strong></td><td>RDS instance delete deletes a target RDS DB instance, so you can test how applications behave when a database disappears permanently and how disaster-recovery procedures handle the loss.</td><td><span data-option="ANRE-FQs">instance, </span><span data-option="MwxcR5TT">delete</span></td><td><a href="#rds-instance-delete">#rds-instance-delete</a></td></tr><tr><td><strong>RDS instance reboot</strong></td><td>RDS instance reboot reboots a target RDS DB instance (with optional Multi-AZ failover) for a configurable duration, so you can test how applications behave when their database restarts.</td><td><span data-option="ANRE-FQs">instance, </span><span data-option="AwSbgEp7">reboot</span></td><td><a href="#rds-instance-reboot">#rds-instance-reboot</a></td></tr><tr><td><strong>Resource access restrict</strong></td><td>Resource access restrict temporarily strips ingress or egress rules from one or more AWS security groups for a configurable duration and restores them afterwards, so you can test how the workload behaves when network access to (or from) an AWS resource disappears.</td><td><span data-option="wRWyp_OV">resource, </span><span data-option="8ocCJXUR">access, </span><span data-option="buMrGqt3">restrict</span></td><td><a href="#resource-access-restrict">#resource-access-restrict</a></td></tr><tr><td><strong>SSM chaos by ID</strong></td><td>SSM chaos by ID runs an arbitrary AWS Systems Manager document against a target EC2 instance selected by ID, so you can inject custom chaos that is not covered by a dedicated fault.</td><td><span data-option="VyhPg46D">ssm, </span><span data-option="3SgJocwF">id</span></td><td><a href="#ssm-chaos-by-id">#ssm-chaos-by-id</a></td></tr><tr><td><strong>SSM chaos by tag</strong></td><td>SSM chaos by tag runs an arbitrary AWS Systems Manager document against EC2 instances selected by tag, so you can inject custom chaos against a logical group of hosts.</td><td><span data-option="VyhPg46D">ssm, </span><span data-option="f4AyxQxk">tag</span></td><td><a href="#ssm-chaos-by-tag">#ssm-chaos-by-tag</a></td></tr><tr><td><strong>Windows EC2 blackhole chaos</strong></td><td>Windows EC2 blackhole chaos drops all network traffic destined for specific IPs or hosts on one or more Windows EC2 instances for a configurable duration so you can test how Windows-hosted workloads behave when a specific dependency is completely unreachable.</td><td><span data-option="kg1BdESq">windows, </span><span data-option="AhXy8Ze2">blackhole, </span><span data-option="xsK9fYiL">network</span></td><td><a href="#windows-ec2-blackhole-chaos">#windows-ec2-blackhole-chaos</a></td></tr><tr><td><strong>Windows EC2 CPU hog</strong></td><td>Windows EC2 CPU hog stresses a configurable number of CPU cores at a configurable load percentage inside one or more Windows EC2 instances for a configurable duration so you can test how Windows-hosted workloads behave when their host is CPU-starved.</td><td><span data-option="K4PQA8a6">cpu, </span><span data-option="UeY_gIyH">stress, </span><span data-option="kg1BdESq">windows</span></td><td><a href="#windows-ec2-cpu-hog">#windows-ec2-cpu-hog</a></td></tr><tr><td><strong>Windows EC2 memory hog</strong></td><td>Windows EC2 memory hog consumes a configurable amount of memory inside one or more Windows EC2 instances for a configurable duration so you can test how Windows-hosted workloads behave when their host is starved of memory.</td><td><span data-option="sQsqm86N">memory, </span><span data-option="UeY_gIyH">stress, </span><span data-option="kg1BdESq">windows</span></td><td><a href="#windows-ec2-memory-hog">#windows-ec2-memory-hog</a></td></tr><tr><td><strong>Windows EC2 network latency</strong></td><td>Windows EC2 network latency adds a configurable amount of latency to network traffic destined for specific IPs or hosts on one or more Windows EC2 instances for a configurable duration so you can test how Windows-hosted workloads behave when the network is slow.</td><td><span data-option="xsK9fYiL">network, </span><span data-option="eJornFrm">latency, </span><span data-option="kg1BdESq">windows</span></td><td><a href="#windows-ec2-network-latency">#windows-ec2-network-latency</a></td></tr><tr><td><strong>Windows EC2 network loss</strong></td><td>Windows EC2 network loss drops a configurable percentage of network packets destined for specific IPs or hosts on one or more Windows EC2 instances for a configurable duration so you can test how Windows-hosted workloads behave when the network is lossy.</td><td><span data-option="xsK9fYiL">network, </span><span data-option="sW8FHuNk">loss, </span><span data-option="kg1BdESq">windows</span></td><td><a href="#windows-ec2-network-loss">#windows-ec2-network-loss</a></td></tr><tr><td><strong>Windows EC2 process kill</strong></td><td>Windows EC2 process kill kills one or more processes (selected by PID or process name) on one or more Windows EC2 instances for a configurable duration so you can test how Windows-hosted workloads behave when their backing processes die.</td><td><span data-option="kIe8f5f9">process, </span><span data-option="hGIFpx2x">kill, </span><span data-option="kg1BdESq">windows, </span><span data-option="uzVKAWZC">ec2</span></td><td><a href="#windows-ec2-process-kill">#windows-ec2-process-kill</a></td></tr></tbody></table>

#### ALB AZ down <a href="#alb-az-down" id="alb-az-down"></a>

ALB AZ down detaches one or more availability zones from an Application Load Balancer for a configurable duration, then reattaches them, so you can test how multi-AZ workloads behave when a single AZ disappears from the load balancer rotation.

<details>

<summary>Use cases</summary>

* Validate AZ-level resilience and DNS-based client failover within the TTL budget.
* Confirm remaining AZs absorb redirected traffic without breaching latency SLOs.
* Verify cross-zone load balancing behavior and target group re-registration after recovery.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/alb-az-down.md" class="button primary">View details</a>

#### CLB AZ down <a href="#clb-az-down" id="clb-az-down"></a>

CLB AZ down disables one or more availability zones on a Classic Load Balancer for a configurable duration, then re-enables them, so you can test how multi-AZ workloads behave when an AZ disappears from a CLB.

<details>

<summary>Use cases</summary>

* Validate AZ-level resilience and DNS-based client failover.
* Confirm `N-1` AZ capacity is sufficient on the remaining AZs.
* Verify instances re-register cleanly when the AZ returns.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/clb-az-down.md" class="button primary">View details</a>

#### AZ blackhole <a href="#az-blackhole" id="az-blackhole"></a>

AZ blackhole isolates network traffic in one or more AWS Availability Zones (optionally scoped to specific VPCs or subnets) for a configurable duration and restores connectivity afterwards, so you can test how multi-AZ workloads handle a zone-level outage.

<details>

<summary>Use cases</summary>

* Validate ALB / NLB failover to remaining zones when an AZ goes dark.
* Confirm Multi-AZ databases (RDS, ElastiCache, OpenSearch, MSK) survive a single-AZ blackhole without data loss.
* Rehearse Auto Scaling and disaster-recovery automation under a zone-level outage.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/az-blackhole.md" class="button primary">View details</a>

#### VPC route misconfiguration <a href="#vpc-route-misconfiguration" id="vpc-route-misconfiguration"></a>

VPC route misconfiguration temporarily removes specified CIDR routes from one or more VPC route tables for a configurable duration and restores them afterwards, so you can test how the workload behaves when egress to a Transit Gateway, NAT Gateway, VPC peer, or internet gateway disappears.

<details>

<summary>Use cases</summary>

* Detect blast radius of a future change to a VPC route table before rolling it out.
* Validate clean error handling when egress to a TGW / NAT Gateway / peer is broken.
* Confirm alarms on NAT bytes or TGW packet drops fire within the SLA.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/vpc-route-misconfiguration.md" class="button primary">View details</a>

#### DynamoDB replication pause <a href="#dynamodb-replication-pause" id="dynamodb-replication-pause"></a>

DynamoDB replication pause pauses cross-region replication on one or more Amazon DynamoDB global tables for a configurable duration using an AWS Fault Injection Service (FIS) experiment, so you can test how your application handles a brief stop in multi-region consistency.

<details>

<summary>Use cases</summary>

* Validate eventual-consistency tolerance when replication latency spikes.
* Confirm cross-region failover automation does not misfire on a temporary replication pause.
* Rehearse global-table catch-up after a multi-region replication gap.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/dynamodb-replication-pause.md" class="button primary">View details</a>

#### EBS loss by ID <a href="#ebs-loss-by-id" id="ebs-loss-by-id"></a>

EBS loss by ID detaches an EBS volume by volume ID for a configurable duration and reattaches it afterwards, so you can test how a workload behaves when its storage disappears.

<details>

<summary>Use cases</summary>

* Validate clean IO-error handling and database failover when the data volume disappears.
* Confirm the workload reconnects cleanly when the volume is reattached.
* Rehearse disaster-recovery procedures for missing-volume scenarios.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ebs-loss-by-id.md" class="button primary">View details</a>

#### EBS loss by tag <a href="#ebs-loss-by-tag" id="ebs-loss-by-tag"></a>

EBS loss by tag detaches EBS volumes selected by tag for a configurable duration and reattaches them afterwards, so you can test how workloads behave when a tagged subset of storage disappears.

<details>

<summary>Use cases</summary>

* Validate replica absorption and stateful-workload failover when a tagged subset of storage disappears.
* Confirm `VOLUME_AFFECTED_PERC` keeps the impact within the planned blast radius.
* Rehearse the recovery procedure for losing a tagged subset of storage.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ebs-loss-by-tag.md" class="button primary">View details</a>

#### EC2 CPU hog <a href="#ec2-cpu-hog" id="ec2-cpu-hog"></a>

EC2 CPU hog stresses a configurable number of CPU cores at a configurable load percentage inside a target EC2 instance for a configurable duration, so you can test how the workload behaves when its host is CPU-starved.

<details>

<summary>Use cases</summary>

* Validate p99 latency stays within SLO when all cores are saturated.
* Confirm CloudWatch CPU alarms and ASG scale-out trigger in the expected window.
* Test burst-credit exhaustion on T-family instances and co-tenant isolation.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-cpu-hog.md" class="button primary">View details</a>

#### EC2 DNS chaos <a href="#ec2-dns-chaos" id="ec2-dns-chaos"></a>

EC2 DNS chaos fails DNS resolution for selected hostnames on a target EC2 instance for a configurable duration, so you can test how the workload reacts when a dependency cannot be resolved.

<details>

<summary>Use cases</summary>

* Validate clean error handling when a critical dependency cannot be resolved.
* Confirm resolver retry semantics back off correctly instead of amplifying load.
* Test multi-target outages and observability coverage of DNS failures.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-dns-chaos.md" class="button primary">View details</a>

#### EC2 HTTP latency <a href="#ec2-http-latency" id="ec2-http-latency"></a>

EC2 HTTP latency adds latency to inbound HTTP traffic on a configurable port of a target EC2 instance for a configurable duration, so you can test how clients react when an HTTP service responds slowly.

<details>

<summary>Use cases</summary>

* Validate client timeouts and retry-with-backoff paths under HTTP slowness.
* Confirm connection pools absorb added latency without exhausting.
* Test load-balancer behaviour and end-to-end SLO impact across the call graph.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-http-latency.md" class="button primary">View details</a>

#### EC2 HTTP modify body <a href="#ec2-http-modify-body" id="ec2-http-modify-body"></a>

EC2 HTTP modify body rewrites HTTP response bodies on a configurable port of a target EC2 instance for a configurable duration, so you can test how clients react when an upstream returns unexpected content.

<details>

<summary>Use cases</summary>

* Validate schema-validation and parse-error paths in clients.
* Test empty-response and truncated-payload handling.
* Confirm UX degrades gracefully when the API returns unexpected content.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-http-modify-body.md" class="button primary">View details</a>

#### EC2 HTTP modify header <a href="#ec2-http-modify-header" id="ec2-http-modify-header"></a>

EC2 HTTP modify header adds, changes, or removes HTTP headers on requests or responses on a configurable port of a target EC2 instance for a configurable duration, so you can test how clients and servers react when headers are missing or malformed.

<details>

<summary>Use cases</summary>

* Validate auth-failure paths when `Authorization` is stripped from requests.
* Test cache-control and CORS-header changes against downstream caches and browser clients.
* Confirm tracing-header propagation breaks (or recovers) exactly where expected.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-http-modify-header.md" class="button primary">View details</a>

#### EC2 HTTP reset peer <a href="#ec2-http-reset-peer" id="ec2-http-reset-peer"></a>

EC2 HTTP reset peer resets inbound TCP connections to an HTTP service on a configurable port of a target EC2 instance for a configurable duration, so you can test how clients react when the server tears down connections mid-flight.

<details>

<summary>Use cases</summary>

* Validate client-side retry safety when connections are reset before the response arrives.
* Test HTTP connection-pool recovery after a churn event.
* Confirm load-balancer detection and observability of TCP resets.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-http-reset-peer.md" class="button primary">View details</a>

#### EC2 HTTP status code <a href="#ec2-http-status-code" id="ec2-http-status-code"></a>

EC2 HTTP status code rewrites HTTP response status codes on a configurable port of a target EC2 instance for a configurable duration, so you can test how clients react to specific error codes returned by an upstream service.

<details>

<summary>Use cases</summary>

* Validate 4xx vs 5xx semantics: clients refrain from retrying 4xx but retry 5xx with backoff.
* Test `429` handling, circuit-breaker open/close behaviour, and cache fallback on `502`.
* Confirm auth-failure (`401`/`403`) paths refresh tokens cleanly.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-http-status-code.md" class="button primary">View details</a>

#### EC2 IO stress <a href="#ec2-io-stress" id="ec2-io-stress"></a>

EC2 IO stress generates sustained filesystem read and write load on a target EC2 instance for a configurable duration, so you can test how the workload behaves under disk pressure or near-full storage.

<details>

<summary>Use cases</summary>

* Validate disk-bound latency and write-error handling under saturation.
* Test near-full disk behaviour and WAL flush stalls for databases.
* Confirm EKS `ephemeral-storage` limits evict pods as expected.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-io-stress.md" class="button primary">View details</a>

#### EC2 memory hog <a href="#ec2-memory-hog" id="ec2-memory-hog"></a>

EC2 memory hog consumes a configurable amount of memory inside a target EC2 instance for a configurable duration, so you can test how the workload behaves when its host is starved of memory.

<details>

<summary>Use cases</summary>

* Validate OOM-killer victim selection lands on the right process.
* Test JVM heap pressure, container memory limits, and pod restarts on EKS.
* Confirm CloudWatch memory alarms trigger ASG scale-out in time.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-memory-hog.md" class="button primary">View details</a>

#### EC2 network latency <a href="#ec2-network-latency" id="ec2-network-latency"></a>

EC2 network latency adds configurable latency and jitter to outbound traffic on a target EC2 instance for a configurable duration, so you can test how the workload reacts when network round-trip times grow.

<details>

<summary>Use cases</summary>

* Validate cross-AZ latency tolerance and database-call timeouts.
* Test connection-pool resilience and retry-storm protection under added latency.
* Confirm SLO error budgets burn at the expected rate when latency is injected.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-network-latency.md" class="button primary">View details</a>

#### EC2 network loss <a href="#ec2-network-loss" id="ec2-network-loss"></a>

EC2 network loss drops a configurable percentage of outbound packets on a target EC2 instance for a configurable duration, so you can test how the workload reacts when network reliability degrades.

<details>

<summary>Use cases</summary>

* Validate partial-loss tolerance and 100%-loss failover behaviour.
* Test TCP retransmission cost and replica failover under packet loss.
* Confirm loss surfaces in network metrics (`tcp_retransmits`) and alerts.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-network-loss.md" class="button primary">View details</a>

#### EC2 process kill <a href="#ec2-process-kill" id="ec2-process-kill"></a>

EC2 process kill kills one or more processes by PID inside a target EC2 instance for a configurable duration, so you can test how the workload recovers when a critical process disappears without losing the host.

<details>

<summary>Use cases</summary>

* Validate supervisor (systemd, container runtime) restart cadence.
* Test crash vs graceful-shutdown semantics by toggling `FORCE` between SIGTERM and SIGKILL.
* Confirm liveness probes detect the failure and trigger restarts cleanly.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-process-kill.md" class="button primary">View details</a>

#### EC2 stop by ID <a href="#ec2-stop-by-id" id="ec2-stop-by-id"></a>

EC2 stop by ID stops one or more EC2 instances identified by their instance IDs for a configurable duration and then starts them again, so you can test how the workload behaves when a specific host disappears. When `MANAGED_NODEGROUP=enable`, the fault waits for a replacement node from the auto-scaling group instead of starting the original instance.

<details>

<summary>Use cases</summary>

* Validate replica failover when an instance hosting a workload is stopped.
* Confirm load balancer health checks detach and reattach the instance cleanly.
* Test auto-scaling group response and EKS managed node group recovery.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-stop-by-id.md" class="button primary">View details</a>

#### EC2 stop by tag <a href="#ec2-stop-by-tag" id="ec2-stop-by-tag"></a>

EC2 stop by tag stops EC2 instances selected by tag for a configurable duration and starts them again afterwards, so you can test how a workload behaves when a tagged subset of capacity disappears.

<details>

<summary>Use cases</summary>

* Validate replica failover for a tagged tier and load-balancer detach/reattach.
* Confirm auto-scaling group response and EKS managed-node-group recovery (`MANAGED_NODEGROUP=enable`).
* Verify `INSTANCE_AFFECTED_PERCENTAGE` keeps the blast radius within plan.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-stop-by-tag.md" class="button primary">View details</a>

#### ECS agent stop <a href="#ecs-agent-stop" id="ecs-agent-stop"></a>

ECS agent stop halts the ECS agent on one or more EC2 container instances belonging to an ECS cluster for a configurable duration, so you can test how the cluster behaves when the data-plane bridge between agent and control plane is interrupted.

<details>

<summary>Use cases</summary>

* Validate that running tasks continue to serve traffic while the agent is offline.
* Confirm the cluster detects the disconnected instance and that the agent recovers cleanly.
* Test that new task placements skip the affected instance until the agent reconnects.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-agent-stop.md" class="button primary">View details</a>

#### ECS container CPU hog <a href="#ecs-container-cpu-hog" id="ecs-container-cpu-hog"></a>

ECS container CPU hog stresses CPU inside containers of EC2-backed ECS tasks for a configurable duration, so you can test how the application and the host behave under CPU saturation.

<details>

<summary>Use cases</summary>

* Validate p99 latency stays within SLO when containers are CPU-starved.
* Confirm CloudWatch CPU alarms and service autoscaling trigger in the expected window.
* Test noisy-neighbour isolation across containers on the same host.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-cpu-hog.md" class="button primary">View details</a>

#### ECS container HTTP latency <a href="#ecs-container-http-latency" id="ecs-container-http-latency"></a>

ECS container HTTP latency adds latency to inbound HTTP traffic on a configurable port of containers in an EC2-backed ECS task for a configurable duration, so you can test how clients react when an HTTP service responds slowly.

<details>

<summary>Use cases</summary>

* Validate client timeouts and retry-with-backoff paths under HTTP slowness.
* Confirm connection pools absorb added latency without exhausting.
* Test load-balancer behaviour and end-to-end SLO impact across the call graph.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-http-latency.md" class="button primary">View details</a>

#### ECS container HTTP modify body <a href="#ecs-container-http-modify-body" id="ecs-container-http-modify-body"></a>

ECS container HTTP modify body rewrites HTTP response bodies on a configurable port of containers in an EC2-backed ECS task for a configurable duration, so you can test how clients react when an upstream returns unexpected content.

<details>

<summary>Use cases</summary>

* Validate schema-validation and parse-error paths in clients.
* Test empty-response and truncated-payload handling.
* Confirm UX degrades gracefully when the API returns unexpected content.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-http-modify-body.md" class="button primary">View details</a>

#### ECS container HTTP reset peer <a href="#ecs-container-http-reset-peer" id="ecs-container-http-reset-peer"></a>

ECS container HTTP reset peer resets inbound TCP connections to an HTTP service on a configurable port of containers in an EC2-backed ECS task for a configurable duration, so you can test how clients react when the server tears down connections mid-flight.

<details>

<summary>Use cases</summary>

* Validate client-side retry safety when connections are reset before the response arrives.
* Test HTTP connection-pool recovery after a churn event.
* Confirm load-balancer detection and observability of TCP resets.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-http-reset-peer.md" class="button primary">View details</a>

#### ECS container HTTP status code <a href="#ecs-container-http-status-code" id="ecs-container-http-status-code"></a>

ECS container HTTP status code rewrites HTTP response status codes on a configurable port of containers in an EC2-backed ECS task for a configurable duration, so you can test how clients react to specific error codes returned by an upstream service.

<details>

<summary>Use cases</summary>

* Validate 4xx vs 5xx semantics: clients refrain from retrying 4xx but retry 5xx with backoff.
* Test `429` handling, circuit-breaker open/close behaviour, and cache fallback on `502`.
* Confirm auth-failure (`401`/`403`) paths refresh tokens cleanly.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-http-status-code.md" class="button primary">View details</a>

#### ECS container IO stress <a href="#ecs-container-io-stress" id="ecs-container-io-stress"></a>

ECS container IO stress generates sustained filesystem read and write load inside containers of EC2-backed ECS tasks for a configurable duration, so you can test how the workload behaves under disk pressure.

<details>

<summary>Use cases</summary>

* Validate disk-bound latency and write-error handling under saturation.
* Test near-full disk behaviour and WAL flush stalls for stateful workloads.
* Confirm ephemeral-storage limits behave as expected when IO load is sustained.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-io-stress.md" class="button primary">View details</a>

#### ECS container memory hog <a href="#ecs-container-memory-hog" id="ecs-container-memory-hog"></a>

ECS container memory hog consumes a configurable amount of memory inside containers of EC2-backed ECS tasks for a configurable duration, so you can test how the workload behaves when its container is starved of memory.

<details>

<summary>Use cases</summary>

* Validate OOM-killer victim selection lands on the right process.
* Test JVM heap pressure and container memory limits.
* Confirm CloudWatch memory alarms trigger service autoscaling in time.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-memory-hog.md" class="button primary">View details</a>

#### ECS container network latency <a href="#ecs-container-network-latency" id="ecs-container-network-latency"></a>

ECS container network latency adds configurable latency to outbound traffic from containers in EC2-backed ECS tasks for a configurable duration, so you can test how the workload reacts when network round-trip times grow.

<details>

<summary>Use cases</summary>

* Validate cross-AZ latency tolerance and dependency-call timeouts.
* Test connection-pool resilience and retry-storm protection under added latency.
* Confirm SLO error budgets burn at the expected rate when latency is injected.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-network-latency.md" class="button primary">View details</a>

#### ECS container network loss <a href="#ecs-container-network-loss" id="ecs-container-network-loss"></a>

ECS container network loss drops a configurable percentage of outbound packets from containers in EC2-backed ECS tasks for a configurable duration, so you can test how the workload reacts when network reliability degrades.

<details>

<summary>Use cases</summary>

* Validate partial-loss tolerance and 100%-loss failover behaviour.
* Test TCP retransmission cost and replica failover under packet loss.
* Confirm loss surfaces in network metrics and alerts.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-network-loss.md" class="button primary">View details</a>

#### ECS container volume detach <a href="#ecs-container-volume-detach" id="ecs-container-volume-detach"></a>

ECS container volume detach detaches EBS volumes attached to ECS task containers for a configurable duration and reattaches them afterwards, so you can test how stateful tasks behave when their storage disappears.

<details>

<summary>Use cases</summary>

* Validate clean IO-error handling and stateful-task failover when the data volume disappears.
* Confirm the task reconnects cleanly when the volume is reattached.
* Rehearse disaster-recovery procedures for missing-volume scenarios on ECS.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-volume-detach.md" class="button primary">View details</a>

#### ECS Fargate CPU hog <a href="#ecs-fargate-cpu-hog" id="ecs-fargate-cpu-hog"></a>

ECS Fargate CPU hog stresses CPU inside a Fargate task for a configurable duration, so you can test how the application behaves when its task is CPU-starved.

<details>

<summary>Use cases</summary>

* Validate that Fargate task vCPU sizing is sufficient for the workload's peak.
* Confirm autoscaling on the ECS service scales out under sustained CPU pressure.
* Test the impact of a noisy sidecar consuming CPU on the main application container.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-fargate-cpu-hog.md" class="button primary">View details</a>

#### ECS Fargate memory hog <a href="#ecs-fargate-memory-hog" id="ecs-fargate-memory-hog"></a>

ECS Fargate memory hog consumes a configurable amount of memory inside a Fargate task for a configurable duration, so you can test how the application behaves when its task is starved of memory.

<details>

<summary>Use cases</summary>

* Validate OOM behaviour and task restart inside the Fargate task.
* Confirm that the application gracefully degrades or restarts when memory is exhausted.
* Test the impact of a noisy sidecar consuming memory on the main application container.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-fargate-memory-hog.md" class="button primary">View details</a>

#### ECS instance stop <a href="#ecs-instance-stop" id="ecs-instance-stop"></a>

ECS instance stop stops one or more EC2 container instances belonging to an ECS cluster for a configurable duration, then starts them again, so you can test how the cluster reschedules tasks and how the workload behaves when a host disappears.

<details>

<summary>Use cases</summary>

* Validate task rescheduling onto surviving container instances.
* Confirm Auto Scaling Group response when an EC2 container instance disappears.
* Test workload availability across a multi-AZ ECS cluster during host loss.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-instance-stop.md" class="button primary">View details</a>

#### ECS invalid container image <a href="#ecs-invalid-container-image" id="ecs-invalid-container-image"></a>

ECS invalid container image swaps the container image on an ECS service to an invalid value for a configurable duration, then restores the original image, so you can test how deployments, rollbacks, and monitoring react to a failing image pull.

<details>

<summary>Use cases</summary>

* Validate that the service detects ImagePullBackOff-style failures and surfaces them in alerts.
* Confirm deployment circuit-breaker (`deploymentConfiguration`) prevents traffic from shifting to the bad revision.
* Rehearse rollback runbooks for failed image pulls.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-invalid-container-image.md" class="button primary">View details</a>

#### ECS network restrict <a href="#ecs-network-restrict" id="ecs-network-restrict"></a>

ECS network restrict modifies the security group rules of an ECS service for a configurable duration and restores them afterwards, so you can test how the workload behaves when outbound or inbound network access is restricted.

<details>

<summary>Use cases</summary>

* Validate clean error handling when outbound access to a dependency is blocked.
* Confirm health checks behave correctly when inbound access is restricted.
* Test fallback paths when an SG rule change breaks a specific port.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-network-restrict.md" class="button primary">View details</a>

#### ECS task scale <a href="#ecs-task-scale" id="ecs-task-scale"></a>

ECS task scale changes the desired count of an ECS service for a configurable duration and restores it afterwards, so you can test how the workload behaves under sudden scale-up or scale-down.

<details>

<summary>Use cases</summary>

* Validate replica failover when the task count is reduced.
* Confirm autoscaling and capacity-provider behaviour during a sudden scale-up.
* Test deployment circuit-breaker behaviour under aggressive scale changes.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-task-scale.md" class="button primary">View details</a>

#### ECS task stop <a href="#ecs-task-stop" id="ecs-task-stop"></a>

ECS task stop stops one or more ECS tasks (selected by service or task ID) for a configurable duration, so you can test how the workload behaves when a specific task disappears.

<details>

<summary>Use cases</summary>

* Validate that the ECS service replaces stopped tasks within the deployment configuration.
* Confirm load-balancer target deregistration and re-registration is clean.
* Test that standalone (non-service) tasks fail upstream callers gracefully.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-task-stop.md" class="button primary">View details</a>

#### ECS update container resource limit <a href="#ecs-update-container-resource-limit" id="ecs-update-container-resource-limit"></a>

ECS update container resource limit re-registers an ECS task definition with reduced CPU or memory limits for a configurable duration and restores the original limits afterwards, so you can test how the workload behaves under tightened resource constraints.

<details>

<summary>Use cases</summary>

* Validate workload behaviour when CPU or memory limits are tightened.
* Confirm autoscaling triggers more aggressively under reduced limits.
* Rehearse the rollback runbook for incorrect resource-limit changes.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-update-container-resource-limit.md" class="button primary">View details</a>

#### ECS update container timeout <a href="#ecs-update-container-timeout" id="ecs-update-container-timeout"></a>

ECS update container timeout re-registers an ECS task definition with modified container start or stop timeouts for a configurable duration and restores the originals afterwards, so you can test how the deployment behaves when container start or stop takes longer than expected.

<details>

<summary>Use cases</summary>

* Validate that deployments fail fast (or wait gracefully) when container start exceeds the timeout.
* Confirm container shutdown handlers complete within the configured stop timeout.
* Rehearse rollback for accidentally too-low start/stop timeouts.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-update-container-timeout.md" class="button primary">View details</a>

#### ECS update task role <a href="#ecs-update-task-role" id="ecs-update-task-role"></a>

ECS update task role swaps the IAM task role on an ECS service for a configurable duration and restores the original afterwards, so you can test how the workload behaves when its IAM permissions change.

<details>

<summary>Use cases</summary>

* Validate clean error handling when the task role loses permissions to a dependency (S3, DynamoDB, KMS).
* Confirm monitoring detects AccessDenied surges from the application.
* Test fallback or retry behaviour against AWS API permission errors.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-update-task-role.md" class="button primary">View details</a>

#### Generic experiment template <a href="#generic-experiment-template" id="generic-experiment-template"></a>

Generic experiment template (also known as Generic FIS experiment template) starts a pre-existing AWS Fault Injection Service (FIS) template by ID, so you can fold native AWS-managed faults into a Harness chaos experiment and probe, verify, and report on the result as you do with any other Harness fault.

<details>

<summary>Use cases</summary>

* Drive an existing FIS template from Chaos Studio so you can attach probes, hypothesis criteria, and reports.
* Mix native FIS actions with Harness-native faults inside one experiment.
* Centralise FIS results alongside every other Harness chaos run.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/generic-experiment-template.md" class="button primary">View details</a>

#### Lambda block TCP connection <a href="#lambda-block-tcp-connection" id="lambda-block-tcp-connection"></a>

Lambda block TCP connection blocks outbound TCP connections from an AWS Lambda function to one or more target hostnames for a configurable duration, so you can test how the function behaves when a TCP-based dependency is unreachable.

<details>

<summary>Use cases</summary>

* Validate fail-fast behaviour when a TCP-based dependency (database, cache, external API) is unreachable.
* Confirm function timeout protects against TCP-blocked dependencies without amplifying cost.
* Test alarm fidelity for elevated Lambda error rate.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-block-tcp-connection.md" class="button primary">View details</a>

#### Lambda delete event source mapping <a href="#lambda-delete-event-source-mapping" id="lambda-delete-event-source-mapping"></a>

Lambda delete event source mapping deletes one or more event source mappings on an AWS Lambda function for a configurable duration and recreates them afterwards, so you can test how the workload behaves when the function stops receiving events from its source.

<details>

<summary>Use cases</summary>

* Validate event backlog handling (SQS / Kinesis / DynamoDB Streams) when the mapping is removed.
* Confirm drain behaviour and idempotency when the mapping is recreated.
* Test alarm fidelity for iterator age and queue depth.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-delete-event-source-mapping.md" class="button primary">View details</a>

#### Lambda function layer detach <a href="#lambda-function-layer-detach" id="lambda-function-layer-detach"></a>

Lambda function layer detach detaches a specified Lambda layer from a target AWS Lambda function for a configurable duration and reattaches it afterwards, so you can test how the workload behaves when a shared dependency layer disappears.

<details>

<summary>Use cases</summary>

* Validate clean error reporting when the layer's libraries or binaries disappear.
* Audit whether the function actually uses the libraries provided by the layer.
* Confirm reattach restores normal operation without manual intervention.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-function-layer-detach.md" class="button primary">View details</a>

#### Lambda delete function concurrency <a href="#lambda-delete-function-concurrency" id="lambda-delete-function-concurrency"></a>

Lambda delete function concurrency deletes the reserved concurrency configuration on an AWS Lambda function for a configurable duration and restores it afterwards, so you can test how the workload behaves when the function has to share account-level concurrency with other functions.

<details>

<summary>Use cases</summary>

* Validate throttling exposure when the reservation disappears.
* Confirm alarm fidelity on `Throttles` and account-level concurrency usage.
* Test downstream consumer behaviour when the function throughput drops.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-delete-function-concurrency.md" class="button primary">View details</a>

#### Lambda toggle event mapping state <a href="#lambda-toggle-event-mapping-state" id="lambda-toggle-event-mapping-state"></a>

Lambda toggle event mapping state disables one or more event source mappings on an AWS Lambda function for a configurable duration and re-enables them afterwards, so you can test how the workload behaves when the function temporarily stops receiving events from its source.

<details>

<summary>Use cases</summary>

* Validate event backlog handling when the mapping is disabled (without losing the mapping).
* Confirm drain behaviour when the mapping is re-enabled.
* Test alarm fidelity for iterator age, queue depth, and "no invocations".

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-toggle-event-mapping-state.md" class="button primary">View details</a>

#### Lambda update function memory <a href="#lambda-update-function-memory" id="lambda-update-function-memory"></a>

Lambda update function memory lowers the memory allocation of an AWS Lambda function for a configurable duration and restores it afterwards, so you can test how the workload behaves with less memory and a proportionally smaller CPU share.

<details>

<summary>Use cases</summary>

* Validate OOM behaviour and the impact of reduced CPU share on duration.
* Identify the lowest safe memory setting for cost optimization.
* Confirm alarms fire when memory pressure rises.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-update-function-memory.md" class="button primary">View details</a>

#### Lambda update function timeout <a href="#lambda-update-function-timeout" id="lambda-update-function-timeout"></a>

Lambda update function timeout lowers the configured timeout of an AWS Lambda function for a configurable duration and restores it afterwards, so you can test how the workload behaves when invocations are cut short.

<details>

<summary>Use cases</summary>

* Validate clean caller behaviour when tail invocations are killed.
* Identify the lowest safe timeout setting for cost optimization.
* Confirm alarms fire on elevated `Errors` from timed-out invocations.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-update-function-timeout.md" class="button primary">View details</a>

#### Lambda inject latency <a href="#lambda-inject-latency" id="lambda-inject-latency"></a>

Lambda inject latency adds a configurable amount of latency to every invocation of an AWS Lambda function for a configurable duration, so you can test how upstream callers and downstream consumers handle slower-than-expected responses, cold-start spikes, and resource contention.

<details>

<summary>Use cases</summary>

* Validate caller timeout and retry behaviour when the function is slow.
* Confirm retries do not amplify load on the function or its dependencies.
* Test alarm fidelity for `Duration` and end-to-end p99.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-inject-latency.md" class="button primary">View details</a>

#### Lambda inject status code <a href="#lambda-inject-status-code" id="lambda-inject-status-code"></a>

Lambda inject status code overrides the HTTP status code returned by an AWS Lambda function for a configurable duration, so you can test how upstream callers and downstream consumers handle unexpected error status responses.

<details>

<summary>Use cases</summary>

* Validate caller error handling, retry budgets, circuit breakers, and fallback flows.
* Confirm alarm fidelity on Lambda `Errors` and API Gateway / ALB 5xx.
* Test client behaviour against unexpected statuses without crashing.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-inject-status-code.md" class="button primary">View details</a>

#### Lambda update role permission <a href="#lambda-update-role-permission" id="lambda-update-role-permission"></a>

Lambda update role permission detaches a specified IAM policy from the execution role attached to an AWS Lambda function for a configurable duration and reattaches it afterwards, so you can test how the workload behaves when the function loses permission to call a downstream AWS service.

<details>

<summary>Use cases</summary>

* Validate fail-fast behaviour when an AWS API permission disappears.
* Confirm alarm fidelity on Lambda errors and downstream service access denials.
* Test caller and downstream behaviour during the IAM propagation window.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-update-role-permission.md" class="button primary">View details</a>

#### Lambda modify response body <a href="#lambda-modify-response-body" id="lambda-modify-response-body"></a>

Lambda modify response body overrides the response body returned by an AWS Lambda function for a configurable duration, so you can test how upstream callers and client applications handle unexpected payload shapes and corrupted data.

<details>

<summary>Use cases</summary>

* Validate response-schema validation in client applications.
* Identify silent consumers that accept invalid responses without alerting.
* Confirm alarm fidelity on application-level error rate.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-modify-response-body.md" class="button primary">View details</a>

#### NLB AZ down <a href="#nlb-az-down" id="nlb-az-down"></a>

NLB AZ down detaches one or more availability zones from a Network Load Balancer for a configurable duration, then reattaches them, so you can test how multi-AZ NLB workloads behave when a zone disappears from the load balancer surface.

<details>

<summary>Use cases</summary>

* Validate AZ-level resilience and DNS-based client failover for TCP/UDP workloads.
* Test long-lived TCP connection recovery when the AZ endpoint is removed.
* Confirm cross-zone behaviour and target re-registration after recovery.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/nlb-az-down.md" class="button primary">View details</a>

#### RDS instance delete <a href="#rds-instance-delete" id="rds-instance-delete"></a>

RDS instance delete deletes a target RDS DB instance, so you can test how applications behave when a database disappears permanently and how disaster-recovery procedures handle the loss.

<details>

<summary>Use cases</summary>

* Rehearse the DR runbook for restoring a deleted DB instance from snapshot.
* Validate read-replica promotion when the primary disappears.
* Confirm monitoring detects the deletion within the expected window.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/rds-instance-delete.md" class="button primary">View details</a>

#### RDS instance reboot <a href="#rds-instance-reboot" id="rds-instance-reboot"></a>

RDS instance reboot reboots a target RDS DB instance (with optional Multi-AZ failover) for a configurable duration, so you can test how applications behave when their database restarts.

<details>

<summary>Use cases</summary>

* Validate connection-pool reconnection across a reboot.
* Test Multi-AZ failover and read-replica behaviour with `FAILOVER=true`.
* Confirm write-path timeout handling and one cohesive alert during reboot.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/rds-instance-reboot.md" class="button primary">View details</a>

#### Resource access restrict <a href="#resource-access-restrict" id="resource-access-restrict"></a>

Resource access restrict temporarily strips ingress or egress rules from one or more AWS security groups for a configurable duration and restores them afterwards, so you can test how the workload behaves when network access to (or from) an AWS resource disappears.

<details>

<summary>Use cases</summary>

* Validate clean fail-fast behaviour when network access disappears.
* Confirm multi-AZ resilience absorbs the load on healthy resources.
* Test alarm fidelity on connection errors and target health.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/resource-access-restrict.md" class="button primary">View details</a>

#### SSM chaos by ID <a href="#ssm-chaos-by-id" id="ssm-chaos-by-id"></a>

SSM chaos by ID runs an arbitrary AWS Systems Manager document against a target EC2 instance selected by ID, so you can inject custom chaos that is not covered by a dedicated fault.

<details>

<summary>Use cases</summary>

* Run a custom shell script or domain-specific failure not covered by another fault.
* Trigger filesystem corruption, kernel-level chaos, or other one-shot scenarios.
* Validate hypotheses without authoring a new dedicated fault.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ssm-chaos-by-id.md" class="button primary">View details</a>

#### SSM chaos by tag <a href="#ssm-chaos-by-tag" id="ssm-chaos-by-tag"></a>

SSM chaos by tag runs an arbitrary AWS Systems Manager document against EC2 instances selected by tag, so you can inject custom chaos against a logical group of hosts.

<details>

<summary>Use cases</summary>

* Run a custom shell script across a tagged service tier.
* Apply domain-specific failures to a percentage of tagged hosts via `INSTANCE_AFFECTED_PERC`.
* Validate hypotheses across a fleet without authoring a new dedicated fault.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ssm-chaos-by-tag.md" class="button primary">View details</a>

#### Windows EC2 blackhole chaos <a href="#windows-ec2-blackhole-chaos" id="windows-ec2-blackhole-chaos"></a>

Windows EC2 blackhole chaos drops all network traffic destined for specific IPs or hosts on one or more Windows EC2 instances for a configurable duration, so you can test how Windows-hosted workloads behave when a specific dependency is completely unreachable.

<details>

<summary>Use cases</summary>

* Validate fail-fast and circuit-breaker behaviour when a dependency is unreachable.
* Confirm cross-region or fallback routing engages within the SLA.
* Test monitoring alert fidelity on "dependency unreachable" conditions.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/windows-ec2-blackhole-chaos.md" class="button primary">View details</a>

#### Windows EC2 CPU hog <a href="#windows-ec2-cpu-hog" id="windows-ec2-cpu-hog"></a>

Windows EC2 CPU hog stresses a configurable number of CPU cores at a configurable load percentage inside one or more Windows EC2 instances for a configurable duration, so you can test how Windows-hosted workloads behave when their host is CPU-starved.

<details>

<summary>Use cases</summary>

* Validate p99 latency stays within SLO when all cores are saturated.
* Confirm CloudWatch CPU alarms and ASG scale-out trigger in the expected window.
* Test burst-credit exhaustion on T-family instances and co-tenant isolation.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/windows-ec2-cpu-hog.md" class="button primary">View details</a>

#### Windows EC2 memory hog <a href="#windows-ec2-memory-hog" id="windows-ec2-memory-hog"></a>

Windows EC2 memory hog consumes a configurable amount of memory inside one or more Windows EC2 instances for a configurable duration, so you can test how Windows-hosted workloads behave when their host is starved of memory.

<details>

<summary>Use cases</summary>

* Validate that the OS swap (pagefile) absorbs the pressure without crashing the application.
* Confirm CloudWatch memory alarms trigger ASG scale-out in time.
* Test application behaviour as available memory falls below critical thresholds.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/windows-ec2-memory-hog.md" class="button primary">View details</a>

#### Windows EC2 network latency <a href="#windows-ec2-network-latency" id="windows-ec2-network-latency"></a>

Windows EC2 network latency adds a configurable amount of latency to network traffic destined for specific IPs or hosts on one or more Windows EC2 instances for a configurable duration, so you can test how Windows-hosted workloads behave when the network is slow.

<details>

<summary>Use cases</summary>

* Validate timeouts and retry behaviour for targeted dependency slowdowns.
* Confirm latency budgets across the call graph hold within SLO.
* Test cross-AZ or cross-region replica failover when one path is slow.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/windows-ec2-network-latency.md" class="button primary">View details</a>

#### Windows EC2 network loss <a href="#windows-ec2-network-loss" id="windows-ec2-network-loss"></a>

Windows EC2 network loss drops a configurable percentage of network packets destined for specific IPs or hosts on one or more Windows EC2 instances for a configurable duration, so you can test how Windows-hosted workloads behave when the network is lossy.

<details>

<summary>Use cases</summary>

* Validate retry recovery and TCP backoff under partial packet loss.
* Confirm monitoring detects elevated loss on the affected path.
* Test replica failover when a specific path becomes lossy.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/windows-ec2-network-loss.md" class="button primary">View details</a>

#### Windows EC2 process kill <a href="#windows-ec2-process-kill" id="windows-ec2-process-kill"></a>

Windows EC2 process kill kills one or more processes (selected by PID or process name) on one or more Windows EC2 instances for a configurable duration, so you can test how Windows-hosted workloads behave when their backing processes die.

<details>

<summary>Use cases</summary>

* Validate Windows Service Control Manager recovery options.
* Confirm cluster failover (SQL Server AlwaysOn, MSCS) when a local process dies.
* Test custom watchdog/supervisor (NSSM, FireDaemon) respawn behaviour.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/windows-ec2-process-kill.md" class="button primary">View details</a>

{% @harness-feedback/feedback %}
