Enterprise-Scale VS ALZ-Bicep

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

you can also use the default scripts from https://github.com/Azure/ALZ-Bicep

Not sure what your requirements are for IAC but we started our eslz with bicep and using this https://github.com/Azure/ALZ-Bicep repo. We had some consultants help build and then train us to do the deployments. I was able to pick up bicep quickly. By the end of the engagement I was modifying our IAC as the need arises. I did try terraform but found it a bit cumbersome. I prefer how bicep is incremental vs terraform having a state file to manage. They both have their place and probably both are just as excellent in the right hands. But I personally got a lot farther on day one playing with bicep then I didi with terraform.

Also, take a look at the Azure Landing Zones bicep implementation (and follow the links to generic landing zones documentation, if you haven't gone through that yet) - again, probably not something for here and now, but something you might want to read when thinking about if there are more applicatons coming in, or need to scale more.

1) Personally I would deploy the CAF blueprints (through the portal, or even better through CI/CD, I'm personally a fan of the Bicep templates. Then depending on what's already in the cloud (number wise, can you take a weekend of being offline while you fix it etc), you can opt to move the VMs out of the existing subscription/vnet, or recreate connectivity in a separate hub network. Ideally the AD VMs are moved to the identity subscription as well, so that's a 3rd sub.

The landing zone concept is a huge undertaking at Microsoft these days. There are many excellent resources to help get the core platform services and subscription stood up - https://github.com/Azure/ALZ-Bicep.

- Deploy hub with adaptation of https://github.com/Azure/ALZ-Bicep - Deploy landing zone (ie. subscriptions into management group structure) implementation with a service principal scoped on management group. This step has a generic implementation with subscription-specific parameters. - Deploy workloads to the landing zone with service principal created by the previous step.

https://github.com/Azure/ALZ-Bicep https://github.com/Azure/Enterprise-Scale/blob/main/docs/ESLZ-Policies.md#eslz-policy-assignments-for-built-in-policy-definitions-and-policy-set-definitions https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/