Your cross-cloud transfer is encrypted.

But do you know which layer of encryption is actually protecting your data — and what each layer can't do?

Most teams stop at "encrypted in transit" and move on. But when you're moving regulated data between cloud environments, the details matter. Here's what's actually happening at each layer — and the trade-offs nobody talks about.

Layer 1: TLS — What you already have.

AWS DataSync and GCP Storage Transfer both use TLS by default. It encrypts the data payload between your application and the CSP's service endpoint. It works. It's automatic. It's the right starting point.

But TLS doesn't encrypt packet headers. An observer can see which servers are communicating, how often, and how much data is moving — even if they can't read the data itself.

And TLS terminates at the CSP's service endpoint. The managed service decrypts your data to process the transfer — checksum it, route it, write it to the destination. During that processing window, your data exists in plaintext in the CSP's application environment.

TLS is the only layer these tools provide natively. Everything beyond this is on you.

Layer 2: IPsec — Hiding the metadata.

Adding an IPsec VPN tunnel between your source and destination VPCs encrypts the entire packet, including headers. The metadata exposure from TLS goes away. An observer now sees two gateways talking — not individual servers.

Here's where it gets practical.

IPsec is software-based. It consumes CPU cycles on your cloud instances, which adds latency and reduces throughput — a real concern when you're moving large regulated datasets.

And key management across two different CSPs is genuinely painful. You're coordinating IKE parameters, pre-shared keys, and rotation schedules across AWS and GCP — two different configuration interfaces, two different APIs, two different failure semantics.

When a key expires or a config mismatches, the tunnel drops and your transfer fails.

That's the infrastructure your team now owns, monitors, and troubleshoots.

Layer 3: MACsec — Hardware-grade, but hardware-gated.

MACsec (IEEE 802.1AE) operates at Layer 2 — encrypting the entire Ethernet frame at near line-rate with almost zero latency, because it's implemented in the NIC hardware, not software.

But MACsec is only available on dedicated connections at specific bandwidth levels — 10 Gbps and 100 Gbps for AWS Direct Connect, similar for GCP Cloud Interconnect.

If your organization isn't at that scale, MACsec isn't an option.

AWS and Google recently announced a joint cross-cloud interconnect service that simplifies provisioning, but it's still in preview with no pricing announced — and the underlying MACsec architecture hasn't changed.

The hidden costs of layering.

Some teams try to use all three simultaneously — TLS + IPsec + MACsec — as defense in depth. The security logic is sound. The practical costs are real.

IPsec tunnel mode wraps your entire original IP packet inside a new, larger packet with ESP headers. A standard 1500-byte packet becomes roughly 1550-1570 bytes — exceeding the network MTU and forcing the router to fragment every packet.

That means double the processing for the same amount of data and measurable throughput degradation for large transfers.

TLS and IPsec are both software-based, consuming CPU cycles on your cloud instances. For large regulated datasets, the processing overhead compounds.

MACsec avoids the software overhead (it runs in hardware), but it requires dedicated 10/100 Gbps connections that most organizations don't have.

Add it all up: software overhead, fragmentation from IPsec, key management across two clouds, hardware requirements for MACsec, and the operational burden of maintaining three separate encryption systems.

That's the real cost of securing the pipe.

The question nobody asks.

Every one of these layers protects the pipe — the transport path between source and destination.

None of them protect the object inside it.

What if instead of stacking more layers on the pipe, you encrypted each object at the source with AES-256 using keys you control — before the data enters any transport layer?

The pipe becomes a commodity. The packet stays lean — no nested headers, no fragmentation, no MTU wall.

The CSP's managed service handles encrypted ciphertext, not plaintext.

And because the encryption lives at the object level, you get something no transport layer can provide: a persistent, verifiable proof that the object at the destination is the same object that left the source.

How many layers of transport encryption is your team managing right now — and what's the throughput cost?