I'm trying to optimize cost for my project for some valid reasons we're running it on very expensive instances.
To the best of my knowledge Amazon charges by hours. For instance, if I'm running my EC2 instance for 1 hour and 4 minutes I'll be charged 2 hours.
What would be the best way to shut down instance closest to the next billing cycle, but not exceeding current one?
I was trying to do this based on uptime, but there is some difference between aws billing and uptime value.
I'm looking to use watchdog sitting on the instance itself. So I can pass parameters during provision and it will shut down itself say after 2 full billing cycles.
You can get the time that Amazon starts billing from the EC2 instance (assumes you have jq installed)
curl -s http://169.254.169.254/latest/dynamic/instance-identity/document/ | jq .pendingTime
and you could run a shell script once a minute to shut down after, say 58 minutes.
But this is a pain. If your processing is able to handle interruptions of an instance running then you should look at using spot instances perhaps with a fixed duration. This allows you to run at a reduced price for a known period of time without any additional costs because of running over.
If your workload is complete before the full hour, stop/terminate your instance right away when the work is complete. No need to keep the instance idle for the remainder of the hour.
The only time this may not be efficient is if you may have more work coming in before the full hour, and then you want to keep it running to process that new work. But that will only be the case if work is sporadic. And if it is sporadic, then it just may be better to keep it running.
Related
CPU metrics cannot be selected below 1 minute in Cloudwatch service. For example, how can I lower this period time to trigger the Autoscale scale faster? I just need to trigger the AutoScale instances in short time. (By the way, datapoints value 1 to 1)
the minimum granularity for the metrics that EC2 provides is 1 minute.
Source: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html
Would also say that if you need to scale that quickly, wouldn't the startup time be an issue anyway?
You are correct -- basic monitoring of an Amazon EC2 instance provides metrics over 5-minute periods. If you activate EC2 Detailed Monitoring, metrics are provided over 1-minute periods. Extra charges apply for Detailed Monitoring.
When launching a new instance via Amazon EC2 Auto-Scaling, it can take a few minutes for the new instance to launch and for the User Data script (if any) to run. Linux instances are quite fast, but Windows instances take a while on their first boot due to sysprep operations.
You mention that you want to react to a metric in less than one minute. I would suggest that this would not be an ideal way to trigger Auto-scaling. Sometimes a computer can be busy for a while, then can drop down again. Reacting too quickly to a high CPU load would cause the Auto-Scaling group to flap between adding instances and terminating instances. It is better to provision enough capacity for a reasonable amount of extra load and then gradually add more capacity as it is required over time.
If you have a need to react so quickly, then perhaps you should investigate using AWS Lambda to perform small amounts of work in a highly-parallel fashion rather than relying on Amazon EC2 instances.
I am trying to host an application on AWS. I am comparing hosting it on Lambda and on EC2, and was thinking about "sides costs".
Indeed with lambda I am charged for cold starts, and I was wondering if when starting/stopping an EC2 instance you're charged for this time, since my instance will take something between 1 or 2 minutes to start and stop.
Since I plan to start and shut down quite a lot of instances frequently it would represent a non negligible cost for me if I am charged for this period.
You pay when the instance is in RUNNING state. From docs:
If your instance is billed by the second, then you're billed for a minimum of 60 seconds each time a new instance is started—that is, when the instance enters the running state.
This is independent of your application on the instance.
Compute optimizer shows right sizing recommendations for ec2 instances that have been active for a large period of time over the last 2 weeks. Through this it produces graphs that show you your cpu, memory and network usage from 0 to 100% of the instance capacity.
How do i get access to this information without the use of compute optimizer. I want to know so i can right size instances after 3 days instead of waiting for 2 weeks for compute optimizer to get enough data to produce a recommendation. I have tried with cost explorer but can't see any way to filter ec2 instances by cpu or memory utilisation.
EC2 instances by default check a few baseline stats in 5-minute intervals which you could increase to "Enhanced Monitoring" that run checks every minute.
CPU is monitored by default and you can see it in the console if you go to EC2, your instance, and click the monitoring tab that shows up. To track memory you'll need to install the CloudWatch agent on the EC2 instance (second link).
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring_ec2.html
I'm relatively new to using AWS Batch, and have been noticing it takes a LONG time to spin up EC2 instances in a managed compute environment.
My jobs will go from Submitted > Pending > Runnable within 1 minute.
But sometimes they will sit in Runnable anywhere from 15 minutes to 1 hour before an EC2 instance finally gets around to spinning up.
Any tips and tricks on getting AWS Batch to spin up instances more quickly?
Ideally I'd like an instance the moment somethings in the Runnable state.
For some more context, I am using AWS Batch essentially like Lambda but choose your own instance and hard drive. I can't use lambda because the jobs need a lot more resources (GPUs) and time to process.
It would appear the scheduler takes its time based on non-transparent load at the data center.
Would love if creating a Batch Job returned estimated TTL.
But anyways, sometimes I get machines instantly, sometimes it takes up to 15 minutes, and sometimes it will take an hour or more for newer GPU instance types, because there are not any available.
There doesn't appear to be anyway to control the schedule. Oh well.
Note: Below setting might help reduce provision time, but will incur additional costs.
Compute environments -> Compute resources -> Minimum vCPUs
Making this = 1 (or more) will allow single instance to run all the time.
Compute environments -> Compute resources -> Allocation strategy
Changing this from "BEST_FIT" to "Best_Fit_Progressive" will also help.
I am using an Amazon EC2 instance with instance type m3.medium and an Amazon RDS database instance.
In my working hours the website goes down because CPU utilization reaches 100%, and at night (not working hours) the CPU utilization is 60%.
So please give me right solution for this site down issue. I am not sure why I am experiencing this problem.
Once I had set a cron job for every minutes, but I was removed it because of slow down issue, but still I have site down issue.
When i try to use "top" command, i had shows below images for cpu usage, in which httpd command consume more cpu usage, so any suggestion for settings to reduce cpu usage with httpd command
Without website use by any user below two images:
http://screencast.com/t/1jV98WqhCLvV
http://screencast.com/t/PbXF5EYI
After website access simultaneously 5 users
http://screencast.com/t/QZgZsiNgdCUl
If you are CPU Utilization is reaching 100% you have two options.
Increase your EC2 Instance Type to large.
Use AutoScaling to launch one more EC2 Instance of same Instance Type.
Looks like you need some scheduled actions as you donot need 100% CPU Utilization during non-working hours.
The best possible option is to use AWS AutoScaling with Scheduled actions.
http://docs.aws.amazon.com/autoscaling/latest/userguide/schedule_time.html
AWS AutoScaling can launch new EC2 instances based on your CPU Utilization (or other metrics like Network Load, Disk read/write etc). This way you can always keep your site alive.
Using the AutoScaling scheduled actions you can specify metrics such that you stop your autoscaled instances during non-working hours and autoscale instances during working hours according to CPU Utilization(or other metrics).
You can even stop your severs if you donot need them at some point of time.
If you are not familiar with AWS AutoScaling you can follow the Documentation which is very precise and easy.
http://docs.aws.amazon.com/autoscaling/latest/userguide/GettingStartedTutorial.html
If the cpu utilization reach 100% bacause of the number of visitors your site have, you must consider to change the instance type, Auto Scaling or AWS CloudFront in order to cache as many http requests as posible (static and dynamic content).
If visitors are not the problem and there are other scheduled tasks on the EC2 isntance, I strongly recomend to decouple these workload via AWS SQS & AWS Elasticbeanstalk - Worker type