9 ms·
> I'm terrified of the literally infinite bill that might show up from a typo a month down the line Whilst this might sound funny, we were surprised to see it
by akh 5y ago
> I'm terrified of the literally infinite bill that might show up from a typo a month down the line
Whilst this might sound funny, we were surprised to see it as a common use-cases with users putting https://github.com/infracost/infracost https://github.com/infracost/infracost in their CI/CD pipelines to act as safety net. Currently it only works for Terraform users, but we plan to add other infra-as-code tools in the future. We're also discussing how we can do this for people who don't use infra-as-code in https://github.com/infracost/infracost/issues/840 https://github.com/infracost/infracost/issues/840 but it's not clear what the workflow could look like for them. Perhaps having separate AWS accounts with a budget alert that emails you to run https://github.com/rebuy-de/aws-nuke https://github.com/rebuy-de/aws-nuke is a work-around just now.
(I'm co-founder of Infracost)
- YetAnotherNick 5y agoI think most of the cost for medium-large sized business are elastic(number of pods, bandwidth cost depends on requests per second, storage cost for many things increases linearly with users etc).
- akh 5y agoYep - it seems to depend on the architecture too (e.g. companies that lift-and-shift to the cloud use VMs heavily). We're discussing ideas on https://github.com/infracost/infracost/issues/730 https://github.com/infracost/infracost/issues/730, e.g. could CloudWatch be used to fetch the usage so user has context of what those elastic services used last week/month.
- YetAnotherNick 5y agoDidn't imagined that this functionality would be present. Looks very useful and I would try it out for my terraform setup!
- koolba 5y ago> Perhaps having separate AWS accounts ... You absolutely must, MUST, MUST be using separate AWS accounts for separate purposes. You can have as many as you’d like and roll up the billing into one actual paying account. This is a win for accountability (roll up dev and easily see the split out for separate environments), but more importantly for security as it limits the blast radius for any one environment. Combined with per-account budget alerts it’s a win across the board.
- philwelch 5y agoThis is true. It does add additional complexity, especially if you have to do cross-account access, but the tooling for that is improving over time.
- Sevii 5y agoIt may be a 'must' for security but from a UX perspective it is a horrible experience. Does it make sense for one team to have 10+ AWS accounts per service because 'security'? How about if each team out of 1000s in your company has 10 AWS accounts per service? We run our service in 3 geographic regions and have a separate AWS account for each region and stage despite each account supporting resources in multiple regions. Considering that we have 4~ services that is roughly 40 AWS accounts for just one team with less than 10 people. What I'm describing above is the 'best practice' way to manage AWS accounts at scale. It is insane and saying 'security' does not magically make this reasonable.
- jsperx 5y agoI was so happy when I finally got cross-account roles working so I could use a nice drop down and seamlessly switch between my accounts. So cool! Then I learned because they’re saving it all browser-side I had to rebuild the whole menu whenever I first used a new browser or computer? Whaaaat? Of all people, AWS console users have to be highly likely to be using multiple devices/browsers. Having to recreate your own prefs at each new environment is nuts.
- thayne 5y ago