Behind the application we are likely to find a database cluster of some sort. For this example, we have chosen RDS (MySQL/PostgreSQL). However, the scaling and resilience ideas can be easily translated to suit a custom DB cluster on EC2 instances.

Starting with high-availability, in terms of RDS, the feature is called a Multi-AZ deployment. This gives us a Primary RDS instance with a hot STANDBY replica as a failover solution. Unfortunately, the Standby cannot be used for anything else, that is to say we cannot have it, for example, serving read-only queries.

A Multi-AZ setup within our VPC would look like this:

In the case of a PRIMARY outage, RDS automatically fails over to the STANDBY, updating relevant DNS records in the process. According to the documentation, a typical failover takes one to two minutes.

The triggers include the Primary becoming unavailable (thus failing AWS health-checks), a complete AZ outage, or a user interruption such as an RDS instance reboot.

So far, with Multi-AZ we have a reasonably resilient, but perhaps not very scalable setup. In a busy environment it is common to dedicate a primary DB node for writes, while reading is done off of replicas. The inexpensive option would be to add a single replica to our current arrangement:

Here we write to PRIMARY and read from REPLICA, or for read-intensive applications reads can go to both.

If our budget allows, we can take this a step further and provide a REPLICA in both subnets in which we deploy frontend/application nodes:

Latency across AWS zones is already pretty low, but with such a per-zone RDS distribution, we reduce it even further. All hosts would write to the PRIMARY. However they can assign a higher priority to their local (same zone) REPLICA when reading.

And since we are on a spending spree, additional RDS performance boost can be gained with provisioned IOPS. This is something to consider if you are running a heavy workload and in need of high RDS Storage I/O.

Although indirectly, caching is another very effective way to increase RDS scalability by alleviating the load.

Popular software choices here are Memcached and Redis. Either is simple to setup locally (on each application host). If you would like to benefit from a shared cache then you could run a cluster on EC2 or use the AWS managed ElastiCache service. With the latter, we can have again a Multi-AZ configuration plus multiple replicas for resilience and low-latency:

You will notice that the failover scenario differs from RDS in that there is no standby instance. In the event of a PRIMARY failure ELASTICACHE promotes the most up-to-date REPLICA instead.