AWS Fault Injection Service

AWS FIS Actions, Action Selection & Scenario Library

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 — verify with aws fis list-actions and aws fis get-action --id <action-id> (or the FIS Actions reference) before committing to a command. The tables below are illustrative, not a frozen source of truth.

Contents

• Action structure

• Action selection map — match failure scenario → action

• Action catalog by namespace (illustrative)

• Targets — how to scope the blast radius

• Scenario library (console-only, AWS-owned)

• Prerequisites & gotchas by action

Action structure

Each action in actions has:

"actions": {
  "StopInstances": {
    "actionId": "aws:ec2:stop-instances",
    "description": "Stop EC2 instances then restart after 10 minutes",
    "parameters": { "startInstancesAfterDuration": "PT10M" },
    "targets": { "Instances": "myInstanceTarget" },
    "startAfter": []
  }
}

Action ID naming convention

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).

Action selection map — match failure scenario → action

Models often pick a real but wrong action. Use this map, then verify the ID.

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.

Action catalog by namespace (illustrative)

• EC2 — 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.

• ECS — aws:ecs:stop-task, aws:ecs:drain-container-instances, plus SSM-agent-based CPU/ memory/IO/network stress task actions.

• EKS — 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.

• RDS — aws:rds:reboot-db-instances, aws:rds:failover-db-cluster.

• ElastiCache — aws:elasticache:replicationgroup-interrupt-az-power.

• EBS — aws:ebs:pause-volume-io (Nitro-based instances only).

• Lambda — aws:lambda:invocation-add-delay, aws:lambda:invocation-error, aws:lambda:invocation-http-integration-response (require the FIS Lambda extension layer).

• Network — aws:network:disrupt-connectivity, aws:network:route-table-disrupt-connectivity, aws:network:transit-gateway-disrupt-cross-region-connectivity.

• FIS API faults / control — aws:fis:inject-api-internal-error, aws:fis:inject-api-throttle-error, aws:fis:inject-api-unavailable-error, aws:fis:wait.

• SSM (custom faults on hosts) — 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.

• CloudWatch — aws:cloudwatch:assert-alarm-state.

• ARC — aws:arc:start-zonal-autoshift.

Targets — how to scope the blast radius

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).

Resource parameters (attribute selectors) — examples

• 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.

Example target

"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)"
  }
}

Scenario library (console-only, AWS-owned)

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):

• EC2 stress: instance failure — stop instances, restart after the action duration (default 5 min).

• EC2 stress: CPU / Memory / Disk / Network Latency — inject increasing resource pressure.

EKS (target pods by Kubernetes app label):

• EKS stress: Pod Delete — delete matched pods (recovery per k8s config).

• EKS stress: CPU / Memory / Disk / Network latency.

Single-AZ / multi-AZ / multi-Region (multiple resource types):

• AZ Availability: Power Interruption — simulate a complete power interruption in one AZ.

• AZ: Application Slowdown — add latency between resources within one AZ.

• Cross-AZ: Traffic Slowdown — inject packet loss between AZs.

• Cross-Region: Connectivity — block traffic from the experiment Region to a destination Region and pause cross-Region data replication.

EBS (target volumes by tag; volumes must be in the same AZ):

• EBS: Sustained / Increasing / Intermittent / Decreasing Latency — I/O latency patterns.

Prerequisites & gotchas by action

• SSM-based actions (host stress, custom faults): SSM Agent must be installed and running on targets; the experiment role needs SSM permissions.

• Lambda actions: require the FIS Lambda extension layer configured on the function.

• EBS pause-volume-io: target volumes must be attached to Nitro-based instances.

• EKS pod actions: require the target EKS cluster to be prepared for FIS (see EKS Pod actions docs).

• Network faults: verify VPC/subnet/route-table prerequisites; connectivity disruption acts at the network layer, not the API layer.