8 ms·
This is not the intent at all, I work in the AWS Well-Architected team, and we are engineers trying to help other engineers. If you follow the best practices yo
by FigmentEngine 7y ago
This is not the intent at all, I work in the AWS Well-Architected team, and we are engineers trying to help other engineers. If you follow the best practices you will spend less (there are performance and cost optimization pillars).
- crankylinuxuser 7y ago(erased)
- privateSFacct 7y agoI think the way the forward looking CFO positions approach this (that keeps development velocity high without the 20 layers of paperwork to get CFO approval in old system) is as follows. New feature coming online, team sits with cost/acctg side and says, we expect our budget needs to go up by $X / month. Either third party or now AWS budgets for a given tag/project/account are prepared daily. If the daily / hourly rate > expected, inquiries as to why are made, discipline if needed (rare). Many CFO's are so happy to be out of the CapEX game, out of the Oracle audit game they will probably put up with a fair bit of a tradeoff there. Those same CFO's have had a lot of trouble when a project doesn't work out under old approach. Now they just spin down everything in AWS over a few hours. Govt side in particular, the datacenter buildout costs are CRAZY and the utilization often terrible.
- klodolph 7y agoI think this really hits it on the nose. CapEx is “cheap” long-run but often insanely difficult. It only makes sense if you have the scale (1) to control variance (2) to amortize planning costs (3) and it provides a competitive advantage. Meanwhile sysadmins with no knowledge of accounting will complain that on-prem is cheaper. This is why cloud wins.
- FigmentEngine 7y agoThanks for the clarification, I agree we can do more around cost, we do offer advice here that should help https://d1.awsstatic.com/whitepapers/architecture/AWS-Cost-Optimization-Pillar.pdf https://d1.awsstatic.com/whitepapers/architecture/AWS-Cost-O... As an engineer I would prefer to see a workload work well on a single vendor, before adding the complexity of running it across multiple vendors. Complexity is rarely your friend in Reliabilty or Security