Ask HN: What is the good time to move out of AWS?

You can chop that 10k into 2k a month for 2 large boxes on Internap (10gig uplink, 128gigs of ram, 16tb sata with 480gb ssd and this isn't the actual price it's actually about 250 less than 1k, no guarantee you can get the same price)

There is a setup cost both from the managed hosting provider and from whatever you provide to install the datastore and configure replication and backups.

Its easily worth it but there's work involved if you up to it it's not going to break you. It will make you stronger.

If you have to hire somebody at 100k p.a. to manage your bare-metal based infrastructure, then, again, it doesn't make good business sense. And there always are costs and lots of debugging in switching as well.

Although there are technical considerations in switching, I would be inclined to understand such decisions from a business point of view. Of course, I'm assuming that you are not flush with cash, otherwise you wouldn't be concerned with your burn rate.

For RDS specifically it might be worth reaching out to Percona to get advice/consultation about what a replacement solution might look like (not affiliated in any way)

1. Can I afford to run my own DB and Object storage with acceptable service levels? Do I have the necessary skills in house? 2. Is this cost relatively long-term or very short time? If long, renting space for your own servers at co lo datacenter might be well worth it. If you're not sure about your business, it might be wise to stay put with AWS.

I think it is a conscious decision based on your future plans and business goals. There is no direct answer to such infrastructure planning.

There’s some simple things you can do, like reservations, that can cut 30-40% off your bill.

In most places I’ve worked, even if we dropped our aws costs down to zero, it wouldn’t materially affect the business. Developers were generally the bigger expense, so having one take say a month to research and migrate instead of building a feature.. usually building features won because there’s no cap on the upside. Cost savings were generally only done if they were quick wins.

Questions you should ask:

- How does the monthly rate change as we grow? (i.e. Do you have an architecture that doesn't scale well?) Maybe what you have is fine as you will grow into it. Maybe your cost growth will out-pace your revenue/user growth. This one is really important to understand.

- How optimal is my current RDS/S3 setup? Are you using instance types above your needs? Are you retaining more data than you need? (i.e. Are you simply over paying?)

- How optimal is my application's usage of AWS? (i.e. Are you using indiscriminately?)

- How severely is the growth of my business impeded by the loss of $2k-$10k/month? Where else could it be applied to grow the business? (i.e. Is thinking about this the best use of your time, or is it just the most glaring, easy thing? Remember that saving on monthly expenses doesn't get you customers or grow your revenue.)

- What hidden costs might there be from switching away from the status quo? In addition to the monthly costs, what will the development/operational costs be? Are you making trade offs in your availability or your ability to quickly recover from technical issues by switching?

If you have someone on hand that has the time and is willing to be on call for managing the DB that's great and it's probably worth it. But if you have to hire someone or have to move someone of of other work to take care of the DB it may not be worth it. And if you can't hire someone and don't have someone with experience in managing a prod DB it could be a risky move.

Speaking of moving, the move itself can be risky. It can be tricky to move data like this depending on whether or not you can take some downtime, how much downtime, what your data access patterns are, if you can easily dual write and how long it will take to transfer the data are some things to think about. The cost of the move itself in dev time and testing costs (you will probably want to make sure this works before doing it for real, which means starting up copies of your DB in both AWS and your new provider) might blow away any savings you might make for some time.

It also depends on the DB tech you are using. Some are more reliable than others and require very little attention.

I don't know enough about your situation to give you definite advice but those are the things I would consider before moving. There are a lot of non-direct costs associated with something like this so it's best to think through everything. Some other things to consider are dev familiarity (they used one tool now they need to learn another), monitoring and observalbility (you didn't mention using cloudwatch but it's there), security and upgrades/updates.

Good luck with whatever you decide on.

(1) What is the range of variable cost per user? Can you pass variable costs onto users? For example, if one of your power users is consuming 500gb of space in your DB, are they paying for the 500gb of space, or are they paying the same as your customers using 0gb of space?

(2) How do storage/cloud requirements change with an additional 1 user, 100 users, 1000 users?

(3) Is your monthly revenue per user greater than your monthly cloud cost per user?

(4) If you gained 100k users tomorrow, would you go out of business this month?

(5) Do your costs scale linearly with number of users?

(6) Are your capacity requirements generally static and predictable on an immediate (daily, weekly) basis? Or do you have large spikes in traffic?

Generally speaking, the advantage of the cloud is elasticity; you provision capacity on demand only as you need it. If you are running instances 24/7, you are almost definitely losing money. The first cost saving measure I would look into is moving core, basic infrastructure onto dedicated or colocated servers.

By "core infrastructure," I mean the predictable capacity that you always need. Keep that in one place with a low fixed cost. Any extra capacity you need, use the cloud.