There are many reasons you may want to have a static IP address for outbound connections. For example, you may be accessing a system which requires you to whitelist IP address in a firewall, such as SQL Database or an external service.

Currently, the only way to get a static IP address for outbound connections is to use App Service Environment. App Service Environments are quite complex, and has a very high price tag. You need at least 4 instances, 2 of which must be P2, meaning you'll pay at least 1000 EUR/month. Paying 1000 EUR/month just because you want a static IP address is obviously ridiculous.

I'm looking forward to being able to use a static IP address without an App Service Environment.

We are seeing some delays in Time To First Byte because OCSP stapling is not active on Azure Web Apps SSL endpoints.
This causes our clients' browsers to call the issuing CA's endpoint before SSL negotiation can really begin.

Stapling would save the client browser from having to make an extra request to the CA checking if the certificate has been revoked.

There is also a potential privacy issue for our clients that the CA will be able to log these requests. If the web server takes care of OCSP on the other hand no requests will be sent from the client to the CA.

The wikipedia article on OCSP stapling explains things pretty well.
https://en.wikipedia.org/wiki/OCSP_stapling

Running webpagetest.org against your site with the browser set to firefox shows the OCSP calls to the CA.

We need a consolidated way to see near-realtime CPU and Memory consumption for each Web App per App Service Plan. This way we can quickly identify which apps are consuming the most resources (specifically CPU and Memory) in that App Service Plan.

These are the 2 scenarios we run into often:

1. We run many web apps in each App Service Plan. We don't want to pay for a new App Service Plan until all memory (or CPU) is consumed on what we currently have. I could rebalance the sites (move some to another plan) if I could easily see which sites were consuming the most resources.

2. Sometimes, a web app consumes a lot of CPU or memory. I get an alert that the App Service Plan is hitting a limit, but I need to quickly identify which Web app is consuming the resources so I can stop it or restart it.

The current way of doing this is very slow and cumbersome. If I want to see the sites using the most memory, in Metrics (App Service Plan), I have to add every site to the chart, uncheck CPU for each site, then hover over the chart. Then I visually sort them in my mind.

Ideally, I could instead click on App Service Plan, Consumption and see a list of all web apps with CPU and memory consumption and the ability to sort it by either.

For multi-tenant applications, we require the ability for Azure to support double wildcard custom domains.

Single wildcard custom domains are currently well supported, i.e.

*.mydomain.com

catches all unmapped, single subdomain urls e.g. level1ex.mydomain.com, level2ex.mydomain.com etc

The issue (which isn't documented: see forum post below) is that secondary level wildcards are not supported at all by Azure:

e.g. www.level2.mydomain.com will result in a 404 error.

Why is this important? in a multi tenant environment, with lots of customers on different subdomains, it is best from an end-user perspective to support a www. subdomain prefix, as that's what 99% of non-technerati do when navigating to a website!

i.e. typing in www.level2.mydomain.com should be resolvable by Azure, just as single-level domains are, and not result in a 404

https://social.msdn.microsoft.com/Forums/azure/en-US/4196087d-0ef9-44dc-9192-73e434bdb194/second-level-subdomains-wildcard-domains-on-azure-dont-work-as-expected?forum=windowsazurewebsitespreview

In the current model, FTP credentials are tied to a user's azure login. Thus, we have no visibility into credentials that are set, as we cannot see other people's FTP credentials they've set. Furthermore, when an FTP account is created or deleted, nothing is logged. This makes it difficult to audit who has access. With the logins being tied to the user, when the user leaves, there is no way for us to reclaim that username unless they delete their ftp credentials first. This doesn't always work, as a user may depart abruptly or not on good terms. Although the credential is disabled as soon as we remove access to the subscription, we still cannot claim it.