'AWS suggested' way to deal with object lock, glacier, and File Gateway (ie lifecycle logic / lamdbas)

I'm interested (somewhat linked to other questions about how uploads to the Storage Gateway in File Gateway mode work when there is a need to hash data after copying to the NFS share) in the 'AWS suggested' ways to handle the mix of File Gateway, Object locking, and Deep Glacier transitions because it feel like its easy to set up wrong, and treble storage costs inadvertently.

I'm noticing for each upload, two object versions are made.

I read (Here) this is because of the way data is written to NFS where the file metadata is transferred after the file contents (which the storage gateway would have already started to upload). So Before I even start looking at Lifecycle rules I already have two object versions for each file (they both seem to be of the same size, so doubling storage costs out the bat)...... not ideal...

I then want to use a lifecycle rule to move data to Deep Glacier. But then I have one object version in Deep Glacier, and one version in S3 'Standard' (increasing storage costs)....

I want to take advantage of object locking to protect from ransomware 100% (that is after all one advantage of WORM). However, because I now have multiple object versions I need to have lifecycle rules to delete the older versions to save on costs, BUT, if you ONLY keep the latest version, there is a significant risk of ransomware encrypting data waiting to move to Deep Glacier (as lifecycle rules only run once per day). This would create a new 'encrypted' object version, which then potentially gets moved to Deep Glacier as 'the most recent' object, and old versions (ie the un-encrypted version that represents the actually object WE uploaded and is not affected by the ransomware) are then removed leading to a mix of ransomware affected objects in Deep Glacier with no way of knowing which is and isn't...

I hope that scenario makes sense?

We cannot just blindly keep the most recent object version, as it could have been affected by ransomware, but we cannot, and do not, want to keep a million object versions (of which a min. of two object versions are always made because of the way NFS metadata is written 2nd)...

I want to (as a side note) put legal holds onto Deep Glacier objects just because we effectively want indefinite retention, but still have the ability to remove and delete as needed when situations arise.

How do AWS envisage this is supposed to work? I would appreciate some insight as to the types of lifecycle policies, and or lambda functions that would be needed to purely from a 'system logic' perspective (ie rough ideas of what needs to be done, I'm not asking for documented examples - unless they already exist).

Owen.

PS. not having versioning and object locking doesn't help the main aim of protecting the data from ransomware / malicious code as another way to destroy this 'archive data lake' would be to rm -rf from the NFS mount.... which without the object locking / versioning would delete all the data.....