Introduction to AWS Fault Injection Service (FIS)
As a part of AWS Resilience Hub, AWS Fault Injection Service is a fully managed service for running fault injection experiments to improve an application’s performance, observability, and resilience. Fault injection is based on the principles of chaos engineering. These experiments stress an application by creating disruptive events so that you can observe how your application responds. You can then use this information to improve the performance and resiliency of your applications so that they behave as expected. AWS Fault Injection Service simplifies the process of setting up and running controlled fault injection experiments across a range of AWS services, so teams can build confidence in their application behavior.
To measure resilience, these AWS FIS experiments simulate disruptions to your AWS resources. Examples of disruptions include network unavailable errors, failovers, stopped processes on Amazon EC2 or AWS ASG, boot recovery in Amazon RDS, and problems with your Availability Zone. When the AWS FIS experiment concludes, you can estimate whether an application can recover from the outage types defined in the RTO target of the resiliency policy.
All the experiments in AWS Resilience Hub are built using AWS FIS and they execute AWS FIS actions. AWS FIS experiments use only AWS FIS automation actions that are customized to specific AWS services. For more information about AWS FIS actions, see AWS FIS actions reference.
AWS FIS Concepts
AWS Resilience Hub simplifies AWS FIS experiments by integrating with AWS FIS experiments. It provides tailored recommendations and allows initiating AWS FIS experiments with pre-populated templates mapped to your Application Components (AppComponents), enabling efficient resilience testing. For more information, see Initiating, creating, and running AWS FIS experiments.
To use AWS FIS, you run experiments on your AWS resources to test your theory of how an application or system will perform under fault conditions. To run experiments, you first create an experiment template. An experiment template is the blueprint of your experiment. It contains the actions, targets, and stop conditions for the experiment. After you create an experiment template, you can use it to run an experiment. While your experiment is running, you can track its progress and view its status. An experiment is complete when all of the actions in the experiment have run.
Chaos Engineering for Serverless applications on AWS
Below is the list of the 3rd party resources and tools already available for AWS Lambda:
Introducing AWS Fault Injection Service Actions to Inject Chaos in Lambda functions
In November 2024 AWS introduced AWS Fault Injection Service Actions to Inject Chaos in Lambda functions.
AWS FIS now injects faults into AWS Lambda functions using a “chaos” Lambda extension that runs as a separate process within the Lambda execution environment, intercepting invocations before they reach the runtime.
With the launch of FIS Lambda actions, the following three actions are now available to us in the FIS experiment templates:
- Add start delay: aws:lambda:invocation-add-delay
- Modify integration response: aws:lambda:invocation-http-integration-response
- Enforce invocation errors: aws:lambda:invocation-error
See AWS FIS aws:lambda:function actions for a more detailed description of these actions.
Conclusion
In this part of the series, we gave the introduction to the AWS Fault Injection Service (FIS) in general, explored what 3rd party services or tools are already available for AWS Lambda and introduced the recently announced AWS Fault Injection Service Actions to inject chaos into Lambda functions. In the next parts of the series, we'll use our sample serverless application to demonstrate all three actions (add start delay, modify integration response, and enforce invocation errors) available in the FIS experiment templates to inject chaos into Lambda function.
Sources :
Top comments (0)