In this video, you'll see Part 1 of how you can manage application resilience with AWS Resilience Hub.
In Part 1 of this three-part demonstration, you’ll learn how to publish your application
resources and resiliency policy, run a resiliency assessment, and act on resiliency recommendations.
This is AWS Resilience Hub, which we have already set up with our AWS accounts and required
AWS Identity and Access Management (IAM) permissions.
As you can see, we haven’t published any applications yet.
Before we show how to publish an application, let’s go to AWS CloudFormation
and view the template for the application we’ll add.
Our application is called "Unicorn Store."
The stack has four outputs.
These outputs comprise our ”Unicorn Store” application.
This application is a full-service commerce website.
Let’s return to Resilience Hub and add the application.
We'll use our CloudFormation stack to define the application's structure.
Let's name the application and move on to the next step.
Our stack has imported and now Resilience Hub is discovering its resources.
We'll select all resources for inclusion and continue.
Next, we'll select a resiliency policy for the application.
Resiliency policies define the Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
used to measure an application's resiliency to certain disruption types.
We can create a policy from scratch or use one of the suggested policies.
Suggested policies include tiers for foundational IT core services,
mission-critical, critical, important, and non-critical applications.
Let's go back.
For the purposes of this demonstration, we have already prepared a "mission critical" policy for this application.
The policy defines an RTO and RPO of five minutes for infrastructure and Availability Zone recovery.
With the policy selected, let’s move on.
When we review our selections, we can see additional details of the resiliency policy.
Let's publish the application.
Now we can view our application within Resilience Hub.
This page captures a summary review of the application's resiliency, as well as the resources being assessed.
We can also see versions of the application resources and view reports for resiliency assessments.
Let’s run an assessment now.
We’ll retain the default name for the report.
It takes a few moments for the assessment to complete.
Our application has a compliance status of "policy breached."
Let's review the assessment.
Some components achieved the RTO and RPO targets, but others exceeded policy targets or were unrecoverable.
Here, we can see which application components were unrecoverable.
Here, we can see that RPO targets for infrastructure passed, but two RTO targets were missed by 25 minutes.
The same targets were missed for the Availability Zone.
Let’s look at the resiliency recommendations.
AWS Resilience Hub evaluates our application components and recommends how to optimize them for
the lowest RTO and RPO during an Availability Zone disruption, for the lowest cost, and for minimal changes.
For example, for our compute component, all three optimization categories recommend adding
an Auto Scaling group in a different region.
For our database component, the recommendations vary by category.
To optimize the Availability Zone, for instance, we can add read replica in the same region,
change to Aurora, and enable cluster backtracking.
Or, for a lower cost or minimal changes, we can enable the instance for multiple Availability Zones.
For both storage components, the across-the-board
recommendation is to add versioning for the Amazon S3 bucket.
We can compare the options and choose which to implement.
Let's resolve the storage components.
We'll access the Amazon S3 Management Console.
Let's select one of the buckets associated with our
application and edit its properties to enable Bucket Versioning.
We'll do the same for the second bucket.
Now let's return to Resilience Hub.
Another recommendation was to enable multiple Availability Zones for the database component.
Let's implement this recommendation.
We'll go to the RDS Management Console.
Let's find our database instance and modify it.
We'll create a standby instance.
Let's continue.
We'll apply this modification immediately and modify the DB instance.
Now the database has been modified for multiple Availability Zones.
Let's return to Resilience Hub and reassess our application.
Like before, we'll name and run the report.
Although we did not initiate all of the original recommendations, let's see whether our actions
helped improve the estimated times for RTO and RPO.
Our application still shows a "policy breached" status, as we expected.
In the Infrastructure category, the compute component, which we did not optimize, isn’t meeting its target.
However, the database and storage components for which we implemented recommendations
show that targets have been met.
The same is true for the Availability Zone targets.
Let's review the resiliency recommendations.
Only the compute component is still breached according to our resiliency policy.
We can further optimize the database component, but we are in compliance.
All other recommendations have been followed.
Once we add an Auto Scaling group in a different region, we’ll be fully compliant with our resiliency policy.
You've just seen Part 1 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.