cloudparts

AWS Fault Injection Service

AWS’s managed chaos engineering service: you write an experiment template of actions, targets and stop conditions, and FIS stops instances, fails over databases, slows networks or throttles AWS APIs in your account, halting when a CloudWatch alarm fires.

What it is
Chaos engineering
Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary
Facts checked
24 October 2026
Website

What it is

AWS FIS runs experiments against real resources in your AWS account. An experiment template names the targets (resources picked by ARN, by tag or by filters, then all of them, a count or a percentage at random), the actions to run on them, in sequence or in parallel, and the stop conditions, which are CloudWatch alarms that halt the experiment if they go off. FIS assumes an IAM role you give it, so the role limits what an experiment can touch.

Actions cover much of AWS: stopping, rebooting or terminating EC2 instances and sending Spot interruptions; stopping ECS tasks and draining container instances; deleting EKS pods and terminating node group instances; failing over RDS and Aurora clusters; pausing EBS volume I/O; pausing DynamoDB global table, MemoryDB and S3 replication; cutting subnet or cross-Region connectivity; and returning throttling, internal or unavailable errors from AWS APIs for a chosen IAM role. Inside instances and containers, CPU, memory, I/O and network faults run through Systems Manager documents or ECS and EKS actions; Lambda faults use an FIS extension attached as a layer, which adds delay or errors to a percentage of invocations. For anything else, aws:eks:inject-kubernetes-custom-resource creates Chaos Mesh or Litmus resources in an EKS cluster.

A scenario library holds prebuilt templates, such as “AZ Availability: Power Interruption”, which takes down zonal compute, subnets, EBS volumes and ElastiCache and RDS primaries in one Availability Zone. Multi-account experiments run from an orchestrator account against target accounts. FIS charges $0.10 per action-minute for each target account.

Why teams pick it

  • No agents or extra infrastructure for faults that go through AWS APIs, such as instance stops, database failovers and API throttling
  • Faults no outside tool can produce, such as a simulated power loss across an Availability Zone or paused DynamoDB global table replication
  • Guardrails built in: an IAM role scopes each experiment, CloudWatch alarms stop it, and experiments can be scheduled or run across accounts
  • Can drive Chaos Mesh or LitmusChaos inside EKS, so one template can mix AWS-level and pod-level faults

Watch out for

  • AWS only: it can’t inject faults into other clouds or into on-premises systems
  • In-guest faults need the Systems Manager agent on instances, and Lambda faults need a layer, an S3 configuration bucket and environment variables on every function
  • The Lambda extension polls for work, so faults can take up to about 60 seconds to start, and it can’t be used with response streaming
  • Billed per action-minute per account, and experiment reports cost $5 each, so long or many-account experiments add up

Alternatives

What all chaos engineering have in common →Compare side by side →
GremlinCommercialA commercial chaos engineering platform: agents on your hosts, containers and Kubernetes clusters take orders from Gremlin’s hosted control plane to inject resource, network and state faults, and Gremlin scores each service on how it held up.

How it fits with other technologies

Stop three random prod instances for two minutes, unless an alarm fires first · json

{
  "description": "Stop and restart three instances with the specified tag",
  "targets": {
    "myInstances": {
      "resourceType": "aws:ec2:instance",
      "resourceTags": { "env": "prod" },
      "selectionMode": "COUNT(3)"
    }
  },
  "actions": {
    "StopInstances": {
      "actionId": "aws:ec2:stop-instances",
      "parameters": { "startInstancesAfterDuration": "PT2M" },
      "targets": { "Instances": "myInstances" }
    }
  },
  "stopConditions": [{
    "source": "aws:cloudwatch:alarm",
    "value": "arn:aws:cloudwatch:us-east-1:111122223333:alarm:checkout-errors"
  }],
  "roleArn": "arn:aws:iam::111122223333:role/fis-experiments"
}

See it in a real stack

No architecture uses AWS Fault Injection Service yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2020–2025

AWS describes chaos engineering as building on work by “Master of Disaster” Jesse Robbins in the early days of Amazon.com, later taken “into high gear” by Netflix’s Chaos Monkey. At re:Invent in December 2020 Werner Vogels pre-announced AWS Fault Injection Simulator, saying “chaos engineering is for everyone, not just shops running at Amazon or Netflix scale”. It became generally available in March 2021 with actions for EC2, ECS, EKS and RDS.

The service grew outward from there: CloudWatch alarm checks, Systems Manager Automation runbooks and I/O and network actions for EC2 in November 2021, GovCloud regions in 2022, and in November 2023 scheduled experiments, a scenario library, multi-account experiments and the Availability Zone power interruption and cross-Region connectivity scenarios. By then AWS called it AWS Fault Injection Service. Later additions include Lambda faults, experiment reports and, in November 2025, scenarios for slowdowns within and between Availability Zones.

Why it’s built this way

Experiments as templates with stop conditions
Jeff Barr described stop conditions as a safety mechanism that keeps a local failure from cascading into a full outage, so every experiment declares what will end it before it starts.
Act through AWS’s own control plane
Running inside AWS lets FIS produce failures customers can’t script themselves, such as API throttling for one IAM role or a zone-wide power loss, without installing anything for most actions.
Plug in open-source Kubernetes tools
Rather than reimplement every pod-level fault, FIS can create Chaos Mesh and Litmus custom resources in EKS, letting those tools do in-cluster injection.

Timeline

  1. 2020

    Announced at re:Invent in December

  2. 2021

    Generally available in March with EC2, ECS, EKS and RDS actions

  3. 2022

    Available in AWS GovCloud (US)

  4. 2023

    Scenario library, scheduled and multi-account experiments, AZ power interruption scenario

  5. 2025

    Scenarios for application slowdown in one AZ and traffic slowdown between AZs

Sources8 · facts checked 24 October 2026

Improve this page on GitHub