4 ms·
So there are three choices, essentially to argue over: - run on demand instances (maybe mix in spot) - run fargate instances (maybe mix in spot) - reserve th
by abofh 4y ago
So there are three choices, essentially to argue over:
- run on demand instances (maybe mix in spot)
- run fargate instances (maybe mix in spot)
- reserve them.
Every company hates #3, but it's usually the best choice if you can't go spot - you can swap them within the family for size, use them for baseline, it's fine. You're incorporated right? So if you fold, it's just another debt on the pile, stop worrying. Go no upfront if you really want to avoid the cash outlay, or go spot if you can defend limited outages.
- noduerme 4y agoReally the issue is swapability. The way the system is constructed, there's basically one monolith for customer-facing services and another for internal ops, and some smaller shared databases, services and a bunch of backup. This hews to the company's security profile, and the lack of scattered microservices (which I now consider fortunate) is also a result of that years-ago migration from dedicated servers where these two interconnected systems evolved along separate trajectories [edit: to the point where the customer facing system still only writes to its own mark/sweep DB that's picked up by the internal system, or in rare cases accesses internal APIs by cUrl ... so either could still be anywhere]. Going up a tier on one or both of those monoliths would be more difficult and costly if they're reserved. So in a sense, a long reservation would just be good insurance against the business not growing. But no one wants to pull the trigger on that.
- eb0la 4y agoIMHO Reservations in AWS are good if you have a US Bank Account. Why? Because there is a secondary market (run by AWS) where you can buy and sell reservations. If you have a 1-year project that will have a 1-year extension, then get a 3-year reservation (with some amount upfront) that you can sell. Your second best option is a Savings Plan.