66 docs tagged with "aws-faults"

Detach one or more availability zones from an Application Load Balancer for a configurable duration so you can test how clients, target groups, and AZ-aware routing behave when a zone is taken out of the load balancer rotation.

Isolate network traffic for one or more AWS Availability Zones (optionally scoped to specific VPCs or subnets) for a configurable duration and restore connectivity afterwards so you can test how multi-AZ workloads handle a zone-level outage.

Disable one or more availability zones on a Classic Load Balancer for a configurable duration so you can test how clients and back-end instances behave when an AZ is removed from the load balancer rotation.

Pause cross-region replication on one or more Amazon DynamoDB global tables for a configurable duration using an AWS Fault Injection Service (FIS) experiment so you can test how your application handles a brief stop in multi-region consistency.

Detach an EBS volume by volume ID for a configurable duration and reattach it afterwards so you can test how a workload behaves when its storage disappears.

Detach EBS volumes selected by tag for a configurable duration and reattach them afterwards so you can test how workloads behave when a tagged subset of storage disappears.

Stress a configurable number of CPU cores inside a target EC2 instance via AWS Systems Manager so you can test how the workload behaves when the host is starved of CPU.

Block or redirect DNS resolution for selected hostnames on a target EC2 instance via AWS Systems Manager so you can test how the workload reacts when a dependency cannot be resolved.

Add latency to inbound HTTP traffic on a configurable port of a target EC2 instance via AWS Systems Manager so you can test how clients react when an HTTP service responds slowly.

Replace HTTP response bodies on a configurable port of a target EC2 instance via AWS Systems Manager so you can test how clients react when an upstream returns unexpected content.

Add, change, or remove HTTP headers on a configurable port of a target EC2 instance via AWS Systems Manager so you can test how clients react when headers are missing or malformed.

Reset TCP connections to an HTTP service on a configurable port of a target EC2 instance via AWS Systems Manager so you can test how clients react when the server tears down connections mid-flight.

Rewrite HTTP response status codes on a configurable port of a target EC2 instance via AWS Systems Manager so you can test how clients react to specific error codes returned by an upstream service.

Generate sustained filesystem read and write load on a target EC2 instance via AWS Systems Manager so you can test how the workload behaves under disk pressure or near-full storage.

Consume a configurable amount of memory inside a target EC2 instance via AWS Systems Manager so you can test how the workload behaves when the host is starved of memory.

Add configurable latency and jitter to outbound traffic on an EC2 instance via AWS Systems Manager so you can test how the workload reacts when network round-trip times grow.

Drop a configurable percentage of outbound packets on a target EC2 instance via AWS Systems Manager so you can test how the workload reacts when network reliability degrades.

Kill one or more processes by PID inside a target EC2 instance via AWS Systems Manager, so you can test how the workload recovers when a critical process disappears without losing the host.

Stop one or more EC2 instances selected by instance ID for a configurable duration so you can test how the workload running on those instances behaves during and after the outage.

Stop EC2 instances selected by tag for a configurable duration so you can test how the workload running on those instances behaves when a tagged subset disappears.

Stop the ECS container agent on every container instance in an ECS cluster for a configurable duration so you can test how tasks, scheduling, and self-healing behave when the cluster temporarily loses its agent.

Stress a configurable number of CPU cores at a configurable load percentage inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how the workload behaves under sustained CPU pressure.

Add latency to inbound HTTP traffic on a specific port inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how clients behave when the HTTP service responds slowly.

Replace HTTP response bodies on a specific port inside a percentage of running ECS tasks (EC2 launch type) with a configurable string for a configurable duration so you can test how clients behave when the response body is unexpected.

Reset TCP connections to HTTP clients on a specific port after a configurable timeout inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how clients behave when the server abruptly closes the connection.

Return a configurable HTTP status code (and optionally rewrite the body) on a specific port inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how clients behave when the service returns an unexpected status.

Stress filesystem IO using a configurable number of workers writing to a configurable mount path inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how the workload behaves when disk IO is saturated.

Consume a configurable amount of memory (absolute or percentage) using a configurable number of workers inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how the workload behaves under sustained memory pressure.

Add a configurable amount of network latency on a specific interface inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how the workload behaves when the network is slow.

Drop a configurable percentage of network packets on a specific interface inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how the workload behaves when the network is lossy.

Detach the data volume attached to a percentage of running ECS tasks for a configurable duration so you can test how the workload behaves when its storage disappears.

Inject CPU stress inside a percentage of running ECS Fargate tasks for a configurable duration via a sidecar container so you can test how the service behaves under sustained CPU pressure.

Consume a configurable amount of memory inside a percentage of running ECS Fargate tasks for a configurable duration via a sidecar container so you can test how the service behaves under sustained memory pressure.

Stop one or more EC2 container instances that back an ECS cluster for a configurable duration so you can test how the cluster reschedules tasks, drains workloads, and recovers when capacity disappears.

Swap the container image of an ECS service to an invalid value for a configurable duration so you can test how ECS, your deployment guardrails, and your alerting respond to a failed image pull.

Add or remove a network rule (ingress or egress, by IP and port range) for the security group of one or more ECS services for a configurable duration so you can test how the workload behaves when network access is partially restricted.

Force one or more ECS services to a configurable replica count for a configurable duration so you can test how the workload, dependent services, and autoscaling logic behave when capacity is suddenly scaled up or down.

Stop a configurable percentage of ECS tasks (selected by task ID or by service) for a configurable duration so you can test how the service reschedules, how dependent traffic reroutes, and how the workload recovers.

Re-register the task definition of an ECS service with smaller CPU and memory limits for a configurable duration so you can test how the workload behaves when its container resources shrink.

Re-register the task definition of an ECS service with chaos values for container start and stop timeouts for a configurable duration so you can test how the workload behaves when ECS no longer waits long enough for containers to start or drain.

Swap the task role of an ECS service to a chaos value (or empty) for a configurable duration so you can test how the workload behaves when its IAM identity loses or changes permissions.

Trigger any pre-built AWS Fault Injection Service (FIS) experiment template by ID from Harness Chaos Engineering so you can fold native AWS-managed faults into your chaos experiments and probe / verify / report on the result as you do with any other Harness fault.

Block outbound TCP connections from an AWS Lambda function to one or more target hostnames for a configurable duration so you can test how the function behaves when a TCP-based dependency is unreachable.

Delete one or more event source mappings on an AWS Lambda function for a configurable duration and recreate them afterwards so you can test how the workload behaves when the function stops receiving events from its source.

Delete the reserved concurrency configuration on an AWS Lambda function for a configurable duration and restore it afterwards so you can test how the workload behaves when the function has to share account-level concurrency with other functions.

Detach a specified Lambda layer from a target AWS Lambda function for a configurable duration and reattach it afterwards so you can test how the workload behaves when a shared dependency layer disappears.

Inject runtime latency into an AWS Lambda function for a configurable duration so you can test how upstream callers and downstream consumers handle slower-than-expected responses, cold-start spikes, and resource contention.

Override the HTTP status code returned by an AWS Lambda function for a configurable duration so you can test how upstream callers and downstream consumers handle unexpected error status responses.

Override the response body returned by an AWS Lambda function for a configurable duration so you can test how upstream callers and client applications handle unexpected payload shapes and corrupted data.

Disable one or more event source mappings on an AWS Lambda function for a configurable duration and re-enable them afterwards so you can test how the workload behaves when the function temporarily stops receiving events from its source.

Lower the memory allocation of an AWS Lambda function for a configurable duration and restore it afterwards so you can test how the workload behaves with less memory and a proportionally smaller CPU share.

Lower the configured timeout of an AWS Lambda function for a configurable duration and restore it afterwards so you can test how the workload behaves when invocations are cut short.

Detach a specified IAM policy from the execution role attached to an AWS Lambda function for a configurable duration and reattach it afterwards so you can test how the workload behaves when the function loses permission to call a downstream AWS service.

Detach one or more availability zones from a Network Load Balancer for a configurable duration so you can test how clients, target groups, and AZ-aware routing behave when a zone is taken out of the load balancer rotation.

Delete a target RDS DB instance so you can test how applications behave when a database disappears permanently and how disaster-recovery procedures handle the loss.

Reboot a target RDS DB instance (with optional Multi-AZ failover) for a configurable duration so you can test how applications behave when their database restarts.

Temporarily strip ingress or egress rules from one or more AWS security groups for a configurable duration and restore them afterwards so you can test how the workload behaves when network access to (or from) an AWS resource disappears.

Run an arbitrary AWS Systems Manager document against a target EC2 instance selected by ID so you can inject custom chaos that is not covered by a dedicated fault.

Run an arbitrary AWS Systems Manager document against EC2 instances selected by tag so you can inject custom chaos against a logical group of hosts.

Temporarily remove specified CIDR routes from one or more VPC route tables for a configurable duration and restore them afterwards so you can test how the workload behaves when egress to a Transit Gateway, NAT Gateway, VPC peer, or internet gateway disappears.

Blackhole all network traffic destined for specific IPs or hosts on one or more Windows EC2 instances (selected by ID or tag) for a configurable duration so you can test how Windows-hosted workloads behave when a specific dependency is completely unreachable.

Stress a configurable number of CPU cores at a configurable percentage on one or more Windows EC2 instances (selected by ID or tag) for a configurable duration so you can test how Windows-hosted workloads behave under sustained CPU pressure.

Consume a configurable amount of memory (absolute or percentage) on one or more Windows EC2 instances (selected by ID or tag) for a configurable duration so you can test how Windows-hosted workloads behave under sustained memory pressure.

Add a configurable amount of latency to network traffic destined for specific IPs or hosts on one or more Windows EC2 instances (selected by ID or tag) for a configurable duration so you can test how Windows-hosted workloads behave when the network is slow.

Drop a configurable percentage of network packets destined for specific IPs or hosts on one or more Windows EC2 instances (selected by ID or tag) for a configurable duration so you can test how Windows-hosted workloads behave when the network is lossy.

Kill one or more processes (selected by PID or process name) on one or more Windows EC2 instances (selected by ID or tag) for a configurable duration so you can test how Windows-hosted workloads behave when their backing processes die.