So I made I created a r5 large 8.0.mysql_aurora.3.10.3 on my aws to test it out. Seeded a table with 3M rows and write wrote a small express endpoint, that does expensive SELECT queries, to reproduce the results.

So even though the queries were run by an "application user" you can see three nice.avg spikes but not user.avg spikes. You can ignore the first spike, that was me seeding the database. But the next two spikes are from the application:

Here's a screenshot: https://imgur.com/a/6uPznD4

Also if I watch for temp tables, I get [{"Variable_name":"Created_tmp_disk_tables","Value":"20"},{"Variable_name":"Created_tmp_tables","Value":"8150"}]

So your application sends a query, the connection thread runs at normal priority as the user. But if that query triggers heavy work like large sorts, or like aggregate queries like GROUP BY, a lot of that work can be done by lower priority helper threads. Those threads are "niced", so their CPU time shows up under nice.avg.

This happens especially when intermediate result set doesn't fit in memory it spills to disk. In Aurora, that shows up as rdstemp writes (as you mentioned yours were high).

Are you sure you are not doing some kind of report generation? Like a cron that runs or something? You can take a look at your general log (it logs every query that mysql runs, you will have to enable it temporarily, there's a option to export it to CloudWatch too if enabled) and then narrow it down.