I am currently using Memory optimized DB class in AWS (8 CPUs) because some push notifications in our app cause the CPU utilization to skyrocket, but 99% of the time CPU utilization is at about 10% so 8 CPUs aren't really needed most of the time.
Would I be able to deploy less CPUs on a Burstable Instance and have CPUs adjusted when there are those heavy traffic push notifications?
How do Burstable Instances work?
CodePudding user response：
I wouldn't choose a burstable instance for any production traffic.
The burstable instance accumulates a number of "performance credits" per hour. These credits can be consumed when traffic increases and you needs a significant amount of resources. When the credits are spent, the instance still runs, but has only "baseline performance" which is, frankly, insufficient to handle production traffic.
I've seen many users try to economize by using the T family of instance types. They are usually quite disappointed, because they underestimate their need for resources. They end up consuming their burst credits too quickly, and then operate at the baseline performance level too often.
I'd use a burstable instance only for CI testing servers, or development. These instances typically run idle most of the time, and accumulate a good level of performance credits. They use these credits for brief periods, and then return to an idle level of activity.
You can also look into Aurora Serverless. This is supposed to auto-scale more replica instances in response to traffic increases, which should give you more CPU capacity. You only pay for the instances you use. That's the theory, but I can't speak from experience because I haven't used or tested Aurora Serverless. How well it works and how economical it is for you depends on your application's workload. All I can suggest is to give it a try.
CodePudding user response：
I believe most RDBMS, particularly MySQL, can only be scaled "vertically", in the sense that you can't dynamically add/remove CPU resources to handle bursts of reads/writes.
Perhaps you can create a "notification/fanout" service which is more easily dynamically scaled up and down, using perhaps DynamoDB or AWS SNS. This way your primary database can avoid all of that traffic and in turn you can use a much less expensive EC2 instance for your RDS.