Executive Context
Regulated cross-cloud data transfers fail not because data cannot be moved, but because organizations cannot later prove—at the object level—how data was protected, which cloud identities had access, and whether integrity was preserved while data crossed cloud boundaries.
Cloud-native tools can move data between AWS and Google Cloud. They do not produce a defensible, object-level chain-of-custody that spans competing cloud providers, nor do they provide immutable, unified transfer records. No cloud provider can attest to who accessed or handled data once it entered a competitor’s environment.
Transfer General exists to close this gap — only for transfers it executes.
The Core Challenges for Regulated Cross-Cloud Transfers
For regulated workloads (healthcare, financial services, government, and similar environments), a transfer is complete only when an organization can demonstrate:
- A defensible, object-level chain-of-custody across cloud boundaries
- How data was protected at the object level during staging and transfer
- How integrity was preserved and verified
- That audit evidence is immutable and tamper-evident
- That responsibility for execution and proof is clearly assigned
These requirements cannot be reconstructed after the fact. They must be enforced and recorded during execution.
How AWS → GCP Transfers Are Commonly Executed Without Transfer General
Fragmented security controls
Teams assemble AWS-native and GCP-native transfer mechanisms and are responsible for:
- Relying primarily on transport-layer encryption
- Determining whether object-level encryption is required
- Configuring and operating KMS independently in AWS and GCP
- Defining and maintaining IAM permissions on both sides
Cloud providers do not encrypt objects at the object layer during transfer. Security posture depends on customer implementation and ongoing correctness.
Provider-scoped, mutable evidence
During transfer:
- AWS generates AWS-side logs
- GCP generates GCP-side logs
- Checksums confirm delivery success
What is not produced:
- A single object-level transfer record
- Immutable, append-only audit evidence
- A unified view of how data was protected across clouds
Audit evidence must be reconstructed by correlating multiple independent systems.
Broken chain-of-custody
Even when delivery succeeds:
- AWS cannot attest to who accessed data inside GCP
- GCP cannot attest to how data was accessed or prepared inside AWS
- Neither provider can attest to custody inside a competitor’s environment
Organizations can demonstrate arrival, but cannot establish a cross-cloud chain-of-custody.
Ongoing operational responsibility
Transfers require active oversight:
- Failures must be diagnosed and retried
- Full object re-transfers are common
- Internal teams retain long-term responsibility for explaining outcomes to auditors
How Transfer General Executes the Transfer
Transfer General is deployed within the customer’s AWS and GCP accounts and executes the transfer as a managed, regulated-grade service.
Execution flow (object-level)
- An object is written to a customer-controlled source bucket in the source cloud account
- A checksum is captured on the plaintext source object
- The object is encrypted at the object layer using customer-controlled KMS keys
- The encrypted object is staged inside the customer’s source cloud account
- The encrypted object is transferred to a landing bucket in the destination cloud account
- The object is decrypted and integrity is verified
- Offset-based re-transfer is used if failures occur
- The object is finalized in the destination bucket and removed from the source bucket
All buckets (source, staging, landing, destination) are deployed inside the customer’s cloud accounts. Data never enters Server General–owned infrastructure.
Object-level chain-of-custody
For each object transferred, Transfer General:
- Binds execution to the cloud identities and permissions in effect
- Captures integrity state before encryption and after decryption
- Records encryption, transfer, decryption, verification, failure, and retry events
Execution events are accumulated into an object-level transfer manifest tied to that specific object instance. The manifest is finalized only after successful integrity verification and then written to immutable, append-only storage.
Deterministic integrity verification and retry
- Integrity is verified before encryption and after decryption
- Objects are finalized only after verification succeeds
- Transfer failures trigger offset-based re-transfer of missing data
- Retry behavior and outcomes are explicitly recorded
Attestation with explicit scope
Upon successful completion:
- Transfer General cryptographically signs the finalized, immutable object-level transfer record
- The signature attests that the recorded events accurately represent the transfer executed by Transfer General
- The attestation applies only to transfers executed by Transfer General
Why This Use Case Exists
Regulated organizations cannot rely on inferred custody, mutable logs, or post-hoc explanations for cross-cloud data movement.
Transfer General exists to execute regulated AWS → GCP transfers, encrypt data at the object layer with customer-controlled keys, produce immutable object-level transfer records, and stand behind the accuracy of those records — only for the transfers it executes.
%201.svg)
.png)
