I am in the process of migrating to Amazon AWS and need a SQL server high availability solution. The current licence that I have is SQL standard 2016. At this time Amazon does not support shared volumes for Windows instances. Therefore, I am not able to do a regular SQL cluster fail over solution. This is the one where if the entire server goes down the stand by server picks up the slack and continues writing to the same storage. My only option is high availability always on basic groups. As I am starting to get familiar with this feature I find it very maintenance intensive and can see it becoming a problem when dealing with thousands of databases. In my case I have about 5k databases mostly small in size 600mb or less each. My question is Amazon not a viable hosting environment for a full SQL fail over solution. Is the high availability always on basic groups one per database a viable solution?
Sql-server – SQL server standard 2016 fail over cluster Amazon AWS
awsclusteringfailoversql serversql-server-2016
Related Solutions
Use Database Mirroring. Witness node is optional.
http://technet.microsoft.com/en-us/library/ms190941.aspx
You may configure a failover cluster with virtual shared storage. There are guys who do the VSAN for Windows (however they call it "for Hyper-V" but don't get confused it works bare metal on Windows as well).
Always On is not synonymous with (Always On) Availability Groups and instead is more a marketing term to describe a suite of Microsoft High Availability technologies (which I argue is at best ambiguous). The term actually started out as "Always On" (note the space) a long time ago 
as a pure marketing term (see my graphic as an example), but with the release of SQL Server 2012 was adopted as a wider catch all replacement marketing name for what they called "Hadron" during development (which was specifically Availability Groups) and several other HADR technologies (such as SQL Failover Clustering). The only difference was that when the term was first used, it did not have the trailing space (i.e. "AlwaysOn"). Marketing in their infinite wisdom have now added a space back into the term to add even more confusion :).
The bottom line is that if you completely ignore the use of the term AlwaysOn/ Always On and explicitly refer to the technology Availability Groups/ Failover Clustering/ Database Mirroring etc (or ask people to clarify which technology they are referring to) then you cannot go far wrong.
Related Question
- Sql-server – SQL Server 2016 Standard AlwaysOn group
- Sql-server – Multiple Basic Availability Groups and Performance – SQL Server
- Sql-server – Quorum question for SQL Cluster (Always On)
- Sql-server – Difference between Client Access Name in SQL server Fail over Cluster and Always on availability group
- Sql-server – How to fail over availability groups on multiple remote servers
Best Answer
I did a presentation on this during the summer @ SQL Saturday - LA and you have a few options. In some cases, you need clustering if Mirroring isn't an option and AlwaysOn AGs require cross database (but same instance I believe) transactions using MSDTC on some versions of SQL Server.
Thus in order to provide failover clustering support in AWS I used an AWS Storage Gateway to act as a routable SAN. This was simple to setup and was secured easily via the AWS security groups. We then used mirroring to mirror to Azure and on Azure I used the new SQL and Windows 2016 shared storage direct solutions which are an option for AWS if you use Windows 2016.
Here are the relevant slides on setting up a storage gateway:
-Select the "Storage Gateway" option from the AWS console.
Please note I had to configure both secret and not secret auth for the configuration to work. YMMV
S2D Options For Windows 2016: Here are a few items I had to do with S2D on Windows 2016. Note the hypervisor in this case is Azure but same concept applies:
-These are the S2D requirements for us, read the docs for your environment.