Great question—this is a classic tradeoff between performance and high availability that many AWS/Laravel developers face. Let’s break down the most practical solutions to fix your slow app while keeping everything resilient:

1. Implement RDS Read Replicas + Application-Level Read/Write Separation #

Since your RDS is Multi-AZ (eu-west-1b as primary, eu-west-1a as standby), the standby instance is only used for failover and can’t handle read traffic normally. Here’s how to fix that:

• Create RDS Read Replicas in each AZ where your EC2 Auto Scaling Group (ASG) runs (so one in eu-west-1a, matching your existing EC2 AZ).
• Configure your Laravel app to split database traffic:
  • Send all write operations (creates/updates/deletes) to the RDS primary endpoint (still in eu-west-1b—write traffic is usually a small percentage of total traffic, so cross-AZ latency here is negligible).
  • Route read operations (selects) to the read replica endpoint for the same AZ as the EC2 instance running the request.
• Laravel makes this easy: you can define multiple database connections in config/database.php, then use DB::connection('read') for read queries, or use custom middleware to auto-route read traffic to replicas.

This way:

• Your EC2 ASG stays multi-AZ (eu-west-1a + eu-west-1b) for high availability.
• Read traffic gets low-latency, same-AZ connections to RDS replicas.
• Your RDS Multi-AZ setup still provides failover protection if the primary AZ goes down.

2. Upgrade to Amazon Aurora MySQL (Simpler Multi-AZ Performance) #

If you’re open to switching from standard RDS MySQL, Amazon Aurora is a game-changer here:

• Aurora is natively multi-AZ, with read replicas automatically deployed across AZs (you can add replicas in eu-west-1a and eu-west-1b).
• The Aurora Reader Endpoint automatically routes read traffic to the closest available read replica in the same AZ as your EC2 instance—no manual routing needed.
• Aurora’s replication is near-real-time (sub-100ms latency) compared to standard RDS replicas, so read consistency is rarely an issue.
• Failover is much faster (usually <30 seconds) than standard RDS Multi-AZ, which boosts overall resilience.

For Laravel, the setup is almost identical to standard MySQL—you just update your database connection string to use the Aurora endpoints.

3. Avoid the "Single AZ Lock-In" Trap #

Your original concern is totally valid: if you move all EC2 instances to the same AZ as RDS primary, you lose multi-AZ redundancy. If that AZ experiences an outage, both your app servers and database go down at the same time—defeating the purpose of Multi-AZ RDS.

By using either read replicas (with standard RDS) or Aurora, you get the best of both worlds:

• EC2 runs across multiple AZs to avoid single points of failure.
• Most database traffic (reads) uses same-AZ connections for low latency.
• RDS/Aurora maintains multi-AZ failover for critical write operations.

Quick Laravel Configuration Tip #

To set up read/write separation in Laravel, update your config/database.php like this:

'mysql' => [
    'driver' => 'mysql',
    'url' => env('DATABASE_URL'),
    'host' => env('DB_HOST'), // Primary RDS endpoint
    'database' => env('DB_DATABASE'),
    'username' => env('DB_USERNAME'),
    'password' => env('DB_PASSWORD'),
    // ... other settings
],

'mysql_read' => [
    'driver' => 'mysql',
    'url' => env('DATABASE_READ_URL'), // Read replica endpoint for the EC2's AZ
    'host' => env('DB_READ_HOST'),
    'database' => env('DB_DATABASE'),
    'username' => env('DB_USERNAME'),
    'password' => env('DB_PASSWORD'),
    // ... other settings
],

Then, in your code, use DB::connection('mysql_read')->select(...) for read queries, or create a base model that automatically uses the read connection for select operations.

内容的提问来源于stack exchange，提问作者rodders