Recently I was required to reboot my EC2 instance due to an AWS maintenance alert. After reboot I noticed my CPU credit balance was consumed. Why is that? What's going on?
Stopping and Starting a t2-standard class instance moves your instance to a new host system, clears your credit balance and then ordinarily¹ gives you a baseline of 30 credits per vCPU to ensure a smooth start-up.
T2 Standard instances get 30 launch credits per vCPU at launch or start. For example, a t2.micro has one vCPU and gets 30 launch credits, while a t2.xlarge has four vCPUs and gets 120 launch credits.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-std.html
Rebooting doesn't do this, but restarting (that is, a stop followed by a start) does, and the stop/start required for most maintenance events is a restart, not a reboot.
Tip
To ensure that your workloads always get the performance they need, switch to T2 Unlimited or consider using a larger T2 instance size.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-std.html
T2 unlimited machines are allowed to borrow against future CPU credit earnings for the upcoming 24 hours, so they don't receive the initial credit balance. You aren't charged extra for these borrowed credits, unless your workload is so heavy that over the subsequent 24 hour period is you continue to use credits at a rate that causes you to spend more than you could have earned.
¹ordinarily unless you have performed more than 100 stop/starts or launches of more than 100 t2-standard machines in the past 24 hours or your account is new, to prevent gaming the system. New accounts gradually ramp up to the 100 threshold.
Related
At the end of last month, I started experimenting with Amazon EC2. I launched one or two t2 micro instances, to experiment for free under the free tier.
However, I have quickly noticed on my billing dashboard that my services usage was increasing fast, and after a few dayswas forecast to exceed the free tier limitations by the end of the month. Since I don't need to maintain an 24/7 online presence at the moment and mostly use my instances to experiment, I have terminated one and stopped another. I have even detached the volume of the stopped instance.
All I have left are:
One stopped micro instance
One detached volume
Two snapshots of that volume
One AMI that I had used to move my instance from one region to another in the beginning
As far as I understand it, those more or less "idle" resources, at least not highly active ones. And yet, in my billing dashboard, in the row EC2 - Linux, the month-to-date usage keeps increasing, at the rate of more than one hour of usage per real-time hour.
Before I detached the volume, the usage would increase by 14 hours in only 3 hours. Now that I have detached it, it slowed down a bit, but still increased by 16 hours in the last 13 hours. All that, again, without actively running anything!
I am aware that the tally of the usage isn't strictly limited to running instances, but to associated resources as well. But still, it seems very high to me. I don't even dare to test my app anymore.
I would like to know if such an increase is normal, or if there may be something wrong with my account and how I configured my instances. If it is normal, any indications as to what actions I could take to reduce this increase would be very welcome!
Note that I did contact the Amazon support several days ago and didn't get a single reply, this is why I'm turning to here.
Thanks in advance!
Edit: Solved. I did have an instance running in another region, probably by mistake because I had never interacted directly with that region. See comments for a script to systematically check all regions and avoid this kind of stupid mistake.
Simple question:
If I had six identical EC2 instances process data for exactly ten minutes and turn off would I be charged six hours or one hour?
Update: EC2 and EBS are now based on usage down to the second
Old answer
Granularity for changes are measure down to the hour.
From the AWS pricing site http://aws.amazon.com/ec2/pricing/:
Pricing is per instance-hour consumed for each instance, from the time
an instance is launched until it is terminated or stopped. Each
partial instance-hour consumed will be billed as a full hour.
Unless you are calculating time to be under a threshold for a free tier, the second you use an EC2 instance you're charged for the full hour. If you go one second over the first hour, your charged for a full second hour.
One caveat: Spot Instances.
If spot instances are interrupted by AWS (not you) before reaching a full hour use, you're not charged at all. If you interrupt the spot instance, you're charge for the partial hour usage (which is a full hour rounded up as per the on-demand instances).
AWS has introduced per second billing for EC2/EBS effective October 2, 2017.
New EC2 Billing
You always get 750 hours per month for all your ec2 instances.
Different cases:
Case 1: Your have created and running one instance for 10 minutes.And then stopped.
It will be counted as 1 hour.
Case 2: Your have two running instances for each for 5 or 10 minutes and then stopped. It will be counted as 2 hours.
Case 3: You have one instance running for 10 minutes, then stopped and then again started for 10 or 5 minutes. It will be counted as 2 hours.
You can only use t2.micro servers and some limited OS in free tier.
This way, you can prevent your unwanted billing.
I hope, this has cleared some doubts.
Note: This is just my understanding till today. Please check their(aws) pricing docs for updated information.
I launched a m3.medium reserved instance yesterday, but the usage is already 163hrs and charge me 5 dollars, what does it mean by the usage of that amount of hours?
ps: I launched one on-demand instance before, but I just ran it for 2 hours and stopped it. After purchasing the reserved instance, I restarted it.
You can see amazon's billing documentation for an explanation of this pricing.
http://aws.amazon.com/ec2/purchasing-options/reserved-instances/
Light and Medium Utilization Reserved Instances also are billed by the instance-hour for the time that instances are in a running state; if you do not run the instance in an hour, there is zero usage charge. Partial instance-hours consumed are billed as full hours. Heavy Utilization Reserved Instances are billed for every hour during the entire Reserved Instance term (which means you’re charged the hourly fee regardless of whether any usage has occurred during an hour).
Ec2 instance hour calculated by hour by hour. If you just start and close an instance, it still counted as one hour.
How Heroku handle this? By Minute or By Hour?
Lets assume my app usage exceeds 750 Free Dyno Hour Limit
Heroku prorata to the second. A dyno costs $0.05 per hour. So if you go over 750 hours you will be charged at $0.05 per hour or $0.000833333 per minute. In fact, pretty much all addons also follow the same billing model too.
You can read about billing and charges as https://devcenter.heroku.com/articles/usage-and-billing#cost
I will say, though, that the previous answer seems to be more accurate for the web dyno versus a worker dyno. Heroku's automated sleep cycle for your web dyno tries to prevent it from running too long when it's idle, say, for more than an hour. For the free web dyno it must sleep at least six hours per day for it not to incur charges. As long as you set the scaling to 1 for your web dyno and it sleeps then it should be free.
That said, when you add your first worker dyno those same automations aren't applied to this dyno. It presumably won't be triggered to sleep on idling for an hour. This means that unless you manage it you'll likely be charged $34.50 for each worker dyno per month. I wouldn't exactly call this lying to the customer but most people start off with that first free dyno, get comfortable with that and then innocently think that the next dyno will behave in a similar way--it won't and you'll likely get tagged paying more money than you'd bargained for. That's $414-per-year for a dyno. Compare this with Amazon's t2.micro cost of $150-per-year for one instance or $75-per-year for a 50% duty cycle of same.
As they say, "the devil is in the details". Heroku might be cheap for vanity websites but it's a bit costly if you have a database and worker thread (without any scaling otherwise whatsoever).
How do you configure AWS autoscaling to scale up quickly? I've setup an AWS autoscaling group with an ELB. All is working well, except it takes several minutes before the new instances are added and are online. I came across the following in a post about Puppet and autoscaling:
The time to scale can be lowered from several minutes to a few seconds if the AMI you use for a group of nodes is already up to date.
http://puppetlabs.com/blog/rapid-scaling-with-auto-generated-amis-using-puppet/
Is this true? Can time to scale be reduced to a few seconds? Would using puppet add any performance boosts?
I also read that smaller instances start quicker than larger ones:
Small Instance 1.7 GB of memory, 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit), 160 GB of instance storage, 32-bit platform with a base install of CentOS 5.3 AMI
Amount of time from launch of instance to availability:
Between 5 and 6 minutes us-east-1c
Large Instance 7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of instance storage, 64-bit platform with a base install of CentOS 5.3 AMI
Amount of time from launch of instance to availability:
Between 11 and 18 minutes us-east-1c
Both were started via command line using Amazons tools.
http://www.philchen.com/2009/04/21/how-long-does-it-take-to-launch-an-amazon-ec2-instance
I note that the article is old and my c1.xlarge instances are certainly not taking 18min to launch. Nonetheless, would configuring an autoscale group with 50 micro instances (with an up scale policy of 100% capacity increase) be more efficient than one with 20 large instances? Or potentially creating two autoscale groups, one of micros for quick launch time and one of large instances to add CPU grunt a few minutes later? All else being equal, how much quicker does a t1.micro come online than a c1.xlarge?
you can increase or decrease the time of reaction for an autoscaller by playing with
"--cooldown" value (in seconds).
regarding the types of instances to be used, this is mostly based on the application type and a decision on this topic should be taken after close performance monitor and production tuning.
The time to scale can be lowered from several minutes to a few seconds
if the AMI you use for a group of nodes is already up to date. This
way, when Puppet runs on boot, it has to do very little, if anything,
to configure the instance with the node’s assigned role.
The advice here is talking about having your AMI (The snapshot of your operating system) as up to date as possible. This way, when auto scale brings up a new machine, Puppet doesn't have to install lots of software like it normally would on a blank AMI, it may just need to pull some updated application files.
Depending on how much work your Puppet scripts do (apt-get install, compiling software, etc) this could save you 5-20 minutes.
The two other factors you have to worry about are:
How long it takes your load balancer to determine you need more resources (e.g a policy that dictates "new machines should be added when CPU is above 90% for more then 5 minutes" would be less responsive and more likely to lead to timeouts compared to "new machines should be added when CPU is above 60% for more then 1 minute")
How long it takes to provision a new EC2 instance (smaller Instance Types tend to take shorted times to provision)
How soon ASG responds would depend on 3 things:
1. Step - how much to increase by % or fixed number - a large step - you can rapidly increase. ASG will launch the entire Step in one go
2. Cooldown Period - This applies 'how soon' the next increase can happen. If the previous increase step is still within the defined cooldown period (seconds), ASG will wait and not take action for next increase yet. Having a small cooldown period will enable next Step quicker.
3 AMI type- how much time a AMI takes to launch, this depends on type of AMI - many factors come into play. All things equal Fully Baked AMIs launch much faster