- [Morgan] All right, time to jump into a sample question for the topic, identify elastic and scalable compute solutions for a workload. Let's take a look at the stem. A company has developed an application that processes photos and videos. When users upload photos and videos, a job processes the files. The job can take up to 1 hour to process long videos. The company is using Amazon EC2 On-Demand Instances to run web servers and processing jobs. The web layer and the processing layer have instances that run in an Auto Scaling group behind an Application Load Balancer. During peak hours, users report that the application is slow and that the application does not process some requests at all. During evening hours, the systems are idle. What should a solutions architect do so that the application will process all the jobs in the most cost-effective manner? When reading an exam question, you should first try to identify the key points in the stem. Then, take those key points and apply them to each response, and evaluate which one is the key. Make sure you take the time to read each answer in full. In this case, there is a job that can take up to 1 hour to process. So, the stem is providing a timeframe for the processing question, which could be important. Then, it gives details on the current architecture with the web servers using On-Demand EC2 Instances, and the processing layer run on EC2 Instances in an Auto Scaling group. This is contextual information. Then, the problem statement you are solving for is during peak hours, the users report that the application is slow, or, at times, does not process the job. Finally, when evaluating the answers, you want to see if the answer could solve the problem, but also keep in mind that the question is asking for the most cost-effective answer. Now, let's take a look at the responses. A, Use a larger instance size in the Auto Scaling groups of the web layer and the processing layer. B, Use Spot Instances for the Auto Scaling groups of the web layer and the processing layer. C, Use an Amazon Simple Queue Service standard queue between the web layer and the processing layer. Use a custom queue metric to scale the Auto Scaling group in the processing layer. D, Use AWS Lambda functions instead of EC2 instances and Auto Scaling groups. Increase the service quota so that the sufficient concurrent functions can run at the same time. Now, we'll take a pause for you to review the question. Revealing the key in 3 seconds, so pause now if you'd like more time. Three, two, one. All right. So, the key to this stem here is: C, Use an Amazon Simple Queue Service standard queue between the web layer and the processing layer. Then, use a custom queue metric to scale the Auto Scaling group and the processing layer. The question sets up a scenario where the processing layer with the Auto Scaling group is not scaling up fast enough to complete the jobs at peak times. This means the scaling requirements need to be tweaked so the instances can scale in sync with the volume of the requests coming in. An Auto Scaling group can scale in response to changes in system load in an SQS queue. So, if you introduce an SQS queue into the architecture, you can use a custom metric to scale the processing instances when the queue reaches a certain depth, which signals that the messages are beginning to back up in the queue. This solution also solves the issue where sometimes, at peak usage, the instances sometimes drop requests and never process the job at all. With the introduction of an SQS queue, even if the Auto Scaling group is at its maximum capacity, jobs will be saved in the queue and will be processed when the compute resources become available. In regards to cost effectiveness, you'll see once we cover the incorrect responses, how this is the most cost-effective solution. So, let's go ahead and take a look at the other responses. First is A, Use a larger instance size in the Auto Scaling groups of the web layer and the processing layer. A larger instance size would enhance the performance of the processing instances. However, it also increases the cost. This is mostly an issue because the larger instances would incur greater costs than smaller instances while idle. And we know with this application that at night, the resources are idling, which means that the additional cost incurred using this solution would disqualify it as the correct response. In addition, a change in the instance size cannot guarantee processing. That could depend on how the application is written and how effectively it uses resources. Next up is B, Use Spot Instances for the Auto Scaling groups of the web layer and the processing layer. For this response, it may, at a first glance, seem like a good answer. Spot Instances are more cost effective than On-Demand Instances. So, you may be tempted to choose this response based on that alone. But, taking a deeper look at this response, you will see it does not actually solve the problem set up for you in the question. The application runs slowly and can drop requests when it gets too overwhelmed. Using Spot Instances doesn't inherently make an architecture more scalable. And on top of that, Spot Instances and On-Demand Instances, take the same amount of time to boot up and scale out. So, swapping one out for another doesn't really change the problem we are having here. Additionally, there is no guarantee Spot Instances are available at all times. So, there is a chance that a Spot Instance isn't available, and the application would continue to drop requests. So, this is incorrect. Finally, there is D, Use AWS Lambda functions instead of EC2 Instances and Auto Scaling groups. Increase the service quota so that the sufficient concurrent functions can run at the same time. This is incorrect because you know the processing job can take up to 1 hour to run, but AWS Lambda functions have a runtime limit of 15 minutes in duration. This disqualifies this response as a key. So, it is incorrect. If you got this one wrong, I would recommend reading more on decoupling services, Amazon SQS, and Amazon EC2 scaling practices, as well as AWS Lambda functionality.
