In this section, we will discuss approaches for implementing high availability in the application and data tiers in the application architecture.
In the application layer, we can do a cold start from pre-configured images or a warm start from scaled down instances for the web servers and application servers in a secondary region. By leveraging auto-scaling we can quickly ramp up these servers to handle full production loads. In this configuration you would deploy the web servers and application servers across multiple AZs (in the primary region) and the standby servers in a separate, secondary region. The standby servers need not be launched till you actually need them. However, you should keep the preconfigured AMIs for these servers ready-to-launch in your secondary region.
The data layer can comprise of SQL databases, NoSQL databases, caches, and so on. These can be AWS managed services such as RDS, DynamoDB, and S3, or your own SQL and NoSQL databases like Oracle, SQL Server, or MongoDB running on EC2 instances. AWS services come with HA built-in while using self-managed database products running on EC2 instances offers a do-it-yourself option. It can be advantageous to use AWS services, if you want to avoid taking on database administration responsibilities. For example, with the increasing sizes of your databases you might choose to shard your databases may be easy for you to do. However, re-sharding your databases while accepting live traffic can be a complex undertaking and present availability risks. Choosing to use AWS DynamoDB service in such situations, offloads the work to AWS thereby resulting in higher availability out-of-the-box.
Next, we discuss some data replication options.
DynamoDB automatically replicates your data across several AZs to provide higher levels of data durability and availability. In addition, you can use data pipelines to copy your data from one region to another. DynamoDB streams functionality that can be leveraged to replicate to another DynamoDB in a different region. For very high volumes, low-latency Kinesis services can also be used for this replication across multiple regions distributed all over the world.
You can also enable the multi-AZ setting for the AWS RDS service to ensure that AWS replicates your data to a different AZ within the same region. In the case of Amazon S3, the S3 bucket contents can be copied to a different bucket and the failover managed on the client side. Depending on the volume of data, always think in terms of multiple machines, multiple threads, and multiple parts to significantly reduce the time it takes to upload data to S3 buckets.
While using your own database (running on EC2 instances), use your database-specific high-availability features for within and cross-region database deployments. For example, if you can leverage your databases' replication features for synchronous and asynchronous replication across the nodes. If the volume of data is high, then you can also upload your data to Amazon S3 and restore the data to your database instance on AWS. You can also replicate your non-RDS databases (on-premise or on AWS) to AWS RDS databases. You will typically define two nodes in the primary region with synchronous replication and a third node in the secondary region with asynchronous replication. NoSQL databases, such as MongoDB and Cassandra, have their own asynchronous replication features that can be leveraged for replication to a different region.
In addition, you can create Read Replicas for your databases in other AZs and regions. In this case, if your master database fails followed by a failure of your secondary database, then one of the read replicas can be promoted to being the master. In hybrid architectures where you need to replicate between on-premise and AWS data sources, you can do so through a VPN connection between your data center and AWS. In case of any connectivity issues, you can also temporarily store pending data updates in SQS and process them when the connectivity is restored.
Usually, data is actively replicated to the secondary region while all other servers like the web servers and application servers are maintained in a cold state to control costs. However, in cases of high availability for web-scale or mission critical applications, you can also choose to deploy your servers in active-active configuration across multiple regions.