Is there any way to determine what should be your available bandwidth on EC2? Documentation seems to indicate that it should be based on your instance size, but I'm having a bit of trouble finding any specific numbers.
It is based on your instance size and the only #'s I could find were for XL instances. Supposedly, they should get 300-350 Mbps.
Related
I have a requirement that says if I have the CPU Utilization of 70% of one EC2 instance It should be scaled up and if I have the CPU Utilization of 30% and at least two EC2 instances it should be scaled down. This is working fine, I can scale up and scale down as it is supposed to be.
But for scenarios in which I have at least two EC2 instances, and one has CPU Utilization of 70% and another one has 30% I should migrate the CPU Workload from the instance with 70% to the one with 30%.
Does anyone know how can I do this using boto3? I've read the EC2 documentation but did not find anything related to this kind of workload migration.
Does anyone know how can I do this using boto3?
You can't do this in general and that's why you did not find anything about this. This is not how EC2 Autoscaling works, assuming that you are using the scaling as its not stated in your question.
You would have to develop your own, custom solution for such a requirement. And this depends on exactly what is your "workload". It is also not explained in your question so its difficult to even begin recommending something.
I already used Google Compute instance, and it's located us-central.
I'm living Taiwan, ping the instance than average time 180~210ms.
Amazon EC2 located Singapore, average time 70~80ms.
I think this difference latency result, depend your server located, right?
So I guessed Google Compute Engine doesn't support CDN, right?
even Amazon ec2 also the same.
Kind Regards,
PinLiang
Google Compute runs code while a CDN delivers content (**C**ontent **D**elivery **N**etwork) so they aren't the same thing. If you get better latency to Amazon EC2 then use that instead but be aware that Google Compute and EC2 work very differently and you wont be able to run the same code on both.
If you want low latency (to Taiwan) compute resources you might want to consider using a Compute Engine instances in the Asia zones, see: 4/14/2014 - Google Cloud Platform expands to Asia
Yes, location and network connectivity will determine your latency. This is not always obvious though. Submarine cables tend to take particular paths. In some cases a geographically closer location may have higher latency.
A CDN is generally used for distributing static files, at lower latency to more users. Cloudfront can use any site as a custom origin.
I'm considering purchasing an Amazon AWS EC2 reserved instance. Does any one know of any performance benefits for reserved vs. on-demand, spot instances? Or is this simply a pricing difference? Do reserved instances get spun up on VMs with less congestion and that sort of thing is what I'm thinking about.
Thanks,
Michael
Despite its name, "reserved instance" is a billing construct, not an instance type. When you purchase a reserved instance, no instance is started. It simply affects the price you pay for a standard on-demand instance that matches the availability zone, instance type, operating system of the reserved instance purchase.
Purchasing a reserved instance can reduce the hourly price you pay for an on-demand instance that has already been running for months. If you terminate that on-demand instance, the reserved instance pricing switches to any other on-demand instance that is running and matches the specs.
Spot instances are the same as on-demand instances except in when they are started/terminated and how much they cost.
Spot instances are basically when amazon has unused resources they can sell them at a slightly lower price to hopefully get those used up. The issue with spot instances is that they can be shut off at any time so you're taking a risk.
Reserved instances are computing power you can purchase upfront at a discounted rate. You're basically saying that you're going to use this type of system for 1 or 3 years or if you're not going to use it you want to ensure that you can use it at any time.
On-demand is the default for most people, I think. They're there. They're available when you need them and when you don't need them you stop paying for them.
If you purchase the same types of machine configs for each type of instance then there is no performance difference, only price.
The Amazon page on reserved instances doesn't mention any other benefits apart from the cost.
Adding to what #BuildStarted said, I have noticed longer start times with spot instances. I'm guessing that's because there is some additional time needed to compute the current spot price and find capacity.
Once an instance is up and running, though, you shouldn't see any difference between the 3 pricing methods for the same instance type.
I'm writing a ruby program that need raw cpu power (I know ruby is a very bad choice for this!).. but I don't have a powerful computer, so I wanted to rent something online that you pay per hour..
Any idea? Something simple to use yet very powerful, with multiple cores. I took a look at amazon ec2, that's a possibility. Anything else, more CPU oriented?
As far as on-demand compute power, Amazon's EC2 is a good choice. You can either pay market rates or you can go to their special discount spot market which is similar, but your instance can and will be terminated without warning when demand picks up again.
It's best to have a system that either uses a persistent EBS drive to save results, or saves them to something like S3 frequently.
If you can parallelize your processing, try and split it across the most cost-effective instance type instead of having to pay a premium for a single instance. For example, the XL Hi-CPU On-Demand Instance gives you 20 compute units for $0.68/hr. compared with the 4XL Cluster Compute Instance which is only 33.5 for $1.60/hr.
Remember that a single Ruby process can only use one CPU core unless you're using a combination of JRuby and threads. You will need to support multiple processes in order to make full use of the machine if this is not the case.
SimpleWorker - I think it's more simpler then EC2.
I am looking at the pricing of various cloud computing platforms, particularly Amazon's EC2, and a lot of the quotes are based on a unit called an Instance-Hour.
I am trying to get a handle on the exact definition of an instance-hour to better compare the costs of continuing to host a web-application versus putting it out on the cloud.
(1) Does it correspond to any of the Windows performance counters in such a way that I could benchmark our current implmentation and use it in their pricing calculators?
(2) How does a multi-processor instance figure into the instance-hour calculation?
An instance hour is simply a regular hour where the instance was available to you, wether you used it or not. Amazon has priced their different types of instances differently, so you pay for the type of resource you are getting, not how much you use it.
So... 1. No, it's just a regular hour. 2. It doesn't, it's already factored into the price you pay for the instance pr hour.
Note also that instance hours are billed rounded up (for Amazon EC2). So starting up an instance and immediately shutting it down again incurs the cost of 1 instance hour.
if you plan to start/stop the AWS EMR cluster rapidly within a single hour, and you want to avoid being billed for a full hour each time you do so, then
start the cluster with the --alive argument from cli, which means to leave it running.
then rapidly add steps to the same cluster, instead:
http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/AddingStepstoaJobFlow.html
Don't forget to stop the cluster when you're done! :)