我们已经推出了主streamCMS软件（如Drupal和WordPress）的标准Web服务器configuration，EC2 / EBS上的服务器和存储以及RDS / MySQL中的这些软件包的数据库。
通常我们会使用t2.micro CPU和db.t2.micro数据库进行生产，这使得客户对我们和AWS感到满意，因为他们经常可以在第一年免费上网。 EC2上的默认监视工具清楚地表明，我们可能会超出Web主机的最有利资源，即CPU利用率 。 如果阈值接近或超过10％，那么我们知道迁移到t2.small实例types的时间已经到来。
我们不太确定如何确定什么时候我们可能需要从db.t2.micro升级到db.t2.small或者更多。 这些要求不涉及多可用区或只读副本，只是当CMS软件可能在高峰期需要依靠图表或警报来定位数据库时严重依赖数据库的条件。
EC2实例的文档清楚地表明了他们自己的限制，我想知道是否可以为我们的简单情况推荐RDS实例的这种限制。 Amazon RDS最佳实践中的一般要求是有帮助的，尽pipe我没有遵循所有的链接，因为我只是设置了一些门槛，我们可以采用这种方式，技术客户可以理解和观察。
我承认我不是DBA; 由于我的工作性质，我已经把数据库架构留给了CMS软件的devise者。 如果有人会告诉我从AWS平台上的这个configuration开始，我肯定愿意学习性能评估的基础知识。 也许我只是还没有find正确的官方文档或教程。
或者，我们只需要知道如何根据我们在CloudWatch上看到的情况来定量衡量是否由于实例大小太小（或者MySQL资源参数设置得太低）而导致访问RDS实例的延迟。
细微的，我可以告诉如果CloudWatch指标Freeable Memory接近零，那么我们需要一个实例升级。 和我们的EC2实例一样，还必须有一个最大的CPU使用率 ，我想这个数字远远低于100％，尽pipe我还没有看到像EC2那样的logging。 我想数据库连接会有一个实际的最大值。 最后，我希望有人会告诉我如何解释写入IOPS和读取IOPS ，如果这些会对我们这样的小configuration施加性能限制，或者它们只是用来计算成本。
ps，我试图在AWS论坛上发布这个：Amazon Relational Database Service，但是Post New Thread链接目前产生一个“redirect循环”。 （对不起，我不能在这里包含更多的url，但我不允许。）
感谢@Ross，我不知道CPUCreditBalance在RDS上也是可用的（我在EC2上看到过它）。 没有看到第二个屏幕有7个指标，全部17个可以从列表中select。 RDS实例types，我仍然想知道除CPU以外的可监视资源，特别是I / O活动可能受到什么限制。
pps，我已经细化了一些问题并发布在AWS论坛上（ 如何确定RDS T2实例是否适合CloudWatch统计信息？ ）
在过去的几个月中，我对此有了一些看法，我相信这些观察项目将解决上述所有问题：
1）来自@Ross的关于原始发布的评论是关键。 T2实例不pipe规模大小，无论是EC2还是RDS，都会在最高CPU需求继续下去时CPU停止运行。
2）我们经常见到的CMSnetworking服务器的故障模式正是由以下情况所显示的：当httpd进程所需的CPU百分比超过分配给该实例types的CPU百分比时，CloudWatchgraphics倾向于零（请参阅下面的文档链接）。
3）对于已经用完CPU信用的T2实例的快速解决scheme是closures，升级实例types，并重新启动实例，大约需要3-4分钟。 不同实例types的能力最重要的描述在这里： http : //docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html
4）由于这个原因，AWS上的任何生产Web服务器都必须预先分配一个弹性IP地址：如果没有，并且实例被重新调整，那么IP地址将会改变，这使得Web服务器远远超出了其他方式， 4分钟的停机时间。
5）获得更多CPU积分的唯一方法是升级机器types。 上面的文档链接中描述了每个T2实例大小可容纳的信用额度：它总是等于实例types在24小时内完成的CPU工作量。
6）在高峰性能需求下降之后，机器可以在一段预定的停机时间（也就是3-4分钟）内恢复到原来的规模。
7）到目前为止，在任何高峰期间，I / O活动都没有导致我们的Web服务器性能下降。 IOPS的数量严格按EBS卷大小确定。 IOPS的确切含义，以及这种关系，在这里描述： http : //docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-io-characteristics.html
8）在Web服务器密集型环境中，无论是使用Cloud Watch还是使用Freeable Memory或DB Connections，都无法预测或纠正性能问题。