Azure automatic fail-over vs always on availability groups clarification I am trying to understand automatic failover vs always on availability groups in Azure hybrid and geo-region situations:


Is it possible to have on-premises SQL databases, VM SQL databases and Azure databases in the same availability group? Or does one need to separate on-premises databases from cloud databases in separate always-on availability groups?
Automatic failover is not possible in hybrid situations, it has to be forced manually. But, can automatic failover be implemented across regions in the cloud or does it have to happen in the same region?
On-Premise SQL Server and SQL Server on a VM hosted in Azure are roughly equivalent and can be configured to be part of the same availability group, although as you mentioned the failover is manual rather than automatic.  

This link https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sqlclassic/virtual-machines-windows-classic-sql-onprem-availability provides more details.  

Azure Database (As A Service) is a different thing.  It is definitely based on SQL Server and it's High Availability is provided by something that is very similar to Always On Availability Groups.  But it's completely managed by Microsoft so you won't be able to add it as a member to your own Availability Group.  

This link https://docs.microsoft.com/en-us/azure/sql-database/sql-database-high-availability has more details.  

To answer your second question you should view resources in different regions as if they are in separate data centers (which they are).  You can make automatic failover work in these situations by using VPN tunnels and judicious use of cloud witnesses.  However, I would advise against failing between data centers automatically, that should be a deliberate decision.  

But mostly this depends on your HA/DR requirements.  I love Azure and we use it heavily in my current organization, but stretching across datacenters or on-prem/cloud is not as pain-free as Microsoft would have you believe.