This is something we have looked at a few times since we moved to AWS EC2 in 2012. So far we have not seen a way to make it work for our applications. For scale-out, our applications need to access a consistent set of data on all scale-out servers. Getting this set up and verified would take a number of hours even if everything was fully scripted. The main pain point is synchronising data on the auto-scale server with what is on the master server.

The only use cases that makes any sense is to auto scale for databases that only contain transient data or only contain static data. Any data set that needs to be permanent and can change as time goes by is not a suitable candidate for auto scale. None of our data fits these use cases.

The approach we have adopted for SQL Server is to host the database servers in multiple AZs, use P2P replication to maintain master data across the AZs, and use transactional replication to distribute data to permanent scale-out servers within each AZ. We load-balance our workload across all the AZs, but maintain enough SQL Server capacity in each AZ to meet 100% of our workload if a given AZ became unusable. We accept there are periods each day where not all SQL Server instances are needed, but for us the cost of refactoring how our applications work to be able to auto-scale the database tier does not make business sense.