FIS and Database Workloads

Yes, AWS Fault Injection Service (FIS) can be used to realistically simulate storage issues on database workloads.

For Amazon EBS volumes, which are commonly used for database storage, FIS offers specific actions to test storage fault scenarios:

1. Latency injection action - This simulates degraded I/O performance on EBS volumes, allowing you to observe how latency-sensitive database applications like Oracle, SAP HANA, and Microsoft SQL Server respond to storage performance issues. It replicates real-world signals such as CloudWatch alarms and operating system timeouts.

2. Pause I/O action - This helps test how your database applications handle I/O interruptions.

For database services specifically, AWS FIS integrates with Amazon Aurora DSQL to simulate connection disruptions:

• You can create scenarios where applications need to handle connection disruptions or complete inaccessibility to an Aurora DSQL cluster in an AWS Region.
• For multi-Region Aurora DSQL deployments, you can test failures in one region (like elevated cluster connection error rates) while another region continues normal operations.

These controlled experiments allow you to:

• Validate application error handling and recovery mechanisms
• Test multi-Region application behavior and traffic shifting
• Fine-tune monitoring and recovery processes
• Integrate resilience testing into your CI/CD pipelines

The experiments can be customized to meet application-specific testing needs, and you can generate detailed reports for audit and compliance purposes.
Sources
What's New at AWS - Cloud Innovation & News
Resilience in Amazon Aurora DSQL - Amazon Aurora DSQL
What's New at AWS - Cloud Innovation & News
Fault testing on Amazon EBS - Amazon EBS

Yes, AWS Fault Injection Service (FIS) can be used to realistically simulate storage issues on database workloads. Here's how it works:

Storage Fault Injection Capabilities AWS FIS provides several mechanisms to simulate storage disruptions on database workloads

I/O Latency Injection — Inject configurable read/write latency on Amazon EBS volumes to simulate degraded storage performance. You can specify exact latency values (e.g., 3ms for small I/O, 10ms for large I/O) and the percentage of transactions affected. Pause I/O Action — Completely stall all I/O operations on EBS volumes to simulate total storage unavailability. Multi-Attach Volume Support — Run experiments on Multi-Attach enabled volumes used by clustered databases.

Database-Specific Use Cases Amazon RDS — Simulate failover events, test Multi-AZ recovery, and validate connection handling during storage disruptions. Amazon ElastiCache — Conduct controlled fault injection experiments on cache workloads. Self-managed databases (Oracle, PostgreSQL, SQL Server, Cassandra on EC2) — Test how database engines respond to degraded storage conditions.

**Database failover mechanisms and automatic recovery *** Transaction rollback procedures under degraded I/O

• Timeout configurations and connection pooling behavior
• Query performance under delayed storage conditions
• SLA compliance under increased latency
• Monitoring and alerting accuracy during incidents

**Safety Controls **FIS includes built-in guardrails — you can configure CloudWatch alarm-based stop conditions to automatically halt experiments if metrics exceed defined thresholds (e.g., stop if volume latency exceeds 3ms).