How important is it to verify the replication of (already verified) disk-based backup sets to cloud?

My company is a little bit behind on the adoption of cloud technology; there hasn't been a compelling need to change anything.

Anyway, I was hoping to at least modify my disk-to-disk-to-tape backup scheme to a disk-to-disk-to-cloud one.   Having to change tapes is a pain, especially now since I have to make a special trip into the office to do it.

There's no way to "budget" anything until I have some sense of how much this would all cost. Amazon has cost calculators, but they ask for metrics I have no way of getting at.   

So as a test, I created an AWS S3 bucket and did some test Duplicate jobs from existing backup sets to the bucket.  

The first ~15.5 GB backup set cost $1.59 to duplicate to 1Z-IA.  So a full 3 TB backup would scale up to approximately $320 every week. Plus, with a 4-week retention period, 12 TB of data storage would be another $120/mo. That would be a nonstarter with management.

Then I dug into the Amazon Cost Explorer and found that most of this ($1.38) was Data Transfer out.   The cost appeared because the duplicate job did a Verify, and to do that, the Backup Exec server had to read all that data back in from AWS.  I verify the duplicate to tape because there's no cost to that.

If I skip the Verify, the weekly cost for AWS backups would drop a lot.   A subsequent 70 GB Duplicate, without the verify, cost about 25 cents.

What would I lose if I skipped the verify? The backups to local disk would still be verified as part of the job that creates them.  There's some error correction built into Ethernet, would that remove the need?

Getting rid of tapes, I could restructure the backups to do incremental forever, so I wouldn't need to keep 4 full backups in local storage or in the cloud.   But I'd like to first estimate costs using the closest structure to existing practice.