Cross Region Disaster Recovery

8. Click Create database after swiping to the bottom.
Create an IAM Role

The IAM Role that will be used to access the secret from AWS Secrets Manager will now be created.
1. Go to the “Policies” section of the IAM console.
2. Create a new policy. Click the JSON button and replace the existing JSON code with the contents of the “dc-php-webapp-webserver-secrets-access.json” file.
3. Give “dc-php-webapp-webserver-secrets-access” the name of your policy. To create a policy, click.
4. Select “Roles” from the menu on the left, and then select “Create role.” Choose the recently established policy and choose EC2 as the use case. Put “dc-php-webappwebserver-secrets-access-role” as the name of your role.
5. Select “Create.”

To set up database tables, launch the first instance from the public shared AMI

(us-east-1)

The first EC2 instance in the main region (us-east-1) will now be launched, and we will use it to create the first table and connect to the database. Later on, we will create a unique AMI using this instance.

1. Select “Launch instance” from the EC2 console.
2. This will be referred to as “dc-php-webapp-ami.”
3. Select “Browse more AMIs” and navigate to “Community AMIs” for the AMI.
4. Look for the AMI “ami-00172f2f108369fb3.” Choose this AMI.
5. Select “proceed without a key pair” under “Key pair.”
6. Choose the “dc-php-webapp-webservers-sg” security group under “Select existing security group” in the network settings. If the default security group is there, remove it.
7. Choose the IAM role we previously created under Advanced information and IAM instance profile, and then click Launch instance.
8. After your instance has been launched and is operating, use EC2 instance connect to connect to it.
9. To install MySQL and update the instance, use the next two commands:

sudo yum update -y

10. We can now establish a database connection. Run the following command, adding the database endpoint at the center. mysql -h dc-php-webapp-database.c3vhkquoiapy.us-east-1.rds.amazonaws.com -u admin -p
11. Enter your password and connect. Which is the password we established when we created the database

12. We must now build the tables in the database named sample; use sample; 12. To do this, run the SQL query that follows:
(id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY, ordernumber VARCHAR(30) NOT NULL, customername VARCHAR(30) NOT NULL, address VARCHAR(150) NOT NULL, item VARCHAR(50) NOT NULL, price DECIMAL(10,2) NOT NULL, date TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP);
13. The read replica can now be launched in the secondary Region (us-west-2)

Create the same security groups in us-west-2 from

We are going to create the same security groups we created earlier but in us-west-2 go to the EC2 management console and select Security Groups from the menu on the left.

2. Select “Security Group Creation.”
3. name it ‘dc-php-webapp-webservers-sg’ to reach the Security Group.
4. Create within the default VPC
5. Include the following two rules: SSH from anywhere and HTTP from anywhere (IPv4).
6. Select “Create.”
7. In the default VPC, create a second security group called “dc-php-webapp-dbservers-sg.”
8. Add “MySQL/Aurora” port 3306 to the inbound rule, with the Web server security group we previously configured serving as the source.
9. Select “Create.”

Create a read replica of the main database in the secondary Region (us-west-2)

1. Go back to the RDS database you established in the main Region (us-east-1)
2. After choosing the database, select “Actions” and then “Create read replica.”
3. Enter “dc-php-webapp-database-west” as the “DB instance identifier.”
4. Choose “US West (Oregon)” as the secondary region under AWS Region. A few moments will pass before the console refreshes.
5. Select 20 GiB for Allocated storage under Storage.
6. Choose Single DB instance under Availability.
7. Select “Generate Read Copy.”
8. To ensure that your read replica is being deployed, check the RDS console in the us-west-2 Region.

Create a Secret within Secrets Manager

To store the database parameters, we will now establish a Secret in AWS Secrets Manager. This will make it simple for us to switch laterally between the Primary and Secondary regions.

1. Click “store a new secret” in the AWS Secrets Manager console located in us-east-1.
2. Under “Credentials for Amazon RDS database,” Select the database instance that we previously built, enter your user name and password that we previously configured and click the next button.

3. Enter “dc-php-webapp-db-secret” as the name
4. Store your secret and leave all other settings as they are.

Build a custom AMI from the currently launched instance

1. Open the Amazon EC2 console.
2. Select your instance by clicking on “Instances” in the navigation bar, and then click on “Actions,” “Image and templates,” and “Create image.”
3. Name your image “dc-php-webapp-image,” check the box next to “No reboot,” and click Create image on the Create image screen.

Copy the AMI from us-east-1 to us-west-2

1. Select AMIs from the EC2 console.
2. Choose your AMI after its status is available. Click the Actions menu and choose “Copy AMI.” Choose “US West (Oregon)” as the destination region.

Create the Launch Configuration.

We will build an application load balancer, an auto scaling group, and a launch template
in this assignment.

1. Select “Launch Templates” in the EC2 management console, followed by “Create launch template.”
2. Type “EastFailoverTemplate” as the launch template name.
3. Click “My AMIs” under “Application and OS Images” and choose the previously produced AMI.

4. Choose the instance type t2.micro, proceed without a key pair, and select the security group ‘dc~php-webapp-webservers-sg’.
5. Assign the IAM role “dc-php-webapp-webserver-secrets-access-role.”
6. Choose “Create launch template”

Create the Auto Scaling group.

Next, we use the Launch Configuration as a template to establish the Auto Scaling Group.

1. Select “Create Auto Scaling group” under Auto Scaling Groups.
2. In the default VPC, type the name “EastASG,” pick the launch template, and select the default public subnets, us-east-1a and us-east-1b.
3. Select “No load balancer” by clicking next, then click next once again. At this point, the value 2 will be added to each choice.

4. Go ahead to create the Auto Scaling group and review. Two instances should be launching at this point in the EC2 console.

Create an Application Load Balancer

1. First, build an application load balancer called “EastALB,” make sure it is internet facing , choose the public subnets us-east-1a and us-east-1b, and use the webserver security group we previously created.
2. Set up a target group on port 80 and HTTP, then register the instances that the ASG launched. Those should be the two cases without a name.
3. Go back to your load balancer, pick the new target group, and press the “Create load balancer” button.
4. You may verify that your application functions once your load balancer has been properly supplied.

Open a web browser and copy the load balancer’s DNS name. This page should be
seen by you:

5. Select “Create” and enter the order details.
6. After that, select “View results,” and the order details you supplied ought to appear.

This is being taken straight out of the RDS MySQL database.

Create the failover routing policy.

The load balancer in the primary region will now be designated as the primary target when we build the failover policy; the failover region will be added in the following stage.

1. Select “Hosted zones” from the Route 53 console.
2. Locate the desired public hosted zone and select “Create Record.”
3. Using failover routing and designating this Application Load Balancer as the primary, we must establish an Alias record referring to the Application Load Balancer located in us-east-1.
4. In addition, we have to build a health check; click the console link by selecting the “info” link that appears next to the health check ID.
5. A new tab will open for you and you will see the health check console:

6. Select “Create Health Check.”
7. Select the “monitor and endpoint” tab, call the health check “Eastern health check,” and provide the DNS name of our load balancer, which is situated in us-east-1.

8. skip the creation of SNS topic, create the health check.
9. The health check should now be able to be included in the failover record.
10. Click “Create Record” after naming it “Primary” under Record ID.

11. You should now be able to use your public DNS domain name to connect to the application.

Create the Launch Template, Auto Scaling Group and Application Load Balancer

1. Switching to the us-west-2 Region, we will follow the same steps we did when we first created the Launch Template, ASG and ALB in us-east-1. once again until the primary and failover regions have the same infrastructure. We will replace “East” with “West” in all names
2. This will contain the Launch Template, ASG, ALB, and Security Groups. The duplicated AMI will be used for the launch template.

Add the secondary region to the failover policy.

We will now complete the development of the failover policy for Route 53.

1. Using the same steps as before, we must also build a second health check called “Western Health Check” that points to the load balancer in the secondary area.
2. Next, navigate to Route 53 and select Create Record beneath the Hosted Zone that we previously utilized. Using the same record name as the primary ALB record, create an alias to the secondary ALB.
3. Choose the us-west-2 load balancer, set up failover routing, and select “Secondary” for the failover record type. Add the recently generated health check ID.
4. Click “ create record ”

Promote the read replica and delete the primary database.

After the primary database is deleted, the read replica will be promoted to the secondary region.
1. Locate the RDS console in the main Region (us-east-1).
2. Click “Delete” after selecting the Database.
3. We can check the box confirming deletion and decide not to maintain any backups.
4. You should observe the database connection from your URL timing out after a brief while.
5. Now that we are in the us-west-2 Read Replica, we can After highlighting it, select “Promote” from the actions menu. Then, select “promote Read Replica” on the following page.

Update the secret in Secrets Manager

In order to reflect the promotion of the read replica to the primary database, we should update the secret.

1. Locate your secret by going to the secrets manager.
2. Select “retrieve secret value” under “secret value” and make changes.
3. To reflect the database change, you must edit the “host” and “dbidentifier” sections.
4. Your database’s endpoint is referred to as the host, and the RDS console includes the dbidentifier.

5. Save the changes that were made. Now, the US-West-2 Region’s application should be able to establish a connection with the database.

Delete the Auto Scaling Group

The auto scaling group in the primary Region (us-east-1) will now be deleted. This will result in a failover and a health check failure.

1. Find the Auto Scaling group by traveling to the main region.
2. Delete it; doing so will end the instances and remove all targets from the load balancer’s path.
3. When you enter the us-east-1 Load Balancer’s URL in your browser, you should see this in action.

4. Since the resources hosted in us-west-2 are the only resources behind the domain name, we should still be able to access the website using the domain name. If we are able to do so, the failover was successful.