AutoGineer
Generated banner for AWS Fault Injection Service
Generated logo for AWS Fault Injection Service

AWS Fault Injection Service

AWSOfficialPublished by AWS

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • No issues found
Download ZIP

From the author

Plans, builds, runs, and analyzes fault injection experiments with AWS Fault Injection Service (AWS FIS) to validate application resilience through chaos engineering. Covers experiment templates (actions, targets, stop conditions), the FIS actions catalog and action selection, the scenario library (AZ power interruption, cross-Region connectivity, EC2/EKS/EBS stress), experiment lifecycle and monitoring, logging and reports, multi-account experiments, the experiment IAM role, and blast-radius safety. Applies when a user mentions AWS FIS or fault injection, asks what experiment to run for a failure mode (AZ, Region, API errors/throttling, instance/pod/DB/cache failure, latency, packet loss), wants to author an experiment template or CLI/CloudFormation, or needs to safely run chaos experiments in pre-production or production. For the broader resilience program across Resilience Hub and ARC, see aws-resilience-lifecycle; for ARC routing controls and zonal shift, see recovery-controller-setup.
— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides domain expertise for AWS Fault Injection Service (AWS FIS), a managed service for running controlled fault injection experiments on AWS resources. It helps users design experiment templates, select appropriate fault actions, manage the experiment lifecycle, and ensure safety through stop conditions and IAM role configuration. The skill covers the full workflow from mapping failure scenarios to specific FIS actions to monitoring and reporting on experiment outcomes.

What it does

  • Maps failure scenarios to specific AWS FIS actions and scenarios.
  • Assists in authoring experiment templates including targets, actions, and stop conditions.
  • Provides guidance on configuring IAM roles and permissions for FIS experiments.
  • Explains the experiment lifecycle from creation to execution and monitoring.
  • Offers troubleshooting for common experiment failures and target resolution issues.
  • Provides a canonical reference for AWS FIS API operations and parameter structures.

When to use it

  • When you need to validate application resilience through chaos engineering.
  • When you want to test how your infrastructure responds to specific failure modes like AZ outages or API throttling.
  • When you are authoring experiment templates using CLI, SDK, or CloudFormation.
  • When you need to safely configure blast-radius guardrails for fault injection experiments.

Advantages

  • Reduces risk by providing guidance on bounded blast-radius safety and stop conditions.
  • Prevents common API usage errors through a curated hallucination-rejection reference.
  • Streamlines the design of experiments by mapping failure modes to verified FIS actions.
  • Supports secure experiment execution through proper IAM role and trust policy configuration.

Usage examples

“What FIS action should I use to test how my application handles a single AZ power interruption?”
The agent identifies the AZ Availability: Power Interruption scenario and explains how to scope the target to the specific AZ.
“Help me create an experiment template to inject API throttling errors into my service.”
The agent provides the JSON structure for an experiment template using the aws:fis:inject-api-throttle-error action and includes a required CloudWatch alarm stop condition.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/aws/aws-fault-injection-service/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip aws-fault-injection-service.zip -d .agents/skills

Documentation by AWS

AWS Fault Injection Service (FIS) Experiments

Overview

Domain expertise for AWS Fault Injection Service (AWS FIS) — a managed chaos-engineering service that runs controlled fault injection experiments on real AWS resources so you can observe how an application responds to disruption and improve its resilience.

This skill lets an agent do three things:

  1. Suggest the right experiment — map a user's failure scenario or resilience question to the correct FIS action(s), scenario, or experiment design, and explain the trade-offs.

  2. Build and run experiments — author experiment templates (actions, targets, stop conditions, logging, reports), wire up the experiment IAM role, and drive the run/monitor/stop lifecycle via CLI, SDK, or CloudFormation.

  3. Inform the user — answer conceptual questions about FIS terminology, safety, pricing, supported services, and how FIS fits into a resilience program.

AWS FIS carries out real actions on real AWS resources. Before running any experiment in production, plan it, run it first in pre-production, and always bound the blast radius with a stop condition. Treat fault injection as a privileged, potentially disruptive operation.

The AWS MCP server is recommended for executing this skill's AWS API calls — it provides sandboxed execution and audit logging — but it is not required; all operations also work with the AWS CLI (aws fis ...) directly.

Guardrail — where this skill's own files live (MCP vs local install)

Before reading a reference file, determine how this skill was loaded:

  • Loaded via the AWS MCP retrieve_skill tool: the skill's reference files are not on the local filesystem. Fetch each one through retrieve_skill with the file parameter (e.g. file="references/fis-concepts.md") — do NOT file_read these paths locally or search the filesystem for them.

  • Installed locally (e.g. .kiro/skills/aws-fault-injection-service/ or ~/.claude/skills/aws-fault-injection-service/): read reference files from the local skill directory using the relative paths shown here.

This applies only to the skill's own reference files; always read and write user or session data in the working directory, never through retrieve_skill.

Start here — route the request

  • "What is FIS / when should I use it / what does X term mean / does it support Y?" → read references/fis-concepts.md.

  • "What experiment/action should I run to test a failure mode?" → read references/fis-actions-reference.md (action selection map + full catalog) and suggest an action or scenario.

  • "Build / create / run an experiment" (template, targets, stop conditions, logging, reports, scenarios, multi-account, monitoring) → follow references/fis-workflow.md exactly.

  • Any AWS CLI or API command for FIS → consult references/fis-api-reference.md FIRST — it is the canonical operation/parameter reference and includes a hallucination-rejection table.

  • IAM role, permissions, trust policy, confused-deputy, blast-radius safety → read references/fis-security.md.

API Reference (READ FIRST before producing any AWS CLI command)

The exact aws fis operation names and template parameters are documented in references/fis-api-reference.md, including a table mapping common wrong API/action names to correct ones. Always consult it before generating commands. Action IDs and resource types evolve — verify with aws fis list-actions and aws fis get-action --id <action-id> rather than trusting memory.

Suggesting experiments (behavioral contract)

When the user describes a failure they want to test rather than a command they want run:

  1. Identify the failure mode (AZ impairment, Region isolation, API errors/throttling, compute/DB/cache loss, latency, packet loss, resource exhaustion).

  2. Map it to a scenario (preferred when one fits — pre-built and AWS-owned) or a specific action using the selection map in references/fis-actions-reference.md.

  3. State the target (resource type + how to scope it) and a stop condition (CloudWatch alarm on your steady-state metric) so the blast radius is bounded.

  4. Recommend running in pre-production first, then production under change management.

  5. Offer to generate the experiment template — then follow references/fis-workflow.md.

Do not invent action IDs, resource types, or parameters. If unsure, say so and verify with aws fis list-actions / aws fis get-action or the FIS documentation.

Troubleshooting

"Experiment failed immediately / no targets found"

FIS resolves all targets at experiment start; if a target resolves to zero resources, the experiment fails (unless emptyTargetResolutionMode is skip). Check tags, filters, region, and account. Use a target preview before running (see workflow reference).

"Action failed with a permissions error"

The FIS experiment IAM role is missing permissions for the underlying service API (or SSM, or the confused-deputy trust conditions block the assume). See references/fis-security.md.

"Experiment stopped unexpectedly"

A stop condition (CloudWatch alarm) likely fired — this is the guardrail working. Check the experiment's state.reason and the alarm history. A stopped experiment cannot be resumed; start a new one from the template.

"Nitro / instance-type errors on EBS or network faults"

Some actions require Nitro-based instances or the SSM Agent. Verify prerequisites per action in references/fis-actions-reference.md.

Observability companion

For the CloudWatch alarms, dashboards, and metrics that back FIS stop conditions and experiment reports, recommend the AWS Observability skill for alarm/dashboard setup — keep this skill's guidance to how those signals feed experiment safety and post-experiment analysis.

Security Considerations

FIS runs real, potentially destructive actions. Key points (full guidance in references/fis-security.md):

  • Least privilege: scope the experiment role to only the actions and target ARNs each experiment needs — never *. Scope the human/CI principals allowed to call fis:StartExperiment.

  • Confused-deputy protection: the experiment role's trust policy MUST condition on aws:SourceAccount and aws:SourceArn (scoped to the experiment ARN pattern).

  • Bounded blast radius: always attach a CloudWatch-alarm stop condition; start with narrow targets (COUNT(1) / low PERCENT) and pre-production before production.

  • No sensitive data in string fields: experiment/template descriptions, tags, and logs surface in CloudTrail, CloudWatch Logs, S3 reports, and (multi-account) target-account Health dashboards — never embed PII, secrets, or sensitive architecture detail.

  • Encrypt logs/reports: experiment logs and PDF reports reveal resilience posture — use SSE-KMS on the S3 buckets, enforce TLS, and consider S3 Object Lock on report buckets.

  • Further reading: FIS Security and the AWS Well-Architected Reliability Pillar.

Files

references/fis-security.md

Security Considerations — aws-fault-injection-service

FIS runs real, potentially destructive actions on real resources. Secure both who can run experiments and what an experiment is allowed to touch, and always bound the blast radius.

Contents

  • The experiment IAM role (roleArn)

  • Restrict who can start experiments

  • Bounded blast radius (safety, not just IAM)

  • Data handling

  • Auditing

  • Further reading

The experiment IAM role (roleArn)

FIS assumes the experiment role to perform actions on your behalf. It is a service role with:

  1. A trust policy allowing fis.amazonaws.com to assume it, with confused-deputy conditions.

  2. Identity-based permissions for exactly the target-service APIs the experiment's actions invoke (and SSM / logs / report S3+CloudWatch if those features are used).

Trust policy with confused-deputy protection (required)

Condition on aws:SourceAccount and aws:SourceArn so only your account's FIS experiments can assume the role — never leave the trust policy unconditioned.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "fis.amazonaws.com" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "aws:SourceAccount": "123456789012" },
      "ArnLike": {
        "aws:SourceArn": "arn:aws:fis:us-east-1:123456789012:experiment/*"
      }
    }
  }]
}
Least-privilege permissions (scope to actions AND target ARNs)

Grant only what the chosen actions need, scoped to the specific target resources — never "*" across a service. Example for an EC2 reboot experiment on tagged prod instances:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:RebootInstances"],
      "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*",
      "Condition": { "StringEquals": { "aws:ResourceTag/env": "prod" } }
    },
    {
      "Effect": "Allow",
      "Action": ["ec2:DescribeInstances"],
      "Resource": "*"
    }
  ]
}

Describe* calls FIS uses for target resolution/filtering generally require Resource: "*" (they don't support resource-level scoping), but the fault actions should be scoped by ARN and/or aws:ResourceTag. Match permissions to the action's underlying API.

Action → underlying-permission mapping (illustrative — verify with get-action)

The exact IAM actions each FIS action needs evolve; treat this as a starting point and confirm the authoritative list before finalizing a policy (see "authoritative source" below). The pattern is always the same: fault permission(s) scoped by ARN/tag + the Describe* resolution permission on Resource: "*".

FIS actionFault permission(s)Typical resolution permission
aws:ec2:reboot-instances / stop-instances / terminate-instancesec2:RebootInstances / ec2:StopInstances(+StartInstances if auto-restart) / ec2:TerminateInstancesec2:DescribeInstances
aws:rds:failover-db-cluster / reboot-db-instancesrds:FailoverDBCluster / rds:RebootDBInstancerds:DescribeDBClusters / rds:DescribeDBInstances
aws:elasticache:replicationgroup-interrupt-az-powerelasticache:InterruptClusterAzPowerelasticache:DescribeReplicationGroups
aws:lambda:invocation-*lambda:<verify with get-action> on the function — never lambda:* + the FIS Lambda extension layerlambda:GetFunction
aws:ssm:send-command / start-automation-executionssm:SendCommand / ssm:StartAutomationExecution (+ the doc/automation ARNs)resource-type Describe*
aws:eks:pod-*IAM is not sufficient — needs eks:DescribeCluster for resolution plus Kubernetes RBAC mapping the FIS role to a k8s group bound to a Role/ClusterRole, plus the cluster "prepared for FIS"eks:DescribeCluster
aws:network:disrupt-connectivity / route-table-* / transit-gateway-*NACL/route-table EC2 actions (e.g. ec2:CreateNetworkAcl, ec2:CreateNetworkAclEntry, ec2:ReplaceNetworkAclAssociation, ec2:DeleteNetworkAcl) — verify the exact set with get-actionec2:DescribeSubnets / ec2:DescribeRouteTables / ec2:DescribeVpcs
aws:ebs:pause-volume-ioec2:<verify with get-action> volume-IO fault permission — do not grant ec2:* (Nitro only)ec2:DescribeVolumes

EKS pod actions are the common trap: IAM alone will not run them. You also need Kubernetes RBAC (map the experiment role into the cluster and bind it to a role that permits the pod operation) and the cluster must be prepared for FIS. Grant eks:* sparingly and lean on k8s RBAC for the actual pod permissions.

Authoritative source (use when an action is not in the table above, or to confirm one that is): run aws fis get-action --id <action-id> and consult How AWS FIS works with IAM and any AWS-managed FIS policies. Do not invent IAM action names for an action whose underlying API you cannot confirm — scaffold the correctly-scoped policy and mark the fault permissions as <verify with get-action> rather than guessing.

Additional permissions per feature

  • Experiment logging — grant FIS vended-logs delivery permissions to the CloudWatch Logs log group and/or S3 bucket you configure.

  • Experiment reports — cloudwatch:GetDashboard, cloudwatch:GetMetricWidgetImage, s3:PutObject, s3:GetObject (scoped to the report bucket/prefix); plus kms:GenerateDataKey, kms:Decrypt if the report bucket uses a customer-managed KMS key.

  • Multi-account — each target account needs its own role that the orchestrator's FIS can assume, with the same confused-deputy conditions and least-privilege target permissions.

Restrict who can start experiments

Starting an experiment is a privileged action. Scope the human/CI principals allowed to call fis:StartExperiment (and template CRUD), ideally with aws:ResourceTag conditions and by template ARN. FIS supports identity-based policies, ABAC (tags in policies), service-specific condition keys, and PassRole controls — use iam:PassRole conditions so only approved experiment roles can be passed to FIS.

Caller iam:PassRole — required

When emitting an experiment role, ALSO emit the caller's PassRole policy. Without it, any caller who can create/update templates can reference any FIS-trusting role in the account.

Rules: Resource = explicit experiment-role ARN(s), never *. Condition iam:PassedToService = fis.amazonaws.com.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": ["arn:aws:iam::123456789012:role/FISExperimentRole"],
    "Condition": {
      "StringEquals": { "iam:PassedToService": "fis.amazonaws.com" }
    }
  }]
}

Bounded blast radius (safety, not just IAM)

  • Always attach a stop condition — a CloudWatch alarm on your steady-state metric. It is the automated kill-switch. {"source":"none"} is acceptable only in a throwaway sandbox.

  • Start narrow — COUNT(1) or a small PERCENT(n), single AZ, pre-production first. Widen only after the experiment passes.

  • Preview targets (actionsMode: skip-all) before a real run to confirm the exact resources.

  • Production requires change management — treat prod fault injection as a change with approval, a run window, and a rollback/stop plan.

  • Empty-target behavior — leave emptyTargetResolutionMode at fail so an over- or under-matching target surfaces immediately instead of silently doing nothing.

Data handling

  • No sensitive data in string fields — template/experiment descriptions, action assertion text, tags, and log/report content surface in CloudTrail, CloudWatch Logs, S3, the console, and (multi-account) target-account AWS Health dashboards. Never embed PII, secrets, or sensitive architecture detail.

  • Encrypt logs & reports — experiment logs and PDF reports reveal resilience posture and architectural weaknesses. Use SSE-KMS on the S3 buckets, enforce TLS with a bucket policy condition on aws:SecureTransport, restrict to a dedicated bucket/prefix, and consider S3 Object Lock on report buckets so evidence can't be altered or deleted.

Auditing

FIS API calls are recorded in AWS CloudTrail (including the actions FIS takes in each target account for multi-account experiments). Review CloudTrail and experiment logs after each run.

Further reading

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
AWS
Publisher
AWS (Official)
Source
aws/agent-toolkit-for-aws · skills/specialized-skills/resilience-skills/aws-fault-injection-service · commit 0a218f8
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download aws-fault-injection-service.zip