In this video, you'll see Part 2 of how you can manage application resilience with AWS Resilience Hub.
In Part 2 of this three-part demonstration, you’ll learn how to set up recommended alarms,
implement Standard Operating Procedures (SOPs), and run an experiment from an SOP.
We’ll begin in AWS Resilience Hub, where we are looking at an assessment report for our Unicorn Store application.
We ran the assessment in Part 1 of this demonstration.
At this point in time, we have implemented all of the resiliency recommendations from the assessment.
Now we’ll review the operational recommendations.
Resilience Hub recommends alarms, SOPs,
and fault injection experiments that can help improve the resiliency of an application.
In this case, 16 alarms are recommended.
As you can see in the Description column, the alarms report when certain thresholds are too high or low.
We'll add all these alarms to our application code using an AWS CloudFormation template.
When the template is created, we can access it from a link on the Templates tab.
The link will take us to the Amazon Simple Storage Service (Amazon S3) bucket with the template.
In the "alarm/" folder we’ll find the JSON file that was created to locate the object URL.
If we were to create a new CloudFormation stack, we'd copy the Object URL to use in that process.
Now we'll go to AWS CloudFormation.
Here we can create a new stack or use an existing one.
For this Resilience Hub demonstration, we'll use a stack we previously prepared called
"AlarmRH" that leverages the Object URL we just copied a moment ago.
In the stack Resources tab, we can see that the alarms we selected have been created.
Let's also go to Amazon CloudWatch to see if the alarms are set up there.
We can see that the alarms are enabled.
Next, let's return to AWS Resilience Hub to review the recommended SOPs.
An SOP is a prescriptive set of steps designed to efficiently recover your application in the event of an outage or alarm.
We'll implement two: the “Restore from RDS Backup” SOP and the “Reboot EC2 Instance” SOP.
Let's create a CloudFormation template for adding the SOPs to our application code.
We'll name and create the template.
Let's navigate to the SOP template on Amazon S3 and copy the object URL.
Next, let's return to CloudFormation and create a new stack.
We’ll paste the object URL here.
Let's proceed.
Let's name the stack.
Next, we'll add a Resilience Hub canary alarm to our template parameters.
We'll retain the default configuration.
Let’s create the stack.
With the stack creation complete, let’s return to Resilience Hub and make sure the SOPs have appeared.
We can see the two SOPs.
Next, we'll run them.
Let's start with the Reboot EC2 Instance SOP.
Resilience Hub works with AWS Systems Manager to automate the steps of your SOPs.
We can review the automation steps in this document.
Let’s execute the automation.
We'll need to provide the EC2InstanceIdentifier.
Let’s go to Amazon Elastic Compute Cloud (Amazon EC2) to find the instance.
We’ll select the instance corresponding with the SOP and copy its Instance ID.
Returning to Systems Manager, we'll paste in the ID.
AWS Resilience Hub has automatically created an AWS Identity and Access Management (IAM) role
for implementing the SOP.
Let's find the name of the CloudFormation stack we built and select it.
Now we can execute the automation.
Let's go to our EC2 instances and refresh the page.
Now let’s return to Systems Manager and review the automation execution.
The automation was successful.
All five execution steps were completed.
Back in EC2, we can see the instance is running.
Let's return to Resilience Hub and look at the second SOP.
This SOP is for restoring Amazon RDS from backup.
Again, we can review the automation steps in an SSM document.
Let's execute the automation.
Let’s search for the IAM role that Resilience Hub has automatically created for implementing the SOP.
Next, let's provide the identifier of the database instance we want to perform this automation on.
That identifier can be found on the Databases page of the AWS RDS Console.
For this demonstration, we've already copied the identifier we need and we'll paste it here now.
Now we can execute the automation.
Let's go to our database instance in Amazon RDS.
We can refresh this page to monitor the database status as the automation script executes its steps.
Next, let's go to Systems Manager to see the script’s progress.
We can see which steps have been executed so far.
In a moment, the new database will be available.
Let’s return to Amazon RDS.
We can see the new database iteration is available.
Returning to Systems Manager, we can see that the next step is to rename the previous database to “old.”
Back in Amazon RDS, let's refresh the progress.
Now the replacement database has inherited the original's name, and the original has become the secondary database.
We'll refresh the execution progress in Systems Manager.
So far, 9 steps have completed successfully, with the 10th step in progress.
Next, we'll see the new database renamed.
With the renaming of the second database, restoration to the backup database is now complete.
With another refresh, we see that the backup database is rebooting.
Now, in the last step of the SOP automation, the backup database is being deleted.
This SOP is working as it should.
We can rerun the experiment periodically to ensure ongoing resiliency for our application.
You've just seen Part 2 of how you can manage application resilience with AWS Resilience Hub.
You can learn more about this topic in the description and links for this video.
Thanks for watching. Now it's your turn to try.