Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The vast majority of business do not need to scale on a dime.

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.



It's not just scaling - a lot of the value comes from how you can change your practices to be more reliable: e.g. instead of having the classic model where you get servers setup and run them for years, now every application no matter the scale or how mature uses APIs to interact with your infrastructure, has automated blue-green deployments, every developer (or your CI process) can spin up instances to test in a production-like environment, you have things like RDS/ELB/S3/etc. as turn-key services which anyone can take for granted when designing their application, everything can be secured with limited scope API keys / policies, etc. When you suddenly get a spike in demand (annual reporting, unanticipated new work, one-time migration / reprocessing, etc.) you can have everything you need instantly without a large procurement lead-time or having to either repurpose existing infrastructure or find a use for new hardware for the rest of its service lifetime.

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.


When I looked last AWS EC2 isn't just 30-40% more expensive than renting a dedicated server, but up to 5-10x as expensive.

And if you're using a lot of outgoing traffic, AWS gets even worse in comparison.


There comes a time where it is way cheaper to not deal with your own IT. My company has a many thousand core cluster with ~30PB of storage on prem. We finally decided that maintaining that ourselves was nuts, and while it's expensive as hell to pay our cloud provider it ends up being cheaper in the long run for multiple reasons


That's completely nuts - for 30PB you'll be paying like $1.5M per month for storage and compute, you could buy all the hardware for maybe $3-5M and rent space for it for like $50k per month.. over 3 years the same cluster would cost you over $50M on AWS versus $10M to do it yourself (let's be generous and say plus 10 engineers at $2.5m/year to run it) so $17.5M to DIY.. there are some situations where it makes sense, like if your baseline is low and your fluctuation is high, but IMO if you have a baseline of 30PB, you'd be able to pay for a lot more engineers if it was in house.


We haven't fully transferred yet, but yes our monthly bills are quite large. From everything i've heard it's been a net savings. There are other advantages such as the cheaper 'deep storage' tiers, spinning up just the compute we need it on demand instead of having to worry about keeping it all packed, etc. It's going to be expensive and a pain in the ass either way.

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.


You can get those same "deep storage" tiers on prem for a fraction of the cost of AWS. There's no scenario, short you of you running the systems at less than 40% capacity, that AWS is cheaper. You have to be criminally inefficient or very very very small (like less than one server small) for AWS to EVER be a cost play.

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.


I don't know a lot about the huge scale side, but I tried running a teeny little server of my own on AWS, and it's way overpriced and over-complicated. You can get a single server for like 20% of the price on any number of hosting services. Digital Ocean works pretty well for me right now.


AWS is somewhat lucky in that its best market was primarily organizations where an offering like it was actually very simple and transparent is what is desired and that price / performance is not what it competes well upon. This is rather different from their main business that's very focused upon lowering costs and merely by being online is in its own way performance.

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.


At that scale you can negotiate significant discounts though.


When buying IT equipment worth millions you will get very significant discounts,too.


And if in the US, write $500k a year off as an immediate expense (when purchasing your gear) versus depreciation. AWS spend is ongoing opex that's gone forever.


Also a very good point. The difference in price between what i'd pay for my personal work and my professional work isn't nearly as large as one would assume based on the listed prices.

That does vary by cloud vendor though.


Do you know this to be true, or are you assuming?


AWS has offered fairly significant discounts to organizations I'm familiar with that are well over $1M+ / month in usage, but this discount pales in comparison to how much they have saved in labor and availability compared to internal managed IT even completely ignoring the business agility kinds of arguments.


> and let's be real, it's low 5 minutes at least for most resources like instances

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.


AWS charge by the hour, as soon as you power up an instance you are charged a full 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.


Bingo. If you've scaled up, you stay scaled up for the instance hour. Otherwise, you just threw money away.


GCE only need 10 minutes and then you can spin down.


That's not at all true. You would be charged for exactly one hour.

Instance hours are just rounded up.

Source: I auto scale my companies entire stack.


Amazon and people who have been hit by this seem to disagree with you:

"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.


I'd love if you could point the way then, because my pre baked AMIs that are EBS backed are always taking at least 3-5 minutes to be healthy and processing traffic or requests from the moment they're spun up.

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.


> whenever your load decreases for even a minute or two, knowing you can just scale right back up.

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.


Would it make sense to spin up a bunch of instances and then stop them, then manage your own autoscaling by just starting/stopping rather than launching/terminating? What's the downside there? You only pay for EBS storage, which is a tiny fraction of compute costs.


It's not even just scaling. Even just getting our dev, as and CI servers started on day 1 is a huge plus.


5 minutes at least for most resources like instances

As of this evening, in eu-west-1 it's about 70 seconds.


...


This is rapidly changing. When I took over technical ops at my employer, we were 100% public cloud. I quickly moved us to private managed cloud and quadruped our capacity for 20% less spend. Now I'm in the process of preparing us to move to colocation, where I'm certain that I can save another 40-50% over three years. What's made this possible is technologies like CoreOS, Kubernetes, and Ceph. We are working on automating the bare metal network management pieces but I am confident that we will soon have an environment that can function in colo without onsite staff. If we automate throughly and pre-cable racks, adding capacity is as simple as using a colo provider's remote hands service to rack and stack new hardware every quarter or so.


Serious question, what are you doing better compared to AWS? Efficiency wise, what can't you offer your own cloud services and cash in on 40-50% markup?


Running a single tenant cloud system is not the same as a multi tenant cloud system.


What happens if that Colo goes down?


This problem is no different in colo as it is in public cloud. If your business requires site redundancy, you build this capability into your app and stack and run a second warm footprint somewhere else.


You wait for it to come back, just like when us-east-1 is having problems every few weeks.


What kind of discount are you talking? I have heard about the negotiation of a quite large deal in the high single to low double digit millions committed annually - and the discounts were basically like a sales tax holiday. Maybe the negotiator just wasn't doing a very good job, but it wasn't the kind of discount I would have expected to see for such a large commitment either.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: