An $8,000 a month AWS bill is surprisingly high for this service.
Most of the compute cost ($2400) goes to an m4.xlarge and an m5.2xlarge. That could be reduced by using reserved instances - but there's other gotchas there if you're likely to change that anytime soon. Google cloud is much nicer in this regard with the auto discounts for continuous usage.
The provisioned IO for EBS $2500 makes me sick, but may be necessary to get adequate performance.
Honestly you could move everything onto two dedicated servers (one as a hot backup) and cut this down to $1000/month and get better performance. But that's the AWS tax.
I use AWS all the time for work, but I would never build my own business on it.
7k$/month is cheaper than hiring an additional head.
Obviously there's other overhead/costs involved, but surely he could find somebody for 60k+ a year (I make less then that at my current development job but I'm from Michigan)?
I agree though with one of the parents, AWS costs here can likely be significantly reduced. I cut costs in half by (a) reserving instances and (b) thinking about EBS and downgrading / downsizing where possible rather than using the defaults.
Basically, with his skillset, maybe it makes sense. With my skillset I'd rather have the hassles with the dedicated setup.
1) Switch to the newest instance families
2) Save up the cash then reserve your instances.
3) Don't bother with the provisioned iops volume type, just use GP2 volumes large enough to give you the baseline IOPS you need
4) In general you have more block storage and snapshots than I'd expect, maybe that can be cut back?
I am assuming you mean you send from the client UI but the extension talks to your server for scheduling the future sends etc. in which case you shouldn't have that much network bandwidth.
My naive thought is that some frontend JS (without the help of a backend server) would be able to accomplish some of the features.