the m3 and c3 family are quite similar, save for these key differences:
- higher vcpu:mem ratio on c3
- higher clock rate per vcpu on c3
- ability to scale beyond 8 vcpu on c3
- option of "enhanced networking" on c3/r3/i3 ... will explain that later
For example, here are some cost-comparable instances:
c3.large | 2 | 7 | 3.75 | 2 x 16 SSD | $0.105 per Hour |
m3.large | 2 | 6.5 | 7.5 | 1 x 32 SSD | $0.140 per Hour |
c3.xlarge | 4 | 14 | 7.5 | 2 x 40 SSD | $0.210 per Hour |
m3.xlarge | 4 | 13 | 15 | 2 x 40 SSD | $0.280 per Hour |
c3.2xlarge | 8 | 28 | 15 | 2 x 80 SSD | $0.420 per Hour |
|
m3.2xlarge | 8 | 26 | 30 | 2 x 80 SSD | $0.560 per Hour |
|
If core count is more important than memory (routing applications often don't require a lot of ram), then c3 is a clear win. In addition, the c3 types support "enhanced networking" in HVM mode, which allows the ixgbevf driver (if properly installed), to virtualize the NIC, and provide multiple hardware interruptes into the VM. It's perfect for high network I/O, like routing applications need, and won't over-saturate a single vcpu with too many interrupts.
I am testing the CSR1000V today. I hope to see Cisco has a compatible ixgbevf driver in their AMI, but I'm not holding my breath.
For most of my applications, I find c3.* to be the ideal instance type for many workloads. I also mix in some r3.* for memory-pigs like redis.