AWS RDS Optimized Memory vs Burstable Instance

Question

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?

Answer 1

Try ServerlesV2 configuration, it is low cost as well.

Answer 2

While the answer given by @Bill Karwin, is correct about how burstable instances work, it can't be disregarded for your requirement. As you mentioned your RDS utilization is ~10% the burstable instanse offers a better option at ~20% less cost.

Consider your scenario where you are using 8 vCPU memory optimized instance. For eg: db.t4g.2xlarge. This will cost you $0.3721/h for a reserved postgres instance. But if you choose burstable db.m7g.2xlarge instance of same compute capacity, this will cost you $0.5190/h which is ~28% higher!

With db.t4g.2xlarge you will get a baseline performance of 40%. Which means untill your CPU utilization reaches 40% you wont lose credits. You will get 192 credits/h for being under 40% CPU utilization. 1 CPU credit = 1 vCPU * 100% utilization for 1 minute. Which means, you will have 192/8 = 24 minutes of full 8 vCPU utilization every hour! This will fulfil your burst CPU needs easily. Check below comparison for reference.

Answer 3

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.

Note: There is also the "Unlimited" option, which T3 instances use by default. This changes the nature of the burst performance. You can get greater CPU performance over prolonged periods, but you end up paying more for it. To understand the details, read https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html carefully.

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.

Which instance type and options are best for you is greatly dependent on your specific application's traffic pattern. Does it have consistent load, or cyclical load (for example, high load during business hours but less at night)? Is it mostly CPU-bound, memory-bound, I/O-bound, or network-bound? You need to understand your application's resource needs before you can pick the best instance type.

Answer 4

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.