[philliphaydon]

I used to think the problem with AWS was pricing and hidden costs etc. But in reality it’s because companies just let developers run wild without restriction on AWS and end up over provisioning or pulling in expensive services to solve dead simple problems.

The issue is definitely not AWS. It’s always the developers. You really need a gate keeper to AWS to question why you need a service and ask for a price estimate on cost and usage.

[zimbatm]

It's not that one-sided. On AWS, you have to go hunt to find the pricing for everything. On GCP, it's right next to the instance that you're starting. The GCP dashboard also provides recommendations to down-size VMs if they are too large. On AWS it's also super easy to spin up a VM and never see it because it's in a different region. These little things add up.

[Xunjin]

I do really hate this pattern done by AWS, and their docs seems more made to hide information than actually make easier.

I've learned much more with 5 minutes posts (which I truly dislike) in other sites than going to AWS docs.

Comparing to Digital Ocean docs and Q&A which is so much easier

Edit reason: Added DO as example of simplicity and really helpful price model.

[kevan]

I'd implement a good cost attribution strategy before trying a gatekeeping approach. Companies generally have at least semi-functional mechanisms for managing department budgets. Once there's a clear picture how much each service/webapp/product costs to run then they can feed that into the existing budget infra and let things shake out.

Until you know both halves of the ROI calculation it's difficult to focus effort on trimming the right things. e.g. It seems silly for a team to spend $2k/mo on naive/managed solutions for simple things but maybe it's worth it if it helps them avoid hiring another $10k+/mo engineer.

[unethical_ban]

Funny, since AWS has much more granular control over IAM roles and users than GCP does, so that the infrastructure/security group should be able to provision devs with the ability to roll their own IAM in a scoped way to prevent issues.

[bassdropvroom]

> so that the infrastructure/security group should be able to provision devs with the ability to roll their own IAM in a scoped way to prevent issues.

This requires money and time that often only large corporations have the luxury of.

[hckr1292]

In my experience trying to configure AAD policies, AWS IAM and (to a very limited extent GCP IAM), it does not generally require a large investment in time. It does require a development account in which the developer has full access to IAM/AAD.

At my employer, we have a gatekeeper team who is terribly overworked and hardpressed to push back too much when business outcomes are at stake. One of the more successful things theyve done is create a terraform repo anyone can contribute to. They will review PRs and manually apply changes for production accounts. Whats great is that these folks can take my PRs that are 80% right and they are able to help me achieve least privilege better than I could on my own. However, other devs really dont care about least privilege and they tend to go for large open policies.

AWS's IAM policy is far and away the most sophiscated and granular, and even has a nice UI now. Trying to achieve this in Azure is next to impossible because you must have extremely high permissions to even be able to make new roles/policies that are super granular.

[unethical_ban]

Also, permissions boundaries are specifically made for the use case of "IAM teams delegating some control to devs".

IAM team creates a "developer admin" role/user that can only create users/roles that have a permissions boundary on it. That way, no matter what policy the dev admin grants, the dev user can only do what the permission boundary allows.

[unethical_ban]

(A) Not necessarily, and (B) if so, okay so what? The whole point of the parent comment was about keeping devs in check, and I submitted an anecdote that AWS in fact has better tooling to keep people from doing things they aren't supposed to. Not related to billing oversight, but permissions.