The scariest thing to me about AWS is that I might accidentally bankrupt myself while I learn to use it. I've seen horror stories on HN before. Articles titled "How I spent $32k with AWS, a for loop, and a simple typo" or something like that.
Normally when I learn something new, I learn by tinkering and breaking stuff. I don't feel comfortable doing that with AWS. I'm hoping people will tell me I'm way off base because this fear has stopped me from getting the ball rolling.
I run a million-dollar business on it for $4500/m, give or take. It's not Webfaction (who I love and highly recommend) or Linode. It's virtualized data-center territory that can support some massive stacks.
They give you enough rope to hang yourself. I'm ok with that, because it works brilliantly when you have the time to put in to it. (They also almost always help out or completely forgive someone that accidentally ran up a massive bill in a short period of time.)
Without AWS, my company wouldn't exist - I could never have initially afforded dedicated hosting or collocation. AWS changed the game. You can argue they're not the cheapest or even the best anymore, but it works this way because of Amazon.
You could have afforded VPS hosting in the beginning (starts from $20 per month for decent specs), and immediately switched to dedicated hosting once you outgrew the VPS (from $100 per month). AWS was never the cheapest for any given level of performance; you've always paid a huge premium for rarely needed flexibility.
I would argue the "rarely needed flexibility" - our traffic is very spiky, and we scale from 3 to 11 or even 13 front-end instances between our lowest and peak usage. If I had to maintain all that hardware capacity for 10% of the day, it would be more costly.
Then there are the ancillary benefits - I can lose a server and another is in its place, attached properly to the stack within 60 seconds. I can take advantage of compute power when I need. I don't have to run nginx or haproxy for load balancing (and I don't have to manage the load balancer servers) and spinning up an identical stack in Europe or Asia is a single command line statement away.
Also I'm not a server admin by trade.
So I realize there are scenarios where bare metal could be cheaper, but the opportunity and admin costs need to be factored as well.
Traffic that spiky is extremely unusual. But you don't need to maintain all that hardware capacity for 10% of the day.
There are a number of colo providers that also provide managed hosting and cloud services (even if you for some reason couldn't deal with the latency of simply tieing EC2 instances into a colocated or managed hosting stack via a tunnel).
In fact, combine, and you can cut the hosting costs even more than with colo services alone, since you don't need to plan for a low duty cycle for the hardware - you can run things on 90%+ load (or wherever your sweet spot turns out to be) under normal circumstances and fire up cloud instances for the spikes.
That method handles the loss of servers etc. as well just fine, again further cutting the cost of a colo/managed hosting setup because you can plan for less redundancy.
Personally I've yet to work on any setup where the admin costs of an AWS setup has been nearly enough lower than colo or managed hosting to eat much into the premium you're paying. You have 90% of the sys-admin hassles anyway, and you're left with far less possibility of tuning your setup to what works best with your setup.
Most of the setups I've worked on come out somewhere between 1/3 to 1/2 of the cost of running the same setup purely on AWS. Sometimes the gap is smaller if you have really spiky traffic or have lots of background processing or one off jobs where you can e.g. use spot instances extensively.
I do understand people wanting to pay to not have to think about these things, though. But you're almost certainly paying a steep premium for it, even with your traffic spikes.
The idea of straddling two separate data centers seems far more complex, cost-wise, and time-wise, than simply going with AWS and using their flavor of elasticity. Given that his hosting costs are half a percent of his yearly revenue, "premium" really seems like the wrong word here.
It may seem more complex, but it really isn't, and it typically ends up so much cheaper than EC2 it's not even funny.
And you don't need to straddle data centres as most data centre operators these days have their own cloud offerings - often cheaper than EC2.
I don't know his margins, so maybe it isn't worth it for him specifically, but I know plenty of businesses with small enough margins that the opportunity to halve a half-a-percent-of-revenue cost like that could easily add 10% to profits.
I wasn't referring specifically to the physical aspect with something like colocation, although that's another potential facet of complexity. The complexity I was referring to is literally having two distinct environments interoperate seamlessly.
You now have one environment trying to talk to a database in another location, for example. So, some requests are artificially slower than others. You could mitigate that with caching, and probably already do, but now your cache is fragmented across two, or more, environments. On and on and on and on.
Configuration, security, duplication of resources that can't be easily shared. These aren't unsolvable problems, but they're relatively more complex than sticking everything in a single environment.
And yeah, the money aspect could easily be worked in either of our favor. It really depends on the specific situation.
If you want to play with VPS servers, use DO. If you want to virtualize a data-center or series of globally-connected data centers with racks of servers, use AWS.
So maybe AWS isn't the right solution for you. You say in another comment that warnings about billing overages aren't enough. AWS can't hold your hand and provide Netflix-capable services at the same time.
Amazon chose the latter. I would recommend you not choose AWS until you have the time to dedicate to it.
How is being able to set up a $ limit "holding my hand"? You guys are defending something that is indefensible.
I don't want to "play" with VPS servers, I want to work knowing that I won't go bankrupt just because I'm using at the same time a service that won't let me set up a limit, and a pull payment system (ie. credit cards, as opposed to push systems like Bitcoin).
I imagine that they decided not to have $ limit as implementing that would be once you hit the $ limit, they will take your whole stack down completely. This includes anything you've had setup on AWS, which could be hundreds of instances of any of their services... which may or may not be feasible to do instantaneously or safely (without you losing data or breaking something.) Imagine pulling systems down in the wrong order or while writes or reads are being done... you now have no guarantee that your data will be in a good state.
It's always best to leave termination of your client's systems up to the client than to pull the plug out from under them... at least I'd like to think that's how they would have reasoned it internally.
You can have a $ limit. Use a CloudWatch alarm that shuts down your instances if the billing metric exceeds the growth rate you specify for the period you specify.
Like it or not this is a problem many of us have, and are avoiding AWS for that sole reason. You can keep blaming the victim, or you can accept not being able to set up a limit is a usability problem.
It's like saying "this website is stupid, it's storing passwords in plaintext", and you answering "hurr, it's the user's responsibility to create and manage cryptographically secure passwords".
You're not a victim! Youre inability to control your costs, given the tools, alarms and general common sense doesn't entitle you to some magic off button! Learn to use the tools appropriately and you won't incur unexpected costs.
And as an analogy, Aws is more like C; if you are willing to put the time in to learn, you can do some amazing things that are impossible with other providers. But you must take responsibility for them.
How is a simple configurable limite a "magic button"? What extreme technical difficulties do you see in implementing it, that warranted you calling it "magic"?
Because it would tear down the entire stack? If you're a real business, depending on servers to be up and data to stick around, then it makes absolutely no sense to have machines shut off and volumes deleted if you hit some arbitrary marker. There's nothing you get for free in AWS (besides the Free tier, and not many people are running their entire, highly profitable business on that) and the only solution to "not spend more than $X per month" is to literally shut down and delete things.
I'd love to hear use cases where legitimate businesses, who make money off of the products or services they offer, can literally afford to have their business just stop working. It sounds totally contrived.
A CloudWatch alarm on a billing metric could also be used to send you SMS, email, hell even call you if you want to wire a webhook up to a quick and dirty twilio app (via SNS)
In fact, we use an SNS->Slack gateway running on a free Heroku dyno to get out alerts in a Slack channel (which is pushed to phones/etc), along with other CloudWatch alarms related to performance.
Honestly, this issue of "I don't have any visibility into what I'm spending" is a waste of energy. You do, and you can have AWS bug you as intensely as you want with updates as frequent and as urgent as you need
It's not "playing": reading is fundamental. Their billing rules are clear. It could be argued that their vocabulary for describing the billing rules takes a bit of figuring out. I have a client that didn't understand either the rules or my instructions and did something silly and ran up a $5000 bill, when he was thinking it would be $100~$200. We called Amazon and they cancelled the bill.
Amazon is very easy to work with, if you simply tell them that you are an idiot and fucked up. You're not the only one.
Can you use a pre-paid credit card with Amazon? (Not that that would absolve you of owing the balance - but they might halt your account for lack of payment and prevent further charges from accruing).
AWS charges are monthly so it won't help much (also they don't immediately pull the plug, they send you the email warning first). One just needs to setup the alarms and pay attention when deploying a new code. It sounds far more scary than it really is.
you could protect yourself by setting up a limited liability company (cost in the uk is about £14), then your assets aren't at risk if something goes very very wrong...
Amazon probably should do a credit check before offering thousands of pounds in credit...
(I am not a lawyer and this should not be taken as legal advice)
I addressed that in other comment: I don't want to have to rely on that. For starters, there is no real data about that, just anecdotes. How do I know they will reimburse non-US customers too? Many companies have that policy: They protect US customers because they can sue them, but people from other countries can only complain on the internet.
You are creating one of those arguments that really add no value. Really, if your app is succeeding you might want it to shut it down? No you are just creating another strawman argument because you see a service not offering one feature you MIGHT want. Seriously, get over yourself.
And AWS is the only service that supports both, and any finegrained solution in between, by triggering programmatically actionable alarms.
You just have to set it up, and if you cannot be bothered, AWS isn't the service for you. If you don't want to do your own cooking, fine, but don't whine about the grocery store not providing you with your own personal chef.
All he asks for is a reasonable feature that can be enabled or disabled as the customer wants. You may not need the feature, he does.
This is hacker news, ie for people who like tech, like to ticker with it and play with it. What is so bloody wrong with wanting a safety button so that you don't ruin yourself that you have to throw out insults?
Yeah, Amazon's key model is a pretty big weak point, both Google Cloud and Azure handle it better. It would be safer to use different sets of keys, like one to create new machines, and app-specific keys that can update only, but that's more work and more headache to manage. Google Cloud just makes me SSH tunnel, which I like.
A friend amasses $200 bill overnight due to bad looping when experimenting with Lambda. This is all too common of a story now. Amazon should do something other than goodwill refund.
This isn't true at all - the main issue that most of those articles have faced is either:
* Committing root credentials to a public git account (equivalent to your root account on every machine + ability to purchase new servers…)
* Spinning up instances during free period, then forgetting and getting billed the $10/month on them a year later
* Not reading the costs, and trying to replicate what you might normally purchase in AWS and being surprised at the cost, rather than buying 101% of capacity required.
I'm using it to host a mid sized website with an intranet type app with servers spanned across multiple data centres, built in redundancy etc for around $100/month after reserved instance one off payments. It's crazy cheap and in my view, incredibly powerful even for smaller businesses.
Given the size of reserved instance pre-payments it seems a bit disingenuous to claim you're paying around $100/month. Reserved instances are definitely the way to go if you have a steady state load that warrants them, but you do have to look at that pre-payment as part of your monthly costs to get a proper view of what's being paid.
Normally when I learn something new, I learn by tinkering and breaking stuff. I don't feel comfortable doing that with AWS. I'm hoping people will tell me I'm way off base because this fear has stopped me from getting the ball rolling.