In certain cases I want to manage the availability of data replicas across a cluster of machines, and can endure more downtime for greater predictability of the nature of downtime.
An example is Kafka, where I can handle a large portion of machines going down so long as I can make predictions of how they'll be correlated so I can plan how I lay out topic partitions to keep a majority of partitions up.

With the way availability sets are currently set up, I can limit my downtime in case of a fault, or in case of an upgrade, but I can't align my planning on fault and upgrade domains to provide higher level guarantees.

As an example: if I have a cluster of 9 machines, and 3 fault domains, and 3 upgrade domains. If I only cared about faults, I could have a replication factor of 3 and distribute them across fault domains and be fairly confident that a fault would only take out 1 replica and I would still have majority and the cluster stays healthy. If an upgrade comes along though, I no longer have those guarantees and may lose 2 or 3 replicas and my cluster will be down, even though I've only lost 1/3rd of machines.
The same holds true if you swap upgrade and fault domains and plan the other way.
If I do 7 replicas in the cluster, and distribute across fault and upgrade domain combinations, I can guarantee that if any 3 machines go down (across either FD or UD), I'll still have majority, but this brings more than double cost and complexity.
If I could have my availability set configured such that all my machines had their Fault and Upgrade domains aligned (such that being in FD 1 guarantees being in UD 1, etc), then I can guarantee availability with only 3 replicas (in the above example) in the Upgrade or Fault case.

You should make this process easier or you will likely lose a lot of would be customers. You should offer the ability to renew an expired subscription to a pay as you go plan once the free trial period expires (or really I think for any expired subscription). I was shocked to find that because I got busy the day my plan expired I had to contact support to get it renewed the next day (which they responded in 12 hours and had it renewed for me, which is great but shouldn't have had to log a support ticket for this). For getting initial customers in the door you should allow for renewal view the subscriptions screen (or someway to transfer all existing Azure services to another subscription). This wastes time for the customer and support staff.

In summary, offer a renew subscription button to expired / canceled subscriptions.

Currently, I don't see any way to filter resources (either in the UI or via the CLI) in such a way that I can see what any given Service Principal has on the subscription. This is important for me, as I've got multiple Principals which are each tied to a different user, and I'd like to be able to have insight into what sort of resources & usage each user on my Subscriptions are consuming.

It would be very useful to have this in both the UI for quick checks, as well as in the CLI so reports can be generated via automated scripts.

Azure is prohibitively expensive for small businesses and new/poor developers.

£150 for 30 days is not long enough to get up and running and to make a viable website/app to cover the costs.

Suggestions:
-Allow users to use the free credits over 12 or 6 or even 3 months.
-Or return to your previous offer with free monthly credits for a year.
-Or offer SSL on the shared plan. (sites without SSL are not an option)

£50-£60/pm for a basic website with custom domain and SSL is ridiculous.

I feel my only option is to abandon Azure and look at something like Google's GCP (who are offering $300 for a year), which means I have wasted many years learning the Microsoft and Azure stack.

I really hope you can review your current offers and make Azure a better choice.

Thanks

Currently, Azure status history ( https://azure.microsoft.com/status/history/ )doesn't have permalink. I want to have permalink per status/failuer.

Current issues:
* Status history feed hide status older than 90 days. I can't know older history.
* I can't specify a specific status in history.

Why permalink?
* I should announse failuer or issue of Azure for customers when status updated (occurred and solved). In this case, I added evidence by quoting status report from Azure status history. However Azure status history doesn't have permalink and I should use quote always. That is weak as evidence. (They confuse and dificult look up issues in history.)

Can I use Azure Service Helth?
* Yes. But that is require login to Azure portal. If AzureAD occurred problem such as 6th April 2018, I can't show Azure Service Helth.

related feedbacks:
https://feedback.azure.com/forums/34192--general-feedback/suggestions/15228267-improved-azure-status-page-past-incidents