I would recommend you to migrate first only the schema of your on-premises databases to Azure SQL Databases and then let Azure SQL Data Sync to migrate the data to Azure and keep it updated on Azure SQL Database.
My suggestion to start with an empty schema on the Azure SQL Database side is because when SQL data Sync finds data on-premises and on Azure it start comparing both databases and that consumes a lot of resources.
On the initial sync SQL Data Sync may consume a lot of resources on the on-premises database server even when having an empty schema on the Azure side, for that you can use SQL Server Resource Governor to cap the CPU used by the data sync sessions in your on premises SQL Server, and this way avoid big performance impact possibly affecting database users.
When you are ready, you can switch your users (gradually or not if SQL Data Sync is on bi-directional mode) to Azure. Once your users have been migrated, you can then remove the member database (the on-premises database) from the SQL Data Sync configuration and stop SQL Data Sync operation.
First of all, no need to worry as this is normal behaviour.
The link in your answer From msdocs on Data space allocated gives us the info needed:
The amount of space allocated grows automatically, but never decreases
after deletes. This behavior ensures that future inserts are faster
since space does not need to be reformatted.
This space allocated grows automatically and will stay the same way when it grows out.
If the database keeps on growing, eventually the allocated space will be the same size as the maximum storage size. This is comparable to the autogrowth behaviour of regular sql server databases.
A useful part of the azure portal is that there are these little (i) marks on many settings.
These should point you in the right direction, the learn more points us to above linked page.
In short
when used space is nearing the allocated space, some more space is
allocated
yes (as long as you are not at the database limit)
when used space is at max size we have no more space available thus we
run out of space
and yes
Another way to get the size is checking the space available in the properties of the azure sql db with ssms.
This could mean that even sql server itself does not know that a mechanism like allocated space is used.
Proof
growing out the previously mentioned database a bit:
increases the used space & allocated space:
Afterwards I deleted the data & shrinked the database (Which you shouldn't ;)), also not with dbcc shrinkdatabase, double foul there.
dbcc shrinkdatabase([databasename])
Results in the same allocated space, but less used space:
Best Answer
I received the same email. I have received similar emails in the past. The only thing I do is add the IPs of the new gateways on the firewall rules on the Azure SQL Database logical server as shown on the image below.
Add the IP addresses of the gateways that belong to the zones where you have created your Azure SQL Database logical servers.
You do not have to do anything else. Based on my experience everything keeps working as usual.