Need a solution to store cheaply a big MongoDB collection
Short answer - this is a tricky proposition and your available options really depend on how much effort you wish to put in versus the cost of your option 2 (which I will talk about below).  Having never done it, I can't speak to the ease (or lack thereof) of using another cloud based solution for storing the data elsewhere, but I can comment on some of the options on the MongoDB side.

First up, in terms of putting in the effort, a slight twist on your 2 proposals:


Create a less expensive instance in the cloud
Implement aging/removal on the live database (either manually, or with TTL or capped collections)
Use a tailable cursor to pull all operations out of your oplog and insert into your new instance(s).  Alternatively you could look at the Mongo Connector for this functionality to avoid writing it yourself, but that will not work out of the box with TTL (TTL deletes are replicated from the primary and would need to be filtered out manually)


Caveats:


Even though it might be less expensive, it still has to be able to keep up with your operations - you do not want to have it lag behind and end up missing data
This is essentially doing a form of replication yourself, it's not officially supported anywhere - you have to support this yourself
You will need to come up with your own method to detect if this is broken so you can stop deletes, recover from failure, and your own method to restore data etc.
Manual deletes, or TTL based deletes will eventually lead to fragmentation and inefficient re-use of space, so you will probably need to regularly compact and/or repair to reclaim space


The above is usually too much effort/hassle and too much of an unknown from a supportability perspective unless you plan to run this way long term and are very comfortable supporting such a customized solution.  

Your option 2, is often far easier and there are ways to save on costs.  You can, for example, have a hidden secondary that is different from the rest to reduce costs.  Imagine this kind of set up:


Primary, Secondary - both equivalent spec, enough memory to hold working set for live site, generally expensive - uses capped collections to manage data storage
Hidden Secondary - less expensive spec (RAM, slower disk), never takes live traffic, keeps all data, perhaps no indexes also - good source for snapshot backups too usually


To get the hidden secondary set up correctly will take some work.  You need to configure it to not build indexes, you need to pre-create any Capped collections without the capped configuration so they do not delete data (they will then continue to grow).