一般而言，我是AWS的忠实拥护者，但RDS却不多。
@RolandoMySQLDBA指出了反对它的一些不错的观点。
与EC2上的MySQL相比，我在RDS中看到的唯一优势是能够执行指向和单击快照，克隆和时间点恢复，但是这些不足以弥补失去控制和灵活性的不足，它们最肯定的是不能证明价格较高。RDS在某些方面很诱人，但您最终不能相信自己最终无法解决的问题，因为您无法了解所有活动的部分。
我不喜欢没有SUPER特权。我不喜欢无法跟踪错误日志。我不喜欢无法在数据库服务器上运行“ top”或“ iostat”来查看核心和驱动器如何承受负载。我不喜欢没有访问联邦存储引擎的权限。我不喜欢购买热备用（多可用区）备份主计算机，而我什至无法利用它作为只读副本。当然，对于要成功地将MySQL成功打包并作为RDBMS-in-a-box进行销售的MySQL，必须有所有这些限制的完全合理的解释。唯一的事情是，RDBMS-in-a-box可以“解决” 我所没有的一系列问题 ……并以我的方式陷入困境，从而导致新的问题。
但是，对我而言，使用RDS的绝对优势在于完全缺乏对二进制日志和复制的访问权限。Binlog，尤其是基于行的Binlog是用于小型灾难的出色恢复工具，但是如果您无法访问它们，则对您没有帮助。是否要在办公室中配置本地服务器作为RDS中生产数据库的只读副本？如果驻留在RDS中的数据发生不可思议的事情，则可以从本地备份中获取报表，并进行报告以备灾难恢复？这是一个显而易见而又辉煌的想法。
糟糕，抱歉，无法直接访问复制。当然，您可以支付只读副本的费用……但只能作为其他RDS实例的费用。这不是我书中的价值主张。
更新：MySQL 5.6的RDS中的一项重大更改
与许多原因相比，我仍然更喜欢运行自己的服务器（甚至在EC2中），而不是运行RDS，其中包括缺乏对用户定义功能的支持，无法使用联合存储引擎以及无法拥有一个服务器。额外的连接可用于紧急访问...但是...
亚马逊在RDS的MySQL 5.6中进行了重大更改，消除了我的主要反对意见之一-也许是我最大的反对意见：二进制日志现在可以访问了，您可以将非RDS实例作为从属实例运行，或者将其他实用程序连接到读取binlog流的服务器。
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html
正式而言，文档表明它们正在公开此信息，以便您可以进行实时迁移而设置从属服务器-您可以使用同步来自现有RDS实例的国外将来的主服务器mysqldump，然后将其作为从属服务器连接到RDS。以便通过复制流获得实时更新，直到您的应用程序迁移到新的主服务器上-但在非正式情况下，只要您不希望它们支持您，就可以持续进行此操作...对我来说，似乎很合理。
最近一次网络研讨会上在大约56:45开始的对话中证实了这一点：
“您可以将其无限期地保持在复制状态...
“ ...只要您负责维护复制...”
“如果您要这样做，我们不会阻止您进行正在进行的复制。”
这项新功能足以让我毫不犹豫地拒绝在我们面向公众的网站支持的MySQL实例中使用RDS，在这些实例中我们根本不使用FEDERATED或根本不使用其他任何东西。
所以我仍然不赞成它，但是我不再反对它了，因为拥有二进制日志的实时流最终使我最终回到实时控制数据的状态，并承担确保没有事务发生的责任。在灾难性的停机中迷失了自己，因为我（作为DBA）重新控制了-这正是我想要的。如果第三方供应商指责对方或对其提起诉讼，或者其他任何事情，如果丢失的数据消失在黑匣子内的黑洞中，则该数据不会找回。
管理层似乎喜欢RDS的“想法”，并且不反对成本差异，因此我们现在启动所有带有RDS的新网站。
我承认，即时点和单击时间点恢复是RDS中的一项不错的功能……它不会改变或破坏您的现有计算机，而是使用以前的备份来启动一个全新的实例。在最接近所选时间点的时间，然后应用必要的binlog将新机器带入您指定的时间点。
与此相关，但是在另一个方向上，现在也可以使用类似的策略将实时MySQL数据库迁移到RDS中……您可以连接RDS主服务器（大概，这通常是新部署的）实例）作为现有系统的从属，以便RDS实例在迁移到该实例时具有实时数据版本。与仅用于5.6的对RDS二进制日志进行向外复制的访问不同，RDS从5.5.33和5.6.13开始支持向内复制。