Enterprise-Scale VS terraform-azurerm-caf-enterprise-scale

We are deploying all our App Gateways in the hub subscription (a hub and spoke architecture). Occasionally, App Gateways are created without the diagnostic settings enabled on them (I know, this can be automated with IaC, but there more to it on a org level, and not worth discussing here, but yes, this could be a solution). However, I’m planning to use the following policy definition provided by the Azure Enterprise Scale project https://github.com/Azure/Enterprise-Scale/blob/main/src/resources/Microsoft.Authorization/policyDefinitions/Deploy-Diagnostics-ApplicationGateway.json I’ve imported it, tested, works. BUT, as of today all App Gateways are sitting in one resource group, meaning that when app/dev teams want to access the logs, they get to potentially view logs for others as well (different teams, countries etc.). Not sure how this could be a problem from a regulatory, compliance standpoint, but the IT team was thinking about splitting the App Gateways per individual resource groups scope to the countries (one rsg for country x, another for country y …) where people from subscription x would be granted access to only rsg x within the transit subscription. Each would then have a dedicated Log analytics workspace in that resource group (the central IT team would still have access to all logs, countries only scope with RBAC to the respective resource groups). I could then of course assign per resource group the above policy n-time to make sure that the parameters reflected in each policy assignment point to the correct Log Analytics workspace.

Hey! You should check out all the policies that are included within the Azure landing zone, these are what’s recommended as part of a landing zone deployment: https://github.com/Azure/Enterprise-Scale/wiki/ALZ-Policies

And it is in separate MG in the reference Enterprise Scale but if you look at the policies assignments - https://github.com/Azure/Enterprise-Scale/wiki/ALZ-Policies - you will notice policies I mentioned are assigned at the intermediate root level, so sandbox MG inhertis them.

There is a Azure policy somewhere in https://github.com/Azure/Enterprise-Scale that can block creation of rules for specific ports, etc.

If you plan to scale out more (and for many other reasons), you should consider the reference architecture for Azure Landing Zones fka Enterprise Scale Landing Zones. https://github.com/Azure/Enterprise-Scale

There is also a terraform version if that is your preferred IaC - https://github.com/Azure/Enterprise-Scale

You can opt to deploy the ESLZ reference implementation for AdventureWorks and select the single option for platform. https://github.com/Azure/Enterprise-Scale/

{ policyType: "Custom", mode: "Indexed", displayName: "Application Gateway should be deployed with proper sslPolicy", description: "This policy enables you to restrict that Application Gateways is always deployed with the proper sslPolicy", metadata: { version: "1.0.0", category: "Network", source: "https://github.com/Azure/Enterprise-Scale/" }, parameters: { effect: { type: "String", allowedValues: [ "Audit", "Deny", "Disabled" ], defaultValue: "Audit", metadata: { displayName: "Effect", description: "Enable or disable the execution of the policy" } } }, policyRule: { if: { allOf: [ { field: "type", equals: "Microsoft.Network/applicationGateways" }, { field: "Microsoft.Network/applicationGateways/sslPolicy.policyName", notequals: "20170401S" } ] }, then: { effect: "[parameters('effect')]" } } }

I have a MSDN subscription but do not have Owner rights to it. Is there a work around so I deploy an ARM template from the /Azure/Enterprise-Scale github repo.? https://github.com/Azure/Enterprise-Scale

I'm planning to use the official landing zone module developped by MSFT, but it's a big bite. https://github.com/Azure/terraform-azurerm-caf-enterprise-scale/wiki

u/Ok-Inspection3886 Great question! Under the hood we use the Azure landing zones terraform module which is recommended by Azure when using Terraform if you're interested in "Platform Landing Zones". The module itself deploys custom policies and also allows users to add additional custom policies relatively easy.

Honestly, https://github.com/Azure/terraform-azurerm-caf-enterprise-scale does a pretty good job at deploying a landing zone-architecture, is active and maintained. I wouldnt try to re-invent the work Microsoft are doing themself but rather contribute to that project and build tools around the existing module. An issue I often hear from people is that they have a hard time visualizing which policies are added on parent management groups and how to exclude/adjust them.

To add to the links, azure released their own version of terraformer (I've never used it myself but if your deployments are on azure it may fill the gaps where terraformer fails) https://techcommunity.microsoft.com/t5/azure-tools-blog/announcing-azure-terrafy-and-azapi-terraform-provider-previews/ba-p/3270937 also https://github.com/Azure/terraform-azurerm-caf-enterprise-scale/tree/main covers creating terraform to create stuff like policies not managed by the standard azurerm terraform module. Best of luck!

The azure environment I'm working on has the Terraform Module for Cloud Adoption Framework Enterprise-scale implemented, so how is the right pattern to connect the cosmos DB with the Hub VNet and also be able to receive data from external sources?

Microsoft provides a an excellent enterprise scale terraform setup here: https://github.com/Azure/terraform-azurerm-caf-enterprise-scale