Hilariously, Azure PaaS offerings of Microsoft products are notably worse than what is available in AWS.
Examples:
- SQL Server Analysis Services (SSAS) has no Azure PaaS, but there is an AWS PaaS for it.
- RDS for SQL in AWS allows setting a time zone, Azure SQL Database is UTC only, breaking the majority of existing databases when migrated. (They confuse what "developers should do" with what "developers actually do".)
- Azure's PaaS for Active Directory (Azure AD Domain Services) can only be linked to an Azure AD tenant, it can't be used as a standalone authoritative domain. AWS allows this scenario.
Essentially, every Microsoft product you can think of is easier/cheaper/better on AWS instead of Azure.
If Microsoft's CEO was still Bill Gates, heads would have rolled a long time ago.
RDS for SQL Server does have some features missing from Azure SQL Database (SSAS and time zones as you said, but also SSRS). As a PaaS service it's pretty rough around the edges, though: scaling requires a long outage, copying a database between servers requires doing a backup to S3 and restoring from that, and the AWS backup/restore operates on the server level rather than the database level.
Where AWS really showed its unsuitability to host applications on the Microsoft stack was that AWS doesn't have a PaaS way to host .NET Framework web applications; IaaS is the only option.
So both .NET Framework web application nor Microsoft SQL Server database were noticeably harder on AWS than Azure for us. Standing up one IaaS server to host SSRS in Azure was a lot less work than accounting for all the gaps on the AWS side would have been.
Azure SQL database doesn’t support .BAK files. It can only import or export in BACPAC format which is SQL statements in a zip file and is an order of magnitude slower to restore.
We’ve had issues where large databases would take forever to cut over to the PaaS database and cause long outages during migrations.
It’s these random feature gaps that make these platforms difficult to deal with.
BACPACs are the only option to get a database out of Azure SQL. And yes, they do suck, for the reasons you outlined.
For the initial migration to PaaS, whether Azure or AWS RDS, it’s faster and easier to use replication instead of BACPACs.
For moves within the Azure SQL environment, they have database copy functionality that can be utilized. (Which RDS doesn’t have, and I would have sorely missed if we hadn’t pulled the plug on AWA.)
There's a better way to get data out of Azure if you can handle a bit of manual scripting (way worth if for large tables).
Setup linked-servers from your local server (via Server Objects / Linked servers), once you've done that you can just do "INSERT INTO bigtable(..) SELECT .. FROM [remotename].dbo.bigtable;" , it'll tax the transaction log but it's a magnitude faster than bacpac's,etc. Sadly Azure SQL doesn't support linked servers so one of the servers has to be outside.
There's an annoying difference between 'Azure SQL Database' and 'Azure SQL Managed Instance'. I recall the Managed Instance does support timezones and SSAS, while the ordinary offering also misses other useful stuff like Resource Governors.
Managed instance has time zones, but not SSAS. It does have SSIS, but only via Azure Data Factory. This means you need additional VMs and the performance is much worse because there’s always an extra network hop.
Azure if you're a .NET shop and want good integration with Visual Studio
AWS for everyone else