Setting the file. One moment.
Skill 103 · AWS Fault Injection Service
Subchapter 103.1
references/fis-actions-reference.mdMarkdown10 KBView on GitHub
Use this to suggest the right fault for a scenario and to build the actions block of a
template. Action IDs and parameters change over time — (or the )
before committing to a command. The tables below are illustrative, not a frozen source of truth.
aws fis list-actions and
aws fis get-action --id <action-id>Each action in actions has:
| Field | Meaning |
|---|---|
actionId | The pre-defined FIS action to run (e.g. aws:ec2:stop-instances). Required. |
parameters | Key-value pairs for the action (durations use ISO 8601, e.g. PT10M). Required/optional per action. |
targets | Maps the action’s target role name → a target defined in the template’s targets block. |
startAfter | Names of actions that must finish before this one starts. Omit → runs in parallel. |
"actions": {
"StopInstances": {
"actionId": "aws:ec2:stop-instances",
"description": "Stop EC2 instances then restart after 10 minutes",
"parameters": { "startInstancesAfterDuration": "PT10M" },
"targets": { "Instances": "myInstanceTarget" },
"startAfter": []
}
}aws:<service-name>:<action-type> — e.g. aws:rds:failover-db-cluster. Service-level fault
namespaces (aws:ec2:*, aws:rds:*, …) act on infrastructure; the aws:fis:* namespace injects
API-level faults and provides control actions (wait).
Models often pick a real but wrong action. Use this map, then verify the ID.
| If the scenario is… | Illustrative action ID (verify with list-actions) |
|---|---|
| Full AZ power interruption / “AZ goes dark” | Use the AZ Availability: Power Interruption scenario (multi-fault); it combines instance/subnet/EBS/RDS/ElastiCache faults |
| Single-AZ instance loss | aws:ec2:stop-instances or aws:ec2:terminate-instances (scope target to the AZ via filter) |
| Spot capacity reclaim | aws:ec2:send-spot-instance-interruptions |
| ECS task loss / capacity drain | aws:ecs:stop-task, aws:ecs:drain-container-instances |
| EKS pod failure | aws:eks:pod-delete |
| EKS node loss | aws:eks:terminate-nodegroup-instances |
| EKS pod latency / packet loss | aws:eks:pod-network-latency, aws:eks:pod-network-packet-loss |
| DB / Aurora / RDS failover | aws:rds:failover-db-cluster (cluster) or aws:rds:reboot-db-instances (instance) |
| ElastiCache node/AZ disruption | aws:elasticache:replicationgroup-interrupt-az-power |
| Region-level API unavailability | aws:fis:inject-api-unavailable-error |
| Service returns 5xx but is reachable | aws:fis:inject-api-internal-error |
| Throttling / 429 responses | aws:fis:inject-api-throttle-error |
| Lambda slow responses (latency) | aws:lambda:invocation-add-delay |
| Lambda forced errors | aws:lambda:invocation-error |
| Lambda altered HTTP integration response | aws:lambda:invocation-http-integration-response |
| Network partition / subnet isolation | aws:network:disrupt-connectivity |
| Route-table-level connectivity loss | aws:network:route-table-disrupt-connectivity |
| Cross-Region (transit gateway) isolation | aws:network:transit-gateway-disrupt-cross-region-connectivity |
| EBS volume I/O latency | aws:ebs:pause-volume-io (Nitro only) — or the EBS latency scenarios |
| Run a custom fault on a host | aws:ssm:send-command, aws:ssm:start-automation-execution |
| Assert a CloudWatch alarm’s state mid-experiment | aws:cloudwatch:assert-alarm-state |
| Trigger ARC zonal autoshift | aws:arc:start-zonal-autoshift |
| Insert a pause between actions | aws:fis:wait |
Rule of thumb: a service/API symptom (unavailable, 5xx, throttle) → aws:fis:inject-api-*
(all three end in -error). An infrastructure symptom (instance, task, pod, DB, cache,
volume, network) → the resource-specific namespace.
aws:ec2:stop-instances, aws:ec2:reboot-instances, aws:ec2:terminate-instances,
aws:ec2:send-spot-instance-interruptions, aws:ec2:api-insufficient-instance-capacity-error.aws:ecs:stop-task, aws:ecs:drain-container-instances, plus SSM-agent-based CPU/
memory/IO/network stress task actions.aws:eks:pod-delete, aws:eks:terminate-nodegroup-instances,
aws:eks:pod-cpu-stress, aws:eks:pod-memory-stress, aws:eks:pod-io-stress,
aws:eks:pod-network-latency, aws:eks:pod-network-packet-loss,
aws:eks:pod-network-blackhole-port.aws:rds:reboot-db-instances, aws:rds:failover-db-cluster.aws:elasticache:replicationgroup-interrupt-az-power.aws:ebs:pause-volume-io (Nitro-based instances only).aws:lambda:invocation-add-delay, aws:lambda:invocation-error,
aws:lambda:invocation-http-integration-response (require the FIS Lambda extension layer).aws:network:disrupt-connectivity,
aws:network:route-table-disrupt-connectivity,
aws:network:transit-gateway-disrupt-cross-region-connectivity.aws:fis:inject-api-internal-error,
aws:fis:inject-api-throttle-error, aws:fis:inject-api-unavailable-error, aws:fis:wait.aws:ssm:send-command (runs an SSM document, e.g. FIS
public stress documents like AWSFIS-Run-CPU-Stress), aws:ssm:start-automation-execution.
Requires the SSM Agent installed/running on targets.aws:cloudwatch:assert-alarm-state.aws:arc:start-zonal-autoshift.A target defines resourceType (exactly one) plus one selector:
resourceArns — specific resource ARNs (cannot combine with tags or filters).resourceTags — map of tag key→value; all listed tags must match (AND).filters — path (PascalCase, from the resource’s Describe API output) + values (OR within
a filter; AND across filters). Cannot combine with resourceArns.parameters — attribute-based selectors for certain resource types (see below).selectionMode — ALL, COUNT(n), or PERCENT(n); picks from the identified set at random.
COUNT(n) selects exactly n resources — no rounding. PERCENT(n) resolves the percentage to a
count and rounds down; if it resolves to fewer than 1 resource, nothing is selected and the
experiment fails.FIS resolves all targets at experiment start. If a target resolves to zero resources, the
experiment fails (unless emptyTargetResolutionMode is skip).
aws:ec2:ebs-volume → availabilityZoneIdentifier.aws:ec2:subnet → availabilityZoneIdentifier, vpc (one VPC per account).aws:ecs:task → cluster, service.aws:eks:pod → clusterIdentifier (req), namespace (req), selectorType
(labelSelector|deploymentName|podName, req), selectorValue (req),
availabilityZoneIdentifier (opt), targetContainerName (opt).aws:lambda:function → functionQualifier.aws:rds:cluster → writerAvailabilityZoneIdentifiers; aws:rds:db → availabilityZoneIdentifiers.aws:elasticache:replicationgroup → availabilityZoneIdentifier (req).Multi-account / cross-AZ tip: when targeting by AZ, use the AZ ID (e.g. use1-az1), not
the AZ name (us-east-1a) — AZ IDs are consistent across accounts.
"targets": {
"randomInstance": {
"resourceType": "aws:ec2:instance",
"resourceTags": { "env": "prod" },
"filters": [
{ "path": "Placement.AvailabilityZone", "values": ["us-east-1a"] },
{ "path": "State.Name", "values": ["running"] }
],
"selectionMode": "COUNT(1)"
}
}Scenarios are pre-built target+action patterns for common impairments. They are a console-only experience: select one in the FIS console → Create template with scenario → fill in parameters, role, stop conditions, logging → save as an experiment template. To automate, either export the created template, or copy the scenario’s Content tab and complete missing parameters manually. Prefer a scenario over a hand-built template when one fits — less undifferentiated heavy lifting and AWS-maintained.
Common scenarios (verify current library in the console):
EC2 (target by tag):
EKS (target pods by Kubernetes app label):
Single-AZ / multi-AZ / multi-Region (multiple resource types):
EBS (target volumes by tag; volumes must be in the same AZ):
pause-volume-io: target volumes must be attached to Nitro-based instances.