AWS: How to set up disaster recovery for ec2 instances in 2 VPCs?

Question

What I have:

• One VPC with 2 EC2 Ubuntu instances in it: One with phpmyadmin, another one with mysql database. I am able to connect from one instance to another.

What I need to achieve:

• Set up the Disaster recovery for those instances. In case of networking issues or if the first VPC is not available for any reason all requests sent to the first VPC are redirected to the second one. If I got it right it can be achieved with VPC endpoints. Cannot find any guide on how to proceed with this. (I have 2 VPCs with 2 ec2 instances in each of them)

Edit:

• Currently I have 2 VPC with 2 EC2 instances in each of them.
• Yes, ideally I need to have 2 databases running and sync the date between them. Not it is just 2 separate db instances with no sync.
• First ec2 instance in each VPC has web app running. So external requests to the web app should be sent to the first VPC if it is available and to the second VPC if smth is wrong with the first one. Same with the DBs: if DB instance in the first VPC is available - web app requests should update data in this DB. If not requests should access the data from the second DB instance

Answer 1

In addition to the previous answers, you might wanna take a look in migrating your DBs to RDS or Aurora.

It would provide HA for your DB tier via multi-AZ configuration, and you would not have to figure out how to sync the data between the databases.

That being said, you also have to decide what level of availability is acceptable for you:

• multi AZ - data & services span across multiple data centers in one region -> if the whole region goes down, your application goes down.
• multi region - data & services span across multiple data centers in multiple regions -> single region failure won't put you out of business, but it requires some more bucks & effort to configure

Answer 2

Traditionally, Disaster Recovery (DR) involves having a secondary copy of 'everything' (eg servers in a different data center). Then, if something goes wrong, failover would involve pointing to the secondary copy.

However, the modern cloud emphasises High Availability rather than Disaster Recovery. An HA architecture actually has multiple systems continually running in separate Availability Zones (AZs) (which are effectively Data Centers). When something goes wrong, the remaining systems continue to service requests without needing to 'failover' to alternate infrastructure. Then, additional infrastructure is brought online to make up for the failed portion.

High Availability can also operate at multiple levels. For example:

• High Availability for the database would involve running the database under Amazon RDS "Multi-AZ" configuration. There is one 'primary' database that is servicing requests, but the data is being continually copied to a 'secondary database in a different AZ. If the database or AZ should fail, then the secondary database takes over as the primary database. No data is lost.
• High Availability for web apps running on Amazon EC2 instances involves using a Load Balancer to distribute requests to Amazon EC2 instances running in multiple AZs. If an instance or AZ should fail, then the Load Balancer will continue serving traffic to the remaining instances. Auto Scaling would automatically launch new instances to make up for the lost capacity.

To compare:

• Disaster Recovery is about having a second set of infrastructure that isn't being used. When something fails, the second set of infrastructure is 'switched on' and traffic is redirected there.
• High Availability is all about continually handling loads across multiple Data Centers (AZs). When something fails, it keeps going and new infrastructure is launched. There should be no 'outage period'.

You might think that running multiple EC2 instances simultaneously to provide High Availability is more expensive. However, each instance would only need to handle a portion of the load. A single 'Large' instance costs the same as two 'Medium' instances, so splitting the workload between multiple instances does not need to cost more.

Also, please note that VPCs are logical network configurations. A VPC can have multiple Subnets, and each Subnet can be in a different AZ. Therefore, there is no need for two VPCs -- one is perfectly sufficient.

VPC Endpoints are not relevant for DR or HA. They are a means of connecting from a VPC to AWS Services, and operate across multiple AZs already.

See also:

• High availability is not disaster recovery - Disaster Recovery of Workloads on AWS: Recovery in the Cloud
• High Availability Application Architectures in Amazon VPC (ARC202) | AWS re:Invent 2013 - YouTube