Why Stacking Encryption Layers Slows Your Migration
And What to Do Instead
A Technical Guide to TLS, IPsec, MACsec, and Object-Level Encryption for Cross-Cloud Data Transfers
By Raj Sharma, Founder, Server General
When organizations move regulated data between cloud environments, the first question is usually: “Is it encrypted in transit?” The answer is almost always yes. AWS DataSync and GCP Storage Transfer both encrypt data using TLS by default.
But “encrypted in transit” is not a single thing. There are multiple layers of encryption, each operating at a different level of the network stack, each protecting against different threats, and each carrying its own operational cost. When security teams try to achieve maximum protection by stacking these layers, they often discover a painful trade-off: more encryption can mean less speed.
This guide walks through the three primary layers of transport encryption — TLS, IPsec, and MACsec — explains what each one protects and what it doesn’t, and introduces the concept of object-level encryption as an alternative that avoids the performance penalties of transport-layer stacking.
To understand the trade-offs, you need to know where each protocol operates in the network stack.
TLS (Transport Layer Security) is the most common encryption protocol in use today. It secures a specific connection between an application and a server — it’s the “S” in HTTPS.
What it protects: The data payload — the actual content being transferred. An observer cannot read the files or objects being moved.
What it doesn’t protect: IP headers and TCP headers remain visible. An observer can see the source and destination IP addresses, the frequency of transfers, and the volume of data being moved. This metadata can reveal which servers are communicating, how often your organization performs backups, and which specific cloud environments are involved.
How CSP tools use it: AWS DataSync encrypts all data in transit using TLS. GCP Storage Transfer uses HTTPS/TLS 1.3 for all communication. This is the only layer these tools provide natively. IPsec and MACsec depend entirely on how you have configured your underlying network.
The termination issue: TLS is typically terminated at the CSP’s service endpoint — a load balancer, gateway, or the managed service itself. After termination, the service decrypts the data to process the transfer: checksumming, routing, and writing to the destination. During that processing window, data exists in plaintext in the CSP’s application memory. This is architecturally unavoidable for any service-managed transfer.
This creates what auditors increasingly call a Service-Managed Trust Gap. Even if the CSP re-encrypts the data for internal routing after termination, there is a window — however brief — where your regulated data exists as plaintext in the service’s application memory, outside your key controls and outside your audit scope. The CSP’s BAA acknowledges this architecture; it does not eliminate it.
IPsec encrypts data at the network layer, creating an encrypted tunnel between two IP endpoints — typically two VPN gateways.
What it fixes: IPsec encrypts the entire packet, including headers. The metadata exposure from TLS goes away. An observer sees two gateways communicating, not individual servers or the nature of the traffic inside the tunnel.
What it costs (operationally): IPsec is primarily software-based. It consumes CPU cycles on cloud instances, adding latency and reducing throughput — a material concern when transferring large regulated datasets.
But the bigger cost is key management. To run IPsec between two cloud environments, you need to coordinate IKE (Internet Key Exchange) parameters, pre-shared keys or certificates, and key rotation schedules across two different CSPs — with different configuration interfaces, different APIs, and different failure semantics.
When a key expires or a configuration mismatches, the tunnel drops and the transfer fails. That’s infrastructure your team now owns, monitors, and troubleshoots at 2 AM. AWS Site-to-Site VPN and GCP HA VPN make this possible, but not simple.
Availability: IPsec is available to any organization willing to configure and maintain VPN tunnels. It is not enabled by default in any managed transfer service.
MACsec (IEEE 802.1AE) operates at the data link layer. It encrypts the entire Ethernet frame — including IP headers — at near line-rate with almost zero latency, because it is implemented in the network interface card hardware, not software.
What it adds: Wire-level encryption between two directly connected devices. No software overhead. No CPU consumption. Everything on the physical link is encrypted.
The hop-by-hop reality: MACsec is point-to-point. At every router or switch in the path, the MACsec envelope is stripped, the device reads the data to determine the next hop, and then re-encrypts it for the next segment. Data exists in plaintext in router memory at each hop. MACsec protects the wire between hops. It does not protect the data at the hop itself.
The hardware gate: MACsec is only available on dedicated connections at specific bandwidth levels — 10 Gbps and 100 Gbps for AWS Direct Connect, with similar requirements for GCP Cloud Interconnect. Most organizations transferring regulated data between clouds are not at that scale. If you’re not on a dedicated high-bandwidth connection, MACsec is not an option for you.
The cost: Historically, dedicated interconnect ports cost thousands per month before accounting for cross-connect fees, colocation, and the corresponding interconnect on the second CSP’s side. In late 2025, AWS and Google Cloud announced a joint cross-cloud interconnect service (currently in preview) that significantly simplifies provisioning — eliminating manual cross-connects and enabling on-demand dedicated bandwidth in minutes rather than weeks. This is a welcome development. However, pricing has not yet been announced, the service is not yet generally available, and the underlying encryption model has not changed: the service uses MACsec between edge routers, which means the hop-by-hop architecture still applies.
Some teams attempt to use all three layers simultaneously — TLS + IPsec + MACsec — as a defense-in-depth strategy. The security logic is sound. The engineering reality is painful.
When organizations attempt to layer all three encryption protocols simultaneously, they encounter real engineering costs. The most significant is IPsec tunnel mode fragmentation, but the operational burden extends beyond packet sizes:
The primary source of fragmentation is IPsec tunnel mode. When IPsec wraps an entire 1500-byte IP packet inside a new packet with ESP headers (approximately 50–70 additional bytes), the resulting packet exceeds the standard 1500-byte MTU. The router must fragment it — splitting it into two smaller packets, creating duplicate headers, and requiring the receiving end to reassemble both pieces before the application can process the data. TLS operates within the TCP payload and generally adjusts its record sizes to fit, reducing effective throughput without causing IP-level fragmentation. MACsec adds overhead at the Ethernet frame level (Layer 2), which MACsec-capable hardware is designed to handle.
This is not a minor overhead. Fragmentation forces the network hardware to do significantly more work for the same amount of data. Transfer throughput degrades substantially — turning a high-speed link into a slower pipe. For organizations moving large regulated datasets (clinical data, genomic data, financial records), this is the difference between a transfer that completes overnight and one that takes days.
And fragmentation doesn’t just affect speed. Each encryption layer introduces its own key rotation cycle, its own configuration surface, and its own potential point of failure. You’re not just paying a performance tax — you’re paying an operational complexity tax.
Whether you use TLS alone or all three layers together, every transport encryption protocol shares the same architectural limitation: it protects the pipe, not the object inside it.
Transport encryption is session-based and ephemeral. It exists for the duration of the connection and disappears when the session ends. It cannot answer the question that regulated industries increasingly need answered:
Can you prove, with your own keys, that the object at the destination is the same object that left the source?
CSP transfer tools perform checksums to verify data integrity — that’s expected. But the CSP computed the checksum, performed the transfer, and verified the result. The CSP is vouching for itself. For most use cases, that’s sufficient. For regulated industries where you need to demonstrate compliance to an auditor, the question shifts from “did the bits arrive intact?” to “who could have seen them along the way, and can you prove it?”
This is the gap that transport encryption — at any layer — cannot close. And it’s the gap that object-level encryption was designed to fill.
Object-level encryption changes the unit of protection from the session to the object. Instead of encrypting a stream of packets between two endpoints, you encrypt each individual object with AES-256 using keys the customer owns — before the data enters any transport layer.
This approach has several practical consequences:
The pipe becomes a commodity. When the object itself is encrypted before it hits the network, the security of the transport layer becomes secondary. You can use TLS (which is free and automatic) without needing to layer IPsec or MACsec on top. No IPsec means no tunnel-mode fragmentation. No MACsec means no hardware dependency. The packet stays standard-sized, and throughput remains at full line-rate.
The CSP handles ciphertext, not plaintext. The “plaintext peak” that occurs when a managed service decrypts data for processing goes away. The CSP’s infrastructure processes encrypted ciphertext at every stage. Even during the transfer processing window, the data is unreadable without the customer’s keys.
Hardware independence. You don’t need 10 Gbps dedicated connections to get strong encryption. Object-level AES-256 protects the data whether it travels over a dedicated fiber link or the public internet. This eliminates the MACsec hardware gate for organizations that aren’t at that bandwidth scale.
Key separation. The customer controls the encryption keys through their own Key Management Service (AWS KMS, GCP Cloud KMS). The service that manages the transfer never holds the keys to decrypt the data. This is a fundamental separation of duties: the logistics of movement are decoupled from the authority to read the data.
Persistent, verifiable proof. Because encryption happens at the object level, you can hash and sign each object independently. This enables a cryptographic manifest — a tamper-evident record that ties a specific object to a specific transfer with a specific integrity proof, verifiable by anyone who holds the public key. No phone calls. No vendor portals. No trust required.
Stacked Transport Layers (TLS + IPsec + MACsec)
Object-Level Encryption (AES-256)
Security Model
Protect the pipe — security depends on the transport path
Protect the object — security is baked into the data itself
Packet Overhead
IPsec tunnel mode causes packets to exceed MTU, triggering fragmentation
Standard packet sizes — no additional headers, no fragmentation
Throughput Impact
Degradation from IPsec fragmentation and software processing overhead
Full line-rate — encryption is in the payload, not the transport
Key Management
Three separate key systems across two CSPs
Customer-owned keys in their own KMS
Hardware Requirements
MACsec requires 10/100 Gbps dedicated connections
Works over any connection — dedicated, VPN, or public internet
CSP Visibility
Data is plaintext during CSP processing (TLS termination)
CSP handles ciphertext at every stage
Audit Evidence
CSP logs — CSP vouches for itself
Cryptographic manifest — independently verifiable
Transfer General is a managed cross-cloud data transfer service built on object-level encryption with customer-owned keys.
Every object is encrypted with AES-256 at the source using keys from the customer’s own KMS before it enters any transport layer. The encrypted object is then transferred to the destination, where it is verified against a cryptographic manifest that records the state of every object at the moment of encryption and the moment of arrival.
This is possible because of how Transfer General handles encryption keys. A plaintext Data Encryption Key (DEK) is retrieved from the customer’s KMS solely to seal the object at the source. Once encryption is complete, the plaintext DEK is immediately purged from memory — before the transfer begins. From that point forward, the transfer pipeline carries only ciphertext and an encrypted (wrapped) DEK that it cannot itself unlock. The wrapped DEK can only be unwrapped via a direct call to the customer’s KMS at the destination. This means the transfer service is architecturally incapable of reading the data in transit — not by policy, but by design.
This manifest is not a status log — it is a hard gate. An object is not moved to the destination bucket on the basis of a network success signal. It is promoted only after a destination-side cryptographic challenge confirms the object matches the source manifest exactly. This turns what would otherwise be a vendor-attested transfer record into independently verifiable proof of integrity — math the customer can hand to an auditor without asking anyone to take anything on trust.
Transfer General runs inside the customer’s VPC and never accesses customer data in plaintext. The service manages the logistics of movement. The customer retains the keys.
For organizations in healthcare, research, pharma, and government — where HIPAA, FedRAMP, and FISMA require demonstrable compliance during data transfers — object-level encryption with cryptographic attestation provides a level of evidence that transport encryption alone cannot match.
Transport encryption is essential. TLS should always be enabled. IPsec and MACsec have legitimate use cases for organizations with the infrastructure and operational capacity to support them.
But stacking transport layers as a substitute for object-level security creates real costs — IPsec fragmentation, key management complexity across two CSPs, hardware dependencies for MACsec, software processing overhead, and throughput degradation — without closing the fundamental gap: the CSP’s managed service still processes your data in plaintext, and the evidence of transfer integrity remains under the CSP’s control.
Object-level encryption with customer-owned keys changes the equation. It protects the data regardless of which pipe carries it, eliminates the performance penalties of transport-layer stacking, and provides independently verifiable proof of integrity.
Transport encryption protects the pipe. Object-level encryption protects what’s inside it.
To learn more about Transfer General and object-level encryption for regulated cross-cloud data transfers, visit servergeneral.com or contact us at info@servergeneral.com.
If you are representing one of our partners, please log into your account to access hidden resources or request an invitation to sign up for the account.
.png)
Want to be notificated about new features and updates? Enter your email adress and name below to be the first to know.
Don't worry! You will not be spammed!
%201.svg)
.svg){kind=logo}
.png)
.png)