[ec2-user@ip-10-0-42-228 ~]$ lscpu
  ...
  L1d cache:           64K
  L1i cache:           64K
  L2 cache:            1024K
  L3 cache:            32768K

EDIT: meaning that a larger sized cache wouldn't necessarily deliver better performance (though I think in this case the architectural differences do favor Graviton making better use of cache)

  $ lscpu
  Architecture:                    x86_64
  Model name:                      AMD Ryzen 7 2700X Eight-Core Processor
  L1d cache:                       256 KiB
  L1i cache:                       512 KiB
  L2 cache:                        4 MiB
  L3 cache:                        16 MiB

From Wikipedia (not the best source I know):

“L1 cache size unchanged at 32 KB (KiB) instruction and 32 KB (KiB) data cache per core.“

https://en.m.wikipedia.org/wiki/Skylake_(microarchitecture)

I am hoping Apple does this with their desktop chips: basically take the fastest phone/tablet processor, give it better thermals, and pump up the cache. That would be an easy path to beating Intel on a laptop.

Graviton2 doesn't even have a particularly large total amount of cache, the only part of the cache system that's bigger than both AMD and Intel is the L1D. L1I is the same as AMD, L2 is same as Intel, L3 is smaller than both (talking about current-gen server chips). That L1D can indeed make a big difference in certain workloads though.

The L3 is actually pretty small for how many cores there are, ARM recommends 1-2MB/core for the N1 cores in the Graviton2 and it has 512KB/core. AMD has 4MB per core in Zen2 albeit with a slightly weird setup where the L3 is localized to 4 core clusters.

Graviton2 has 64KB L1 caches and 1MB L2 cache per vCPU, with a 32MB LLC.

Source: https://youtu.be/4jImmuMqnwc?t=1111

We were pulling in millions of emails from the past few years, so we had to do a larger size RDS and we were killed on the IO charges.

We are now just on a medium sized EC2 server.

Do you have suggestions for better ways of doing this?

If you're willing to post a bit more details, I'm sure people could give you some more detailed options. You basically switched from a fully-managed database solution to a fully DIY solution, and I honestly think you might have just over provisioned the RDS instance. I'm willing to bet you can switch back to RDS and get all the benefits there while remaining within budget. You can get a 1-year reserved t3.medium RDS instance with 50 GB of storage for $40/month.

What was our specific server size and setup and costs with RDS? We were using db.t3.medium (1 CPU, 2 vCPU, 4GB RAM), we were using a DB cluster that has 2 instances db.t3.medium overall cost (~$118 monthly) And now with EC2? We are using c5d.xlarge (4 CPU, 20 ECU, 8GB RAM), we are using one instance c5d.xlarge overall cost (~$140 monthly) What was the big cost savings? Our main issue was in I/O (Read and write), we have very high I/O demand so we was paying for I/O and storage (~$600) and the second issue is CPU credit (~$90 monthly) so the total save is ($600+$90+$118)-$140= $668 per month.

Also EC2 performance is better than RDS because we get a very good cheaper than RDS server.

Note: RDS is configuration less and has support while if you want to use EC2 then you need a person to do configuration and support for DB on it.

Also, if you're doing such heavy IO, you might want to also look at I3en instances, which have fantastic IO using local storage.