Amazon EC2 Beta (2006)
aws.amazon.com
aws.amazon.com
Here's a skeptical comment[1] from Slashdot that was scored by that community as "5:Insightful":
>"Sun's grid effort has pretty much laid an egg. Perhaps I have the economics wrong, but isn't it more cost effective to build your own cluster out of discarded PCs?"
As counterpoint, here's a positive comment[2] to that same announcement that was more enthusiastic about the possibilities:
>Jeremy Wright • 10 years ago: Holy @#$@... We were about to move to Rackspace mainly for uptime support.
If you take Jeremy Wright's research into the new economics of cloud computing and multiply it by a hundred thousand like-minded people, you can trace a direct line from that kind of post to the Rackspace sale to private equity that made the HN front page yesterday[3]. The seeds of Rackspace's sale 10 years later were sowed from the very moment of Amazon's EC2 beta announcement.
1. For a Linux user, you can already build such a system yourself quite trivially by getting a server setup, installing Xen, and then rolling out your own VMs that way. From Windows or Mac, these VMs could then be accessed over SSH.
2. It doesn't actually replace a dedicated server. This does not solve the connectivity issue.
3. It does not seem very "viral" or income-generating. I know this is premature at this point, but is it reasonable to expect to make money off of this?
(/s)
> We have an account at that is nearing its EC2 limit - we need to be able to create more than 20 instances, preferably as many as you can give us. Our application is exploding - we're doing well over 5M page views / day and it's doubling every 2 or 3 days, so the request is rather urgent. Can you have someone call or email us right away?
I remember at that time that it was just so much more expensive than physical servers at iWeb. Sure it was convenient, but the performance per dollar was something like 1/3 or 1/4. Crazy.
This is mostly still true.
Now, though, the benefit in AWS is all the add-ons that you can manage through the same system; DNS, messaging, databases, firewalls, load balancing, etc.
That said, we massively overprovision our servers at my company and it's still probably less than half of what we'd pay at Amazon. That pays for my time to take care of the servers, at least.
when you rent servers you either need a overlay network via a VPN or you end up renting a rack (1/3, half, full) and connect it yourself. but as you might guess you are now inside a single datacenter, if it burns or somehow looses it's connection you are offline. that's not a big deal for some sites, but some stuff will suffer from that.
AWS and Clouds are more about networks and traffic spikes than just a bunch of servers. It's also easier to just replace the system in a outage than on most other services where you mostly try to heal it up. On Clouds you just trash it. We have some small sites on 3 AWS Small instances and a AWS RDS Master-Slave. Whenever one instance breaks or AWS makes a notice that this instance will be recycled we just reprovision it. We are also on AWS Frankfurt which didn't have a real outage yet. Google pricing would be in favor but no RDS Postgres yet, same for Azure (even when we get 130 € per month on 7 accounts for free (startup program) for 3 years or so).
however our software is sold to customers as hardware and not designed to run on a cloud (yet), mostly because of sensitive data.
You're paying 30-40% more to provision in 6 seconds in AWS (and let's be real, it's low 5 minutes at least for most resources like instances), but if you've got the cash to waste, go for it.
As always, marketing is key.
If you've got a pre-baked application AMI, are using EBS-backed instances, and are starting them with auto-scaling or health-checks rather than manually using the console, then no, you really can have new instances up in a couple of seconds.
Mind you, the key (to getting a high ROI from AWS) isn't scaling up on a dime. It's scaling down on a dime, whenever your load decreases for even a minute or two, knowing you can just scale right back up. Being able to run with literally no paid compute-hours spent sitting around doing nothing waiting for a task can save you a rather large amount of money, usually quite easily compensating for that 30-40% AWS surcharge.
This is not restricted to a specific instance type, nor a specific region.
There is literally no way you are performing compute in seconds from when an EC2 instance is instaniated.
I've bookmarked this to come back to benchmark this.
Doesn't AWS still charge by the hour ... so if you were spinning instances up and down based on minute-to-minute load you would be overpaying for vs just maintaining a steady baseline.
If you turn an instance off you need to be pretty confident it will stay off for at least an hour.
If you start and stop one instance 60 time in an hour, you will be charged 60 hours.
So scaling down on a dime and scalling right back up is more expensive than doing nothing.
Instance hours are just rounded up.
Source: I auto scale my companies entire stack.
"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."
https://aws.amazon.com/ec2/pricing/
"You are billed for an EC2 instance-hour for each hour or partial hour (rounded up) that your instance is in the “running” state. Instances that are in any other state (“stopped”, “pending”, etc.) are not billed."
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-i...
Here's a company that got hit hard by that behavior :
"A little-discussed fact about AWS EC2 pricing is that users are billed for each server that runs for any partial hour it runs. That means if a user starts a server and then kills it within five minutes, he is still billed for the full hour. That seems acceptable, but if a user kills a server and replaces it with a new server of the exact same type and location, this move doubles the bill."
http://searchaws.techtarget.com/tip/Paying-the-price-when-an...
You should probably take a look at this, you are probably costing your company a lot of money.
Our largest problem has been the realization that "the cloud" is not in fact infinite despite what the the commercials will have you believe. We quite frequently are told to cool our jets.
I should add, bursty workloads like batch processing can be a cost play simply because a once-a-month even that is time sensitive can benefit greatly from instant* CPU that you don't have to pay for the rest of the month. Those workloads tend to be very niche and one-off for most businesses though.
Internal IT in enterprise is so unbelievably terrible in the Fortune 500 that even the worst mass shared hosting provider probably offers more compelling value. Amazon didn't have much of a bar to cross in technicals as much as in value proposition to encourage a transition worth future benefits.
That does vary by cloud vendor though.
And if you're using a lot of outgoing traffic, AWS gets even worse in comparison.
Absolutely all of that _could_ be done in a traditional IT environment but it's rare to see it done at the level of usability that AWS (or Azure, Google, etc.) offers and that leads to cost both in staff time, technical debt, and time-to-recover after failures. You definitely can beat AWS on pricing but it requires both sufficient scale and ongoing commitment to spend staff time developing and supporting infrastructure, which is usually an area where organizations choose to skimp.
As of this evening, in eu-west-1 it's about 70 seconds.
I know that both HIPAA and CLIA have issues with things like the spot market but you can still be approved via cloud.
Vendors will say all manner of things regarding how HIPAA compliance requires you to buy their most expensive services, but the HIPAA legislation and related rules are almost silent with regards to implementation requirements that map to actual technologies you could actually use. "Quote me the subsection of the Security Rule you are referring to; it will look like 164.308(a)(5)(ii)(D)." is dispositive of this sort of thing.
That's a real thing, by the way. The requirement, in its entirety: "Do you have procedures for creating, changing, and safeguarding passwords?" Did you see the point where it requires hashing the passwords? No, you didn't, because HIPAA doesn't require hashing passwords. It requires you to have some method of "safeguarding" passwords written down somewhere.
[Edit: Parent has clarified that they're dealing with standard paperwork at clients rather than the legislation itself, which makes sense (and, also, oww).]
If your computer is hacked, then attacker would be able to extract information from that Outlook database.
One company I worked for it would take literally 6 months for the internal IT organization to provision a VM and configure it to the state that it was actually usable, and they would chargeback hundreds of dollars a month for it. Physical/dedicated hardware you would need to set the wheels in motion 12-18 months in advance of when you needed it.
That IT department, I still know people there, is currently flailing desperately for a solution to the problem of the business having discovered how quick it is to provision on AWS and what it costs there, even tho' it "looks" expensive it is still a massive saving compared to the fully loaded cost of many large company's IT departments. And even if it takes an hour to spin up an instance, that is still an unbelievable miracle to people who were used to the old way. Questions are being asked for which there are no easy answers...
The guys in IT couldn't understand why the devs and the rest of the business were rapidly moving to Azure...
</timemachine>