Lately, I’ve been working with some customers to automate the migration of their services from another cloud provider to Azure. Quite often the services that need to be migrated include SQL Databases, for example MS SQL, MySQL, or PostgreSQL. In most cases, when there are databases to be migrated we make use of the Azure Database Migration Service. You can find out more about it here. This link is a great jumping off point for information, guides, and tutorials about Azure Database Migration Service. At the time of writing DMS supports migration of Microsoft SQL, MySQL, PostgreSQL, MongoDB, and Oracle.

The Problem

Quite often, when migrating services from another cloud provider or on-premises environment, you have to contend with firewalls and allow lists. This is to be expected of any well-managed environment whether that be in the cloud or in your on-premises locations. This presents us with a problem when it comes to using DMS. DMS doesn’t have a static public IP address for outbound communication. With the default setup, we can’t guarantee what IP address the service will use when it tries to make contact with a database that doesn’t reside within the Azure environment or at the other end of a VPN or ExpressRoute connection.

When you spin up Azure DMS for the first time, you will be asked to pick an existing virtual network and subnet or to create a new one. The Database Migration Service will use this virtual network and subnet to communicate with source and target databases. It achieves this by placing a NIC (Network Interface Card) resource on the chosen subnet.

As you can see in the image below, the service has been assigned the next available private IP address on the network in the same way as would happen if you created a virtual machine.

Not the solution

As mentioned above, the DMS resource uses a NIC to attach itself to the virtual network. During my initial investigations, I attempted to update the NIC configuration to include a public IP address but, unfortunately, you get a not found error similar to the below if you try to access the IP configuration for this NIC.

You can try this yourself by locating the NIC that is tagged with the DMS resource ID.

The Solution

The above failure got me thinking about what other Azure resources might be able to help me take control of the public IP address that DMS uses. That’s when it occurred to me that, if the traffic destined for the public internet traverses the virtual network first, we might be able to use NAT Gateway to control that outbound traffic as it leaves the virtual network. So I decided to do an experiment!! You can find out more about NAT Gateway here.

I already had my DMS instance set up from the above attempt, so all I needed to add was a SQL Database instance (in this case, I opted for Azure Database for MySQL) and a NAT Gateway with Public IP address. Under normal circumstances, I would configure some private connectivity to the database for resources that already exist in Azure but, for the purposes of this experiment, we are pretending that the database resides in another public cloud provider.

First off, I attempted to connect to my new MySQL instance with DMS. As you can see from the image below, the connection was rejected as the dynamic public IP address isn’t in the allow list.

To prove my point, I rebooted the DMS resource so that it picked up a new dynamic public IP address. As you can see below, we are still failing but with a different IP in the error.

Next, I updated the virtual network/subnet configuration to incorporate the NAT Gateway I had created previously. You can see the public IP address that I had assigned it in the image below.

All internet bound traffic is now routing through the NAT Gateway and NAT’ing behind the public IP address you can see above. The only thing left to do is to run a final test connection to our pretend source database server. I have deliberately kept the new IP off the ‘Allow List’ so that we can see the IP reported in the error. As you can see in the connection error below, we are now connecting via the new NAT Gatewat public IP.

In Summary

We’ve been able to control the outbound public IP address that Azure Database Migration Service uses to connect to Databases external to Azure for migration purposes. All we needed to do was add a NAT Gateway in to control outbound traffic. If you follow the path I did, you might end up with a solution that looks similar to the image below.

PSA: Remember, it’s NOT a good idea to experiment on a production environment. Please make sure you test any recommendations you read online in a Dev or Test environment before going to production.

Thank you for taking the time to read this article. I hope you found it useful. If you did, please feel free to share on your social media and tag me. You can find my social media handles above or to the left, depending on what device you are reading this on.