There was some confusion about this feature due to the documentation for it and UX originally released had a bug.
The IP Restrictions feature works as an ALLOW list, rather than a DENY list as originally stated.
The ask here is still valid, there are other services in azure (like SQL) that have UI to explicitly allow other azure services to reach the database. While this is convenient for development scenarios, it’s not a good idea for securing the resource.
We’ll keep an eye on this request and see if it gathers more up-votes.
This is currently causing an issue for us when importing Azure Function into Azure API Management. We have added the IP address of the APIM to the allow list, but the import functionality breaks unless we temporary disable the IP Restrictions on the App Service. It would be great to know what IPs we need to add to allow for this, or to have the Allow Azure Services (if the traffic is coming from the UI for APIM).
Offering IPv6 support across Networking is a high priority for us and we are actively working to deliver this.
Please support static IPv6 addresses! Since many devices do not have access to dns resolution, we need a stable ip.
We currently offer the option of reserving single IPv4 public addresses. Reservation of blocks of IPv4 and IPv6 public addresses is, unfortunately, still in work- we apologize for the delay.
On a related topic, Azure now offers load-balanced, dual-stack (IPv4+IPv6) Internet connectivity for Azure VMs. This native IPv6 connectivity (TCP, UDP, HTTP…inbound and outbound initiated) all the way to the VM enables a broad range of service architectures. IPv6 for Azure VMs is available now in most Azure regions. Data transfers over IPv6 are billed at the same rates as IPv4. For more information, please visit this Overview of IPv6 for Azure Load Balancer: https://azure.microsoft.com/en-us/documentation/articles/load-balancer-ipv6-overview/
This is closely related to the suggestion “Support IPv6 Throughout the Azure Platform” but we’re taking this suggestion as ensuring ALL the various Azure services (Storage, etc.) offer IPv6 connectivity.
A step towards this goal is the IPv6 connectivity now available for Azure VM’s. Azure now offers load-balanced, dual-stack (IPv4+IPv6) Internet connectivity for Azure VMs. This native IPv6 connectivity (TCP, UDP, HTTP…inbound and outbound initiated) all the way to the VM enables a broad range of service architectures. IPv6 for Azure VMs is available now in most Azure regions. Data transfers over IPv6 are billed at the same rates as IPv4. For more information, please visit this Overview of IPv6 for Azure Load Balancer: https://azure.microsoft.com/en-us/documentation/articles/load-balancer-ipv6-overview/
Please add suggestions for specific scenario/service you need IPv6 enabled to help guide our prioritization and work?
The Azure Networking IPv6 feature team
Please support Static IPv6 addresses. This is a must have for many scenarios where certain devices do not have dns resolution, and we need a static endpoint for sending data.
Work on this request has commenced. We will send an update once it is completed.
Our apologies for not updating this ask earlier. Renaming Blobs is on our backlog, but is unlikely to be released in the coming year. Today, you can use the “Copy Blob” API as a workaround.
Using the Azure Files service you can address Azure Storage like a network share using the SMB2.1 protocol. This enables usage of normal Windows API’s to rename files and directories. You can get started with the Files service by visiting https://docs.microsoft.com/en-us/azure/storage/storage-dotnet-how-to-use-files.
For any further questions, or to discuss your specific scenario, send us an email at email@example.com.
Thanks for your suggestion. We are looking into this scenario for a future release. 10697273
702 votesunplanned · AdminSQL Database feature voting forum admins (Product Owner, Microsoft Azure) responded
Not planned at this time. Will keep this item open for future review.
This work necessary to support this is in progress.
Thanks for your feedback here.
Thanks for the suggestion. We are considering at some time to provide an “exception” rowset that could capture such information. Right now we have no ETA and will keep collecting feedback.