AWS Fault Injection Service – Part 1 – What Is AWS (FIS)?

A Beginner’s Guide to Chaos Engineering on AWS


If you’ve ever watched a distributed system crash mid‑deployment, you know how expensive downtime can be. The usual “watch the logs” approach is slow and often misses the root cause because real‑world faults rarely appear in test environments.

AWS Fault Injection Service (FIS) – your own chaos‑engineering playground. Think of it as a safety‑net that lets you create the exact conditions that could bring down an application, then observe how it behaves. By running these experiments before a big release or during maintenance windows, you can:

BenefitReal‑world impact
Proactive resilienceCatch hidden bottlenecks in staging instead of production
Confidence for releasesVerify that auto‑scaling and recovery scripts actually work
Cost controlSpot inefficiencies early, saving on over‑provisioned resources

What Is AWS FIS?

AWS Fault Injection Service is a managed service that lets you run fault injection experiments against your AWS workloads.

It follows the same principles as chaos engineering: intentionally introduce failures (network latency, CPU throttling, instance termination) to see how your system reacts. If your application can recover gracefully, you’re good; if not, you get concrete data on what needs improvement.


How It Works – The Core Concepts

ConceptWhat it isWhy it matters
ExperimentA single run that applies a set of faults to your resources.Gives you the “what happens” snapshot.
Experiment TemplateBlueprint for an experiment: actions, targets, stop‑conditions.Reusable; version control for chaos tests.
ActionThe fault itself (e.g., pause EC2 instance, drop network packets).The cause of the experiment.
TargetThe resource(s) on which an action runs (EC2, ECS task, Lambda function, etc.).Pinpoints where you’re injecting failure.
Stop ConditionA CloudWatch alarm that halts the experiment when a threshold is crossed.Safety guardrail to avoid catastrophic outages.

Tip: Think of an experiment template as a “recipe” – you can bake it many times with different ingredients (targets) or tweak the spice level (action duration).


Where It Fits Into Your Workflow

  1. Planning – Define what you want to test (e.g., “Will my ECS service recover if one container stops?”).
  2. Template Creation – Use the console, CLI (aws fis create-experiment-template), or CloudFormation (AWS::FIS::ExperimentTemplate).
  3. Run & Monitor – Execute via console or aws fis start-experiment. Watch logs in CloudWatch and the AWS FIS dashboard.
  4. Analyze – Review metrics, identify bottlenecks, update your architecture or automation scripts.

You can even embed experiments into CI/CD pipelines (e.g., GitHub Actions → FIS CLI call) for automated resilience testing.


Getting Started With the AWS Console

  1. Open AWS Management Console → Fault Injection Service.
  2. Click Create experiment template.
  3. Pick an action (say, “Terminate EC2 instance”) and set a target group (all instances in dev tag).
  4. Add a stop condition: e.g., “If CPU utilization < 10% for > 30 s, stop the experiment.”
  5. Review & create.

Pro tip: Use the “Pre‑flight” feature to simulate the experiment without actually injecting faults. It gives you a preview of what will happen.


Pricing Snapshot

FIS charges per minute that an action runs, based on the number of target accounts. It’s a pay‑as‑you‑go model:

ActionPrice (USD)
CPU throttling$0.02/min
Instance termination$0.04/min
Network latency injection$0.03/min

Always check the for the latest rates.


⚠️ Important Safety Note

“AWS FIS carries out real actions on real AWS resources in your system.”

Never run an experiment directly against production without first testing it in a sandbox or staging environment. Treat each experiment as a potential live‑event – use stop conditions and guardrails to keep it under control.


Want to Dive Deeper?


Bottom Line

AWS FIS gives you the tools to ask hard questions about your system’s resilience before they become production disasters. By injecting controlled faults, you learn how your architecture behaves under pressure and can iterate faster with confidence.

Part 2: Planning Your First AWS Fault Injection Service Experiment.