Closed rhyspaterson closed 1 year ago
Thank you for logging this @rhyspaterson... this was something which was discussed at length within the team and had a mixed opinion on what we should do.
Within the Terraform module we opted to set the defaults to minimise the risk of "bill shock" by disabling high-cost resource types. But ultimately, we want to ensure that customers are led by the recommended practices rather than costs alone and we would always recommend using the Azure pricing calculator to understand costs before deploying resources to Azure.
You can also monitor costs using Cost Management + Billing, and implement budgets to help reduce your risk.
I will raise this question again with the team to see whether this is something we can incorporate into our documentation.
Also, does the following provide sufficient information if we cross link to this from our Wiki?
https://github.com/Azure/Enterprise-Scale/wiki/What-is-Enterprise-Scale#pricing
Thanks for the reply!
Appreciate the cost management and pricing calculator approach, in fact I cross-referenced each policy being deployed with the calculator and that was what surfaced some of the significant costings associated with them. That the customer/end-user is ultimately responsible for costing is true, but I think being clear that deploying the CAF best practice architecture in its default state will absolutely incur non-insignificant additional cost would be beneficial - particularly if concepts such as DDoS plans are new to them.
Also, does the following provide sufficient information if we cross link to this from our Wiki?
https://github.com/Azure/Enterprise-Scale/wiki/What-is-Enterprise-Scale#pricing
I think that would be great! I definitely missed it and read the wiki quite a few times unpicking the what and the how, policies and configuration options. Sorry I missed it though, it does seem fairly clear, and thanks for pointing it out.
I guess for me a good example of a concerning one is the DDoS plan, just because I believe all you need is a vnet which itself is a 'free' resource and usually considered fairly benign. This approach could also help partners or professional services - who are helping customers adopt best practice, such as CAF - be aware they likely need to forecast CAF induced costings.
I think that would be great! I definitely missed it and read the wiki quite a few times unpicking the what and the how, policies and configuration options. Sorry I missed it though, it does seem fairly clear, and thanks for pointing it out.
No worries... it's a challenge with documentation spread over multiple repositories. We need to get better at having a single source of truth, and cross-referencing things like this were relevant.
@matt-FFFFFF has already labelled this for addition to our documentation so we'll update this in our next set of updates.
Regarding DDoS, I completely agree with the concern around cost which is why all of our examples include this in a disabled state. To enable, there's a dedicated section in the configuration, in addition to linking to specific hubs. We'll consider making this clearer too though.
Note that you cannot currently link a Virtual Hub network to a DDoS protection plan.
Thank you
Trigger ADO Sync
Trigger ADO Sync
Community Note
Description
Is your feature request related to a problem?
It's unclear what the potential cost implications are when deploying the CAF, either directly or indirectly.
Describe the solution you'd like
It would be beneficial to call out the potential cost implications when deploying services into this architecture as configured in its default state. For example, the management subscription punches out a LAW, which I'll admit is a mostly trivial cost. But taking something like the Enable-DDos-VNET assignment, my reading is if a virtual network is deployed then the recommendation is Azure DDoS Standard (I think it is audit only, but I am not game to test it out), which is currently sitting at over $4,000 AUD per month flat fee. Looking closer, this is called out to an extent in the wiki, but cost is not mentioned and rather implied.
Perhaps it might be prudent to be a bit more upfront about cost implications associated with this best practice, even as a warning? If it is indeed mostly policy related, it could be an idea to have somewhere in the repo or wiki a dump of all the policy assignments, even a table to reference, and what is enforced and what is not. Maybe they could even be tagged as ones expected to incur costs, so people can cater for that. I'm sure there is some fun once could have with CI/CD to sort that! That all said, even something in the front page that called out an indicative cost impact would be really beneficial.
Thank you.
Additional context