Explore the Web Application
Go to the AWS CloudFormation console at https://console.aws.amazon.com/cloudformation.
- Wait until CloudFormationLab stack status is CREATE_COMPLETE before proceeding. This should take about four minutes
- Click on the CloudFormationLab stack
- Click on the Outputs tab
- For the Key WebsiteURL copy the value. This is the URL of your test web service
- Hint: it will start with
http://healt-alb and end in
Click the URL and it will bring up the website:
- Troubleshooting: if you see an error such as 502 Bad Gateway, then wait 60 seconds and try again. It takes some time for the servers to initialize.
The website simulates a recommendation engine making personalized suggestions for classic television shows. You should note the following features:
- Area A shows the personalized recommendation
- It shows first name of the user and the show that was recommended
- The workshop simulation is simple. On every request it chooses a user at random, and shows a recommendation statically mapped to that user. The user names, television show names, and this mapping are in a DynamoDB table, which is simulating the RecommendationService
- Area B shows metadata which is useful to you during the lab
- The instance_id and availability_zone enable you to see which EC2 server and Availability Zone were used for each request
Use the following architectural diagram as you explore the site
- A - There is one EC2 instance deployed per Availability Zone
- B - Refresh the website several times, note that the EC2 instance and Availability Zone change from among the three available
- C - Elastic Load Balancing (ELB) is used here. An Application Load Balancer receives each request and distributes it among the available EC2 server instances across Availability Zones.
- The requests are stateless, and therefore can be routed to any of the available EC2 instances
- D - The EC2 instances are in an Amazon EC2 Auto Scaling Group
. This Auto Scaling Group was configured to maintain three instances, therefore if one instance is detected as unhealthy it will be replaced to maintain three healthy instances.
- AWS Auto Scaling can also be configured to scale up/down dynamically in response to workload consitions such as CPU utilization or request count.
|Well-Architected for Reliability: Best practices|
|Use highly available network connectivity for your workload public endpoints: These endpoints and the routing to them must be highly available. You used Elastic Load Balancing which provides load balancing across Availability Zones, performs Layer 4 (TCP) or Layer 7 (http/https) routing, integrates with AWS WAF, and integrates with AWS Auto Scaling to help create a self-healing infrastructure and absorb increases in traffic while releasing resources when traffic decreases.|
|Implement loosely coupled dependencies: Dependencies such as… load balancers are loosely coupled. Loose coupling helps isolate behavior of a component from other components that depend on it, increasing resiliency and agility.|
|Deploy the workload to multiple locations: Distribute workload data and resources across multiple Availability Zones or, where necessary, across AWS Regions. These locations can be as diverse as required.|
|Automate healing on all layers: Upon detection of a failure, use automated capabilities to perform actions to remediate it|
You have deployed the cloud infrastructure architecture that can support a high reliability workload
- This an example architecture of the cloud infrastructure necessary for reliable workloads
- Addition of dynamic auto scaling would further improve reliability
- Reliability also depends on software architecture, network configuration, operational excellence, and testing (especially Chaos Engineering
which tests resilience), which are outside the scope of this lab.
- Without best practices for all of these, which can be found in the Reliability pillar of the AWS Well-Architected Framework
, the workload will not achieve high reliability goals.