Support DNS aliasing of an Azure SQL Managed Instance (at least for public endpoint)
As it is already supported for Azure single SQL Database, it would be nice to be able to create an alias for the Managed Instance, especially for the public endpoint address. All clients connecting directly to the public endpoint would be able to use an alias instead of the real name of the instance. Switching instances, disaster recovery, migration scenarios would be a lot easier to handle.
FYI, creating a public CNAME record redirecting to the public endpoint address of an MI (like instancename.public.***.database.windows.net) does NOT work : IP resolution is good, but no way to login to the instance or have AAD authentication working (even when specifying @servername in the login name).
Aidan Finn commented
This was a showstopper for SQL MI with us today. Back to VMs :(
Luiz Carvalho commented
Very useful property. Hope it can be developed soon!
there are a lot of legacy apps that do not support the length of the endpoint name. So having a way to alias it will be very useful.
Sydney Luu commented
We discovered today during our initial testing phase of our applications that
Azure SQL MI does not support SQL Server alias. We used (\windows\syswow64\cliconfg.exe)
to create these aliases (on-prem) and the app's config/ini points to these aliases.
Please enable this capability.
Bill Hodder commented
whilst not ideal, as it does increase the cost, use a fail over group... the caveat is that the FOG name must match your CNAME configured... for example
Then you can create yourcompanypreferredsqlname.whateverdomain.com CNAME yourcompanypreferredsqlname.microsftrandom.database.windows.net
Daniel Villamizar commented
It would be great to have an alias in azure managed databases, it would greatly facilitate connections and the ability to continue the operation in a disaster.
The lack of internal DNS aliasing support is blocking adoption for us as well - we've seen pretty much all the issues the original poster encountered.
Not having this feature makes lift and shift operations so much more difficult. We have hundreds if not thousands of Excel reports that all have to have their connection string updated. Azure server names are also cryptic and hard to pick out in server name list. With multiple environments and multiple servers all following a similar pattern and with mini guids in the name, I'm about to go cross eyed just finding the correct server to connect to.
Please make this a priority. Please publish a date that this "feature" will be supported. This should have been working on day one.
Kent Maxwell commented
This basic feature is also impacting our implementation of SQL MI. Please introduce this quickly. Thank you.
Ganesh Majeti commented
this basic feature is hindering our progress to productionalise the MI platform. when do you plan to release this? its been a while(3.5 months) this is taken into planned state
Ajay Sahu commented
It is critical to have this feature before we can adopt MI technology.
Nathan Shepherd commented
Ditto what Anthony Genovese said! We need MI because there are things we can't use PaaS for and we don't want to go IaaS if we can avoid it. But if we can't use aliases then we won't go forward with MI.
This feature would be very useful
René Frank Jensby Kristiansen commented
Same would be true for Private Endpoint, where CName would be preferred.. to use locally
Anthony Genovese commented
This right here. We really need this supported or there is no path for us to go to production here.
>>>>Switching instances, disaster recovery, migration scenarios would be a lot easier to handle.