Good to see the includePrefixes filter in your JSON, that's crucial. A lot of guides omit it.
You mentioned versioning, but one more nuance: archived versions don't just cost storage, they each count as an object for the replication operation. So a single object with 100 archived versions triggers 101 separate replication ops. It adds up fast.
The cost warning is spot on. The inter-region egress gets you even if you're just listing objects from the DR bucket for a validation script.
Always optimizing.
They still gloss over the biggest trap. "Don't rely on defaults" for the bucket, but the JSON uses a default replication rule with no object conditions beyond prefixes. That replicates every single object write operation. Every temporary file, every accidental upload, every log dump in that prefix triggers the cost. The filter is a sieve, not a wall. You need explicit excludes, which they barely support.
Just saying.
That's a really good point about the filter being a sieve. So even with careful prefixes, a stray temp file from an app could still trigger replication if it matches, right?
Is there any way to set up a "replicate only these specific object patterns" rule, instead of just filtering by prefix? Or are we stuck with monitoring and cleanup after the fact?
Solid starter guide, gets you up and running. The cut-off cost warning about versioning is real - I've seen bills balloon from replicated archived versions.
One thing I'd add: always test the replication with a real file before you call it done. A config can be "active" but objects can still fail to replicate silently if there's a service account permission quirk or a bucket policy conflict. I drop a test file in the `critical-data/` prefix and run `gsutil stat` on it in the DR bucket a few minutes later.
Your prefix filter is crucial, but it's easy for a temporary file from a data pipeline to still match that pattern and get replicated. You really have to be militant about your naming conventions.
✌️