Each and every built-in role has a specific definition at a specific time and it will gets changed as the new features are available. Does Microsoft logs these kind of activities under azure activity log if there is a change to the built in definition in the future? Or is there a place that we could subscribe it to get these changes?

For building Custom role, we general copy a specific role definition that closely matches to on what we want to accomplish, from time to time, this built-in role definition will gets changed and all the custom roles that were created from this will be obsolete. It would be nice, if MS provides some kind of tracking to the built in role definition changes!

We are using New-AzureRMSubscription to automatically create subscriptions. After creation we see that the Account Owner is made Service Administrator of each subscription that is created via this way.
There is a risk that, when the credentials of this account owner are confiscated, the attacker takes over control, as service administrator/ (service owner), of all the subscriptions.
This risk can be mitigated by having the possibility to assign a different identity as service administrator for each subscription created.
If we create such an subscription via the enterprise portal, we already have the possibility to assign a different identity as service administrator.
It wwould be of great importance to us when we also have the same possibility to specify a different identity as service administrator when using the API's.

The Discover service tags by using downloadable JSON files links go to Microsoft.com download pages. These pages initiate downloads of files with a different name for every update.

This is not useful for staying up-to-date with the service ranges. Either a human has to go click on the downloads, or some screen-scraping tactic needs to be used to get the actual file location.

Better would be to link to a URL that always has the latest JSON file.

The REST API is not a useful alternative, as "the Discovery API might return information that's less current than information returned by the JSON downloads."

https://github.com/MicrosoftDocs/azure-docs/issues/52181

Universal Packages are great for storing binaries and other files needed during deployments or other custom solutions.

What's not good is that we're limited to the Azure CLI for both publishing and downloading these files. There is no other option or integration present.

The only option for automatic downloads on a new environment is to
- Download and Install/Update the Azure CLI
- Install/Update the azure-devops Azure CLI plugin
- wrap the "az artifacts universal download" command in a Powershell Script

Not only does this take forever, but it spawn many processes, downloads dynamic "package downloader" tools, write to STDOUT with progress messages that can't be disabled, and sometimes fail/throw SSL warning errors.

Please make a "managed" Powershell/.NET library to do this or even make it possible via the REST API.

Otherwise it's hard to confirm that things have downloaded, monitor the process, or create a parallelized download process.

We are looking for a Global Router Solution for Billing-Sensitive API Use Cases and we worked with multiple parts of Azure support (namely Front Door, Azure API Management or APIM, as well as Networking) to check whether our use case is supported.

We found out, working with multiple support teams that such use case is not really supported right now and we were strongly encouraged to submit this idea as soon as possible on this feedback forum for potential review by the global community and the respective Microsoft teams. (Initially submitted on this forum, as of 7/21/2020)

In current model as of July 21, 2020. rules blocked by WAF in Azure Front Door charge the inbound rate even if the WAF rule blocked it. This is because the request is passing through Azure Front Door + WAF as one single unit for the purposes of billing. This is similar to how Azure CDN and all other global Layer 7 routing solutions Azure has currently works and bills when they are at the global level. This is confirmed by Azure Support as of 7/21/2020.

Either by changes or features in Azure Front Door, or via another way, this idea submission requests the implementation of a global router functionality that does not charge for inbound traffic that is blocked at the "edge" or perhaps a better term with be the "rules" level. In other words, functionality to support rules that if/when they define a block or deny state, that inbound ingress (especially) is not charged, and preferably not the egress either if possible for the blocked traffic triggered in this way (perhaps with option of a mode whether to respond to the connection, which would incur a small charge, or not respond at all, which would incur no charge. This idea submission is focused more on just the version that would not respond to the connection at all, as existing functionality in current products already processes and bills all requests and returns responses already all the time as-is – however, this nuance is mentioned in case it could still be relevant for this kind of functionality to offer the option of the two at that level of the rule ).
Also, we would prefer not charge by how many times the rule was triggered per period, instead we would rather prefer to pay for each definition of these kinds of rules themselves on a per rule per hour basis or something like that (however, hopefully a reasonable pricing either way).
The preferred way of blocking this kind of traffic would be to have the option to simply hang the connection and not return a response if possible (sort of like NSG's can do at the Virtual Network level, except to apply this at the top global level somehow), since existing functionality already can block and return a response e.g. APIM policy, even to some extent Front Door rules, etc. It is desired that this specific kind of "blocking" actually be somewhat similar to perhaps the way NSG's block traffic on Virtual Networks (for example) that don't match an NSG allow rule or that matched an NSG deny rule - the infrastructure just doesn't return any response at all and there is nothing that processes the request directly when the rule doesn't match. This is for purposes of only high level illustration and this specific example may or may not be based on exact specific working models of current Azure products, and we do not necessarily imply a specific implementation methodology in this idea submission, this specific paragraph would be intended more as a general conceptual reference and there could be likely more than one approach here.

There is more to this idea but it exceeds the description max length - the full idea is attached here as a text file.

Thanks for considering this idea.

Microsoft WAF badBot rule 100200 is not able to differentiate between real spoofed IP vs Microsoft system spoofed IPs. Since we are using CDN ahead of AFD(as it is not fully capable like Azure CDN now)There are genuine requests from Google Bot is getting blocked in Badbot rule as the requests are containing socket IP's as CDN PoP location lP's in the request along with client IP's. Hence Badbot rule detected it has spoofed requests. Since Azure CDN and AFD's are Microsoft supported products, either the rule should be able to differentiate the real spoofed IPs vs in their own products requests, else should have an option to not to forward the PoP IP's in the requests.

In AWS, when I want to create a VM that is encrypted, I create a key store and then when I create the AMI I can create a copy of it and tick the encrypted option. It is very easy indeed and I can go from nothing to an encrypted machine in about 20 minutes.

In Azure, I have to create a vault, create a key encryption key, create an application, allow the application access to the key vault, make a note in excel of about 28736 parameters, try to create the VM, work out why it failed, try to create the VM, work out why it failed,
try to create the VM, work out why it failed. Eventually, I might, after 6 hours of hair pulling, get an encrypted VM.

Perhaps you could get someone who is NOT on acid to devise a simpler encrypted VM deployment method? (And templates do not make it easier as they also require all the pre-reqs.)

20 minutes from scratch should be your target.