4. Question Category: CSAA – Design High-Performing Architectures

[Denzil77777]

As regards to; A
tech company has a CRM application hosted on an Auto Scaling group of
On-Demand EC2 instances with different instance types and sizes. The
application is extensively used during office hours from 9 in the
morning to 5 in the afternoon. Their users are complaining that the
performance of the application is slow during the start of the day but
then works normally after a couple of hours.

Will you please clarify the answer technically? If there is a slowness during, as per the question/scenery 09.00 hrs, then commence operating after say 1-2 hrs (10 am or 11 am ) , 1-3 hrs (10 am or 12.00 noon, lunchtime approaches.

According to the question, this is an everyday occurrence, and it would have triggered alarms via CloudWatch? Could a CloudWatch or a Cloud Trail kick into action, and bring up the necessary instances? Just wondering?

Would it be that loads and loads of customers are logging in as well as the office staff, resulting CPU and Memory?

AWS is all about elasticity and automation. Indeed, the answer address that claim. However, according to the answer, I assume, a new EC2 instance, for example is being started by 08.00 am? In a real time case, would this instance in question, be stopped, after (then works normally after a couple of hours), in a view to save cost?

Lastly, as per the answer, (I am driving a bit deep here, I suppose the type of storage is in place. Could be an EBS?) what happens when this instance is Stopped or Terminated, and only to kick back to life on the next day? Would AWS pick up the same instance, if it was stopped?

[Neil-TutorialsDojo]

Hi Denzil,

Thank you for posting here.

To clarify the answer technically, configuring a scheduled scaling policy for the Auto Scaling group means setting up a rule to automatically adjust the number of EC2 instances in the group based on a schedule. In this case, the schedule would be set to launch additional instances before the start of office hours, such as 8:00 AM, to ensure there are enough resources available when users begin accessing the CRM application at 9:00 AM. This helps alleviate the performance degradation experienced during peak usage times.

Regarding your question about CloudWatch and CloudTrail, these services can indeed monitor the application’s performance and trigger actions based on predefined alarms or events. If performance degradation, such as increased CPU or memory usage, triggers alarms in CloudWatch, it could trigger the scaling policy to add more instances to the Auto Scaling group.

Regarding the customers and office staff logging in, it is indeed a possible cause of the slowness, which is caused by the high CPU and memory usage.

For instance termination and cost optimization, in real-world scenarios, it’s common to employ cost optimization strategies. Instances launched for peak hours could be terminated or stopped during off-peak times to save costs. However, this depends on the specific needs and usage patterns of the application. If the performance issues persist beyond the initial hours and require continuous scaling, it might be more cost-effective to keep the instances running.

If an instance is stopped or terminated, AWS does not necessarily restart the same physical instance. The auto-scaling group maintains the desired capacity and launches new instances as needed, potentially from a different Availability Zone for high availability.

Lastly, for persistent application data, EBS volumes could be attached that remain even if instances are replaced. This ensures data availability when instances are stopped, terminated, or replaced by auto-scaling activities.

I hope this helps. If you have any more inquiries, do not hesitate to ask.

Regards,

Neil @ Tutorials Dojo

[Denzil77777]

Good day to you, Neil,

Why thank you so much for your technical clarification.

It was a great education for me.

Kind Regards,

Denzil