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.
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.
Edit: what's with the down-votes?
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.
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).
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".
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.
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.
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 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.
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.
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)
(They also almost always help out or completely forgive someone that accidentally ran up a massive bill in a short period of time.)
But, and I don't say this lightly, your behavior in this thread makes me think you just want to complain.
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.
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.
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.
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.
1) You're just playing: You want a limit. 2) You're serious about it: You want a warning.
Easy enough to understand I hope.
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.
oafitupa is just whining for the sake of whining.
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?
If you understand AWS pricing, and don't publish your AWS keys, you should be good to go.
More about bots scanning github for api keys, that's pretty scary in itself because I know pushing keys by accident happens a lot.
* 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.