What could be causing this rogue CPU spike on MS SQL Server running on EC2?
For a start, be aware that memory usage (if based on the simple used memory counter, which it likely is) will probably be always static - and likely (for a SQL Server that has been operating for a little while) be the same as the max memory configured for the instance (SQL Server will grab all available memory and won't release it). 

It's worth just checking my guess here - is the memory used in you monitoring tool the same as the configured max server memory (it might be lower after a reboot and slowly increase to the max, dependent on usage)

The stats in your screenshot indicate memory pressure (or possibly slow I/O, but likely memory). The CPU spike isn't exactly the problem here, just a symptom of a problem. 


A sudden drop in page life expectancy (the length of time a page stays in memory)
A rise in latch wait time (lots of things trying to modify the same page) 
The CPU spike (thrashing pages rapidly in and out of memory because the buffer isn't large enough to hold all pages that are needed).


Seeing these counters, I'd definitely think memory pressure. The reason why can be trickier to diagnose, but the other stat on your screenshot indicates something. All of these indicators corresponded with a spike in user connections to the database, I know you mention that their was nothing unusual about site traffic, something/s were connecting to your db and doing something - a lot of things, it seems. 

The reboot cleared it because it cut all of those connections. Unless you have a history somewhere else showing more in depth information about connections, you're not likely to be able to tell (from SQL server side) what was connecting and doing what - it might be worth investigating any connected apps (looking for a process or something going loopy - but I wouldn't spend too long doing so). I doubt you'll be able to ascertain with any amount of certainty exactly what caused it this time.

For the future, if this occurs again, I'd recommend seeing what is connected (and doing what) before you bounce the box (although I know sometimes the pressure is just to get things working again, but taking a quick look at connections doesn't take long). 

There's a number of ways to do this but a good start would be Adam Machanic's sp_WhoIsActive (Info, Download, Brent Ozar talking about it)

Edit: A bit more
For some more performance monitoring stuff I like Brent Ozar's PerfMon best practices (It's an older post, Sir, but it checks out...). It has a nice video. 



Alternate explanation
Yes, it's always possible the cause is infrastructure issues, and you can't be sure on that without separate hardware monitoring information (and even then you can't really be sure...). However, the spike in user connections corresponding to the other metrics behavior really does point to memory pressure due to a spike in activity (although, never assume it's only one problem).