So it appears that your concern here is the cost. I'm going to assume that jumping out of a hot frying pan (expensive right now) into a slowly boiling pot of water (expensive in 6 months) is not your ideal choice either, so I'll do what I usually do, and try to suggest something that is less about a specific vendor's services, and more about the basic tools, which are available from a multitude of vendors.
Also, do you really mean 1 terabit (1000 gigabits) (per second) of bandwidth consumption, or do you mean the thing the vast majority of people (including some hosting company staff!) actually mean when they say bandwidth: 1 terabyte of data transfer (e.g. per month)?
I'm going to assume you mean data transfer per month, because the other one is just insane.
The data transfer itself shouldn't be that expensive. With a 'traditional' VPS host it's maybe $15 for 1TB of data transfer. For EC2 its gonna be closer to $90. Either way, that isn't where the cost is going - it's whatever they're doing "for" you.
I would suggest you identify how much benefit you get from whatever process they provide for images, and see if you can get reasonable performance from a simpler solution that isn't tied to a single vendor - i.e. I would suggest going back to storing your original assets yourselves somewhere (could be regular server(s), could be S3, could be B2, etc), put a simple image resizing layer in front of it (if that's all it's doing, its probably an afternoon's work for someone), and then put your choice of cache in front of that.
For the cache, you could go with a CDN if you have distributed users, if your users are relatively localised, you could go with a couple of high-memory varnish servers.
If we had some more information (e.g. what is the scale of images stored to images served; that is, how much storage space are you using for your original image set, how many images are we talking about, and how many variations of each image are you potentially using?) it would allow for more informed suggestions.