Thank you for your suggestion. We are working to improve this experience.
The new V2 (Autoscaling) SKU reduces the update times to under a min in most cases. https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-autoscaling-zone-redundant
We have raised the limit to 100 recently. We are regularly reviewing the limits and will continue to look for opportunities to raise the limits even further. If you have scenarios requiring limits higher than what is supported, please add your scenario details here (if you are comfortable with that) or raise an issue with Azure support and we will get back to you.
We are working on supporting wildcard listeners in the near term. As mentioned before, if you need more than 100 listeners you can open a support ticket with your specific scenario details. The current limit of 100 is set based on performance tests and we are unable to set it to a much higher value for all customers at this time as it may degrade performance depending on individual scenarios. That being said, we continue to review periodically and optimize our data plane so that higher limits may be possible.
Thank you for all the votes/feedback. We are unable to give an ETA in this public forum but please be assured this is one of our top priorities at the moment.
Please be assured we are working on this feature as one of our top priorities and will announce it as soon as it's ready.
38 votesstarted · 7 comments · Networking » Azure Front Door Service · Flag idea as inappropriate… · Admin →
Something similar is underway, and so wanted to hear your scenarios/use cases to ensure that the same would covered with the other feature. Can you share examples of what the incoming request would be and what should the forwarding URL?
43 votesstarted · 4 comments · Networking » Azure Front Door Service · Flag idea as inappropriate… · Admin →
We would like to hear more feedback on this. Can you explain your scenarios a bit more? Azure Front Door is different than Azure Load Balancer particularly for the fact that it is Layer 7 i.e. HTTP/HTTPS. So, waiting and not getting a feedback from the backend/origin/app server for 30 seconds for a web request is unusual.
valid suggestion subject to upvote
SNAT on incoming connections is done do ensure symmetric routing across the underlying firewall nodes for returning packets. This is needed as the Standard Load Balancer has TCP state checking rules today that will drop the session if the returning packet comes from a different firewall physical node. This will be fixed in the future, but no ETA yet.
9 votes2 comments · Networking » Security (ACLs, Firewalls, Intrusion Detection) · Flag idea as inappropriate… · Admin →
Thanks. We will add this feature to our backlog to consider for a future release.
Thanks for the feedback. This feature is high on our list - tentatively for H1 2019.
We are working on adding Service Tags to Azure Firewall network rules and hope to have it released in Q1 2019.
2 votes1 comment · Networking » Domain Name Service (DNS, Traffic Manager) · Flag idea as inappropriate… · Admin →
Please elaborate on the scenario. You can already provide permissions on a zone to a specific user such that user is able to manage records within that zone but not other zones. Please see https://docs.microsoft.com/en-us/azure/dns/dns-protect-zones-recordsets#zone-level-rbac
HTTP and HTTPS probes use an HTTP GET. Can you please expand on the scenario where something other than 200 is a valid response for this operation? 201 for example is typically used for a POST.
Thanks for the feedback. Agree with the feedback on destination address. We will explore having it as a drop down list that provides the firewall public IPs. This should eliminate also the confusion with the translated address.
Thank you for the feedback. Can you clarify please if you are asking for the health probe to close the connection
a) WITH a 4 way close or
b) WITHOUT a 4 way close and send RST instead?
@hisashima load balancer uses (a) today. why do you need the behavior described in (b). can you elaborate on the scenario and impact please?
526 votes9 comments · Networking » Domain Name Service (DNS, Traffic Manager) · Flag idea as inappropriate… · Admin →
We’re tracking this on our long-term backlog. However, it’s unlikely that we’ll support this in the near future.
Thank you for the suggestion and please keep the votes and ideas coming.
While we don't offer a 301 redirect service, we just announced support for Alias records which will let you point to any Public IP-backed resource (such as Application Gateway) or a Traffic Manager profile, from your zone apex. This may be an alternative if the need is to make sure both the zone apex and say the www subdomain point to the same load balanced application. For more details see https://azure.microsoft.com/en-us/blog/announcing-alias-records-for-azure-dns/
Thanks for the feedback, we are working on enabling ASG references across subscriptions/VNets, it’s currently on our plansAdminAzure Networking Team (Product Manager, Microsoft Azure) supported this idea ·
1 vote1 comment · Networking » VPN Connectivity (Point-to-Site, Site-to-Site) · Flag idea as inappropriate… · Admin →
Hi, can you please indicate to which article/documentation you're referring?
9 votes3 comments · Networking » VPN Connectivity (Point-to-Site, Site-to-Site) · Flag idea as inappropriate… · Admin →
Currently, the gateway private IP addresses are not required for configurations or operations, other than the GatewaySubnet range. They should have been hidden from users. The gateway resource model does not have a field for those either.
There may be use cases for new features down the road. We will update the gateway resource model accordingly and expose those properly.
Taking offline with Farouk to further clarify.
55 votes6 comments · Networking » Domain Name Service (DNS, Traffic Manager) · Flag idea as inappropriate… · Admin →
Azure DNS Private Zones is in Public Preview, which supports split-horizon scenarios.
We will support non-empty Vnets very soon. Stay tuned !
Hello, we are working on supporting existing (non-empty) VNETs. This is coming very soon ! Stay tuned.
Thank you for the feedback. We now have a report that is generated weekly on Mondays: Azure Service Tags JSON (https://www.microsoft.com/en-us/download/details.aspx?id=56519). This file includes all of the Service Tags and data by regions. This is an improvement over previous files as it includes tagging by Service Tag. We recommend you move to using this file and check weekly for updates. The file is broken out by Cloud (I.e. Public) and region (i.e., West US 2). We will take the RSS Feed request under advisement.
Thanks for your suggestion, it is an identified requirement and we are evaluating it to reduce frequency from one hour to near real-time.