Yes, you can technically support automatic failover in this scenario.
However, there a few things you must be aware of and/or check first.
- To be able to offer automatic failover, your replicase must be in synchronous commit mode.
- when in synchronous commit mode, transaction must be able to successfully commit on your secondary replica before they commit on your primary replica.
Does your WAN offer low enough latency for your transactions to be able to commit in DR first, without causing undesired latency for your production commits?
The next thing you need to worry about is quorum. If you're only planning to have two nodes in your AG, you'll need a file share somewhere (or another form of quorum) to offer a tie-breaker vote. You'd need this file share to be somewhere where both replicas can see it.
Also, when failing over between subnets, you need to make sure your SQL Clients are multi-subnet aware. If they're not, you can face potential timeout issues with the default settings. To avoid that, you'll need to set
RegisterAllProviderIP = 0 at the cluster level, so that SQL is not registering your Prod and DR listener IPs in DNS at the same time. Further to avoid as much as 20 minutes of downtimes while the old DNS records age out in this configuration, you'll also want to lower your TTL down to about 2 minutes or so.
In my opinion, I never want a replica to failover to my DR data center without that action being initiated manually. There are generally a lot of things that need to happen in coordination with that, outside of SQL Server. If you choose to go this route, make sure to test it well.