This seems to be a common problem of t1.*
or t2.*
instances which is acknowledged by AWS support but not resolved yet. Some users are trying to mitigate the issue by restarting the instance with CloudWatch custom alarm monitoring CPU usage. I wouldn't recommend it as this is a temporary solution for RDS Multi-AZ deployments only and CPU spikes will reappear again what I have read so far.
If you are really sure that there are no queries running during the CPU spike periods which could cause them and that other related CloudWatch metrics are fine I would definitely contact AWS support.
Here it is how you can find out running queries:
SELECT * FROM pg_stat_activity;
SELECT pid, datname, usename, query FROM pg_stat_activity;
Here are CloudWatch metrics to check:
read/write IOPS
read/write latency
network throughput
binary log disk usage
freeable memory
queue depth
Further information can be found on AWS forums:
https://forums.aws.amazon.com/thread.jspa?threadID=164532
https://forums.aws.amazon.com/thread.jspa?threadID=169893