As a third party storage service, that's not hosted on the same server as your PHP or other SSI code, right? If so you're not at risk.
the problem in said client's case was they were storing the images in question in /images/avatars in the same filesystem tree / uri. As such the people injecting the code simply made it so that they could trick it into storing the users's template as:
"/images/avatars/userAvatarRandomHashHere.jpg?" making any further string addition pointless. So when the system did:
include('templates/' . $user['templateName'] . '/common.template.php');
It actually included the jpeg instead of the correct php file.
Mind you I'm paraphrasing here, it was a bit more complicated than that as I forget how they actually made the rest of the URI be ignored. It was more complex than I made it sound, but that's the gist of said attack vector. If you store user uploads in the same directory tree with the same access levels as the PHP running your logic, a minor elevation or hack could use those files to arbitrarily run code.
Same type of attack nabbed the SMF forum software some decade or so ago.
But since you can't include() code from off server, hosting your images on a third party service would in fact be more secure -- at least in terms of this type of attack vector.
It's why I've taken lately to on systems where it really matters setting up a second domain to handle static files separate from the normal security and operational logic. Since you can't include() across domains, it breaks that link. DOES get a bit complicated though and overhead heavy when you want to allow user uploads, but in modern browsers a hint of JavaScript helps alleviate that burden. I just do so in a manner that gracefully degrades scripting off -- sucking down the excess overhead in said cases.