为了简化我们的环境，在最基本的层面上，我们在一台服务器上的 IIS 6 上运行一个 .NET 网站，并且该网站依赖于另一台服务器上的 MS SQL 2005 数据库中的数据。
为了实现 DR，我们在遥远的地理位置复制了此基础架构。我们将 .NET 代码文件 rsync 到远程 IIS 服务器。我们将 SQL 数据记录到远程 SQL 服务器。
看来我们可以在亚马逊云中做类似的事情。使用由 EBS 卷支持的 EC2 机器。这样做的好处是，我们可以以较低的成本使用较小的机器，直到我们真正需要故障转移为止，在这种情况下，我们可以启动更大的机器来处理负载并连接预先存在的 EBS 卷。
该项目仅处于发现/探索阶段，我们可以从社区使用 Amazon AWS 的一些资深经验中受益。我想到的一些立即有用的内容：
有人有在 AWS 上运行 MS SQL Server 2005 的经验吗？对于数据库驱动的网站产生的 OLTP 负载，性能肯定会受到影响，但您的虚拟 SQL 服务器在哪里工作和失败（例如磁盘 i/o 很糟糕……我们可以在物理服务器上处理约 5k 事务/秒，而使用类似规格的虚拟机，我们的容量减半）。
从长远来看，在考虑了在云中运行灾难恢复解决方案的所有意外成本后，您实际上节省了什么钱吗？隐藏的成本在哪里？
如果您以自动化方式将数据移至亚马逊，您将如何处理？平面文件很容易，但如果您运行的是 SQL 或 Exchange，我特别想知道您使用的工具。
有没有办法直接写入 EBS 卷，或者您是否被迫将 EBS 卷附加到 EC2 实例并与操作系统一起工作？
如果你不幸不得不将故障转移到 AWS 来处理生产负载，那么它作为 DR 解决方案的表现如何？显然每个人的恢复目标都不同，所以我想我真的只是想知道 AWS 在哪里相当优雅/有优势，以及它在哪里对你来说很糟糕
其他见解和现实核查都值得赞赏。TIA 花时间与社区和我分享您的知识。