我目前在AWS中使用内存优化的DB类(8个CPU)，因为我们应用程序中的一些推送通知导致CPU利用率飙升，但99%的时间CPU利用率约为10%，所以大多数时候并不需要8个CPU。
我是否能够在Burstable实例上部署更少的cpu，并在有那些大流量推送通知时调整cpu ?
突发实例是如何工作的?
我不会为任何生产流量选择一个可爆发的实例。
突发实例积累了一些"性能信用";每小时。当流量增加，你需要大量资源时，可以使用这些积分。当信用额度用完后，实例仍然运行，但只有"基线性能"。坦率地说，这不足以处理生产流量。
我看到许多用户试图通过使用T系列实例类型来节省开支。他们通常很失望，因为他们低估了自己对资源的需求。他们最终消耗他们的爆发积分太快，然后在基线性能水平操作太频繁。
我只会在CI测试服务器或开发中使用可爆发实例。这些实例通常大部分时间都是空闲运行的，并积累了良好的性能积分。他们在短时间内使用这些积分，然后回到空闲的活动水平。
注意:还有"Unlimited"选项，T3实例默认使用该选项。这改变了burst性能的性质。您可以在较长时间内获得更高的CPU性能，但最终要为此付出更多的代价。要了解详细信息，请仔细阅读https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html。
您还可以查看Aurora Serverless。这应该是为了响应流量的增加而自动扩展更多的副本实例，这应该为您提供更多的CPU容量。您只需为使用的实例付费。这是理论上的，但我不能从经验出发，因为我没有使用或测试过Aurora Serverless。它的效果和经济性取决于应用程序的工作负载。我所能建议的就是试一试。
哪种实例类型和选项最适合您在很大程度上取决于您的特定应用程序的流量模式。它是否具有一致的负载，或者周期性负载(例如，在工作时间高负载，但在夜间低负载)?它主要是cpu受限、内存受限、I/o受限还是网络受限?在选择最佳实例类型之前，您需要了解应用程序的资源需求。
我相信大多数RDBMS，特别是MySQL，只能"垂直"扩展，也就是说你不能动态地添加/移除CPU资源来处理突发的读/写。
也许你可以创建一个"notification/fanout"使用DynamoDB或AWS SNS，可以更容易地动态扩展和缩小。这样你的主数据库可以避免所有的流量，反过来你可以为你的RDS使用一个便宜得多的EC2实例。