Factors would include: Cost, performance, ease of update.
Fusion Tables has storage limitations where AWS/EC2 is fully scalable to 5000TB.
S3 users could only store objects up to 5GB. Amazon Web Services has decided to lift that limit and allow block storage up to 5TB
Fusion storage limits - 250 MB per user account: 1 million characters per cell. And upload limits - 1 MB per spreadsheet, 100 MB per .csv or KML.
[There is no option currently to purchase or upgrade this]
There are some major differences in the two products, so it isn't exactly "apples to apples".
Fusion Tables is extremely easy to use, just load in some data and you can have a Google Map displaying your data in no time. The back-end doesn't matter at all, you just need a place to store data and start working with it. So Fusion Tables is more of a product/solution.
AWS is more infrastructure/environment. It isn't as simple as Fusion Tables, because you don't only manage the front-end, but also need to manage the back-end, as in the case of EC2. If you want to store polygon data, the simplest means on AWS would probably be to fire up a server instance with PostgreSQL/PostGIS and start loading data. So all of a sudden you have a server to administer and a database to configure, optimize, etc. Nowhere as simple as Fusion Tables. And it costs money, whereas Fusion Tables doesn't.
Really it comes down to what you're trying to accomplish. If you're trying to build a simple web map that displays polygons on a map and gives some infowindow functionality to display attributes, Fusion Tables is made for that. If you need a full database with spatial functionality and have multiple clients that you need to build, and maybe an overall IT infrastructure that it will all fit into, then AWS might be the way to go.
Right tools for the job is what it's all about.