I would suggest that SQL database can be counted off to a large degree. storage is a much more cost effective way to store images which are essentially blobs, however - depending on your needs you might want to store metadata on the blobs in sql to assist in querying
If that is the case using a service layer can assist encapsulating the two paths - storing the blob and storing the metadata
Having said that, passing large blobs through a service is very inefficient and so, for the images themselves, phone->storage is perhaps the most compelling approach and will be the most efficient way to do so both from a coding perspective, solution components and responsiveness; the main downside with that is that it requires the phone app to have the credentials to the storage account, which is a big security risk.
Given all of this you might want to consider a combined flow -> phone->service to store metadata and receive a shared access signature token to the blob and then phone->storage, using the SAS token received, for the photo itself
you will need to handle failures in this flow to update the metadata accordingly...
slightly more complex, but with a good balance between security and performance?