- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
I thought it was too late to start EC2 after a request occurred.
This means that if there are zero EC2s, the very first request will fail.
So I thought it would be a good idea to activate at least one of them.
From the following documentation, I found it difficult to scale when there are no values in the metrics.
https://repost.aws/knowledge-center/elastic-beanstalk-scaling-triggers
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-cfg-autoscaling-triggers.html
I'm not sure if this is possible, but I was wondering if there is a way to create a mechanism to output ALB access logs to CloudWatch Logs, and then create a script to create a metrics filter to determine the number of accesses from that and scale it if it is more than 0.
Contenuto pertinente
AWS UFFICIALEAggiornata un anno fa- AWS UFFICIALEAggiornata 8 mesi fa
- AWS UFFICIALEAggiornata 2 anni fa
Thanks a lot for your early reply!
I checked documents that including the document you recommended, and found it's difficult to scale if the metrics has no data.
I think your proposal: using a custom metrics filter is a solution that seems to work.
In addition: I was inspired from this following guide: It is possible to create a message queue and autoscale at CloudWatch based on the available message depth of the queue. Use a Lambda function at API Gateway authentication or a Lambda@Edge function at CloudFront to add a message to the queue to trigger a CloudWatch alarm.This will trigger autoscaling. But I haven't figured out how to delete messages to reduce the message depth in the queue. https://catalog.us-east-1.prod.workshops.aws/workshops/b317e4f5-cb38-4587-afb1-2f75be25b2c0/en-US/06-custommetric
Looking forward to an in-depth discussion with you on this topic.
For example, but consider the use case of implementing scaling with AutoScaling and SQS. The advantage of using SQS is that asynchronous processing is possible, in which messages are stored for later processing. So, if you do not need to process synchronously when someone using your service accesses it, I think this solution can be used.
After the messages in the queue are deleted by AutoScaling, it is recommended to delete the processed messages in the SQS queue by using "delete_message" after the necessary processing is done. For more information on "delete_message", please refer to the following document. https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/sqs/client/delete_message.html