Group by month taking significant time
INDEX(source_id, date_time, value) is optimal, partially because it is "covering".  "Covering" means that the query can be completely handled by the columns in the index.  I am assuming you did not water down the query?
The column tested by = must come first, regardless of cardinality.  Else, If date_time is first, it will have to read the entire index.
The EXPLAIN estimates that source_id = 2 44% (4418476/10M) of the time.  Reading 4M rows is a lot better than 10M.
Please provide SHOW CREATE TABLE; without it, I am making guesses in my Answer.
Both of your attempted indexes have to bounce between the index BTree and the Data BTree.
Probably between 1GB's and 4GB's worth of blocks (16KB - data or index) needed to be pulled into cache (buffer_pool) to satisfy your query.  Probably it was entirely in the 4GB buffer_pool when it took 7s.  And in the 1GB, there was not room, so it was at least partially I/O-bound.
The suggested index will easily fit in 1GB buffer_pool.  And only 44% of it is needed for this query.
When you add my composite query, get rid of the existing one that is a prefix of it; it will be redundant and unnecessary.
As your data grows, someday the index will become too big for 1GB.  That's a fact of life.
However, by building and maintaining a [Summary table(http://mysql.rjweb.org/doc.php/summarytables), you can make the equivalent query take less than 1 second on either server, even as the table grows.  (It would probably have 3 columns: source_id, date (no time), and sum(value).)