Simply put: DR is up to you (or, more specifically, your app's architecture). There is no way to guarantee recovery to another region. While you might be able to route traffic to another region (whether via Traffic Manager as @Bruno suggested, or your own DNS-based solution), that says nothing about your data. That just deals with external-facing web/api/app tier.
Why do I say it's up to you (your app's architecture)? Just think about how many questions don't have a built-in answer:
- How will you replicate data from a primary region, to ensure it's available in your secondary region? Are you using a data storage service that replicates to alternate regions (e.g. Table/Blob storage)? Are you using VM-based database solutions that require replication to be set up (and then how do you deal with consistency)?
- How will your app operate if it doesn't have data available to it? Does it shut down? Does it go into read-only mode? Does it work with stale data?
- What happens if additional services become unavailable (e.g. email, cache, identity, 3rd-party services, etc.)?
- How will you ensure you're not losing content written to a primary data node, when your secondary nodes are now the only ones available?
- How will you deal with recovery when the primary region comes back online?
- How will you deal with scenarios where multiple regions go offline - will you have additional resources on-premises?
- Etc.
You mentioned Availability Sets, which have nothing to do with DR (as you've surmised). Availability Sets just reduce the chance of your VM cluster going offline, by ensuring VMs are spread across fault- and update- domains.
Bottom line: Disaster Recovery is not something built-in, and will require careful planning, and understanding how your system will (or will not) operate during a failure period.