Elbows Up, Shields Up: Protecting Your Data in a Hyperscaler

Pillar 01 · Security

Most companies believe their cloud data is protected because a contract says so.

That's adorable.

If your data lives in AWS, Azure, or Google Cloud, it's reachable under the U.S. CLOUD Act no matter which datacenter it sleeps in. The Montréal region won't save you. The "sovereign cloud" sticker won't save you. The provider's pledge to "challenge overbroad requests" is a litigation posture, not a control. You can't challenge your way out of a court order any more than you can apologize your way out of a body check.

Elbows up. Here are your actual options.

The one distinction worth memorizing

Governance is a promise about what someone will do with your data. Contracts, certifications, attestations. All revocable. All subordinate to a subpoena.

Custody is a fact about who can access your data. Facts don't respond to subpoenas. There's nothing to produce.

Everything below moves you along that spectrum. Most companies are camped at the governance end, roasting marshmallows, telling each other the compliance framework will protect them.

Option 1: Read your own paperwork (free)

Pull up your provider's shared responsibility model and your data processing agreement. Map your actual data against them.

Every organization that does this finds the same thing: the crown jewels are fine, and the backups, logs, and analytics exports are scattered across services with the protection profile of a screen door. You paid lawyers to negotiate the DPA. Nobody checked where the data actually went.

Cost: an afternoon and some humility.

Option 2: BYOK, or "Bring Your Own Key" (cheap)

All three hyperscalers let you bring your own encryption keys. This is better than defaults, and worth doing.

It's also less than the name implies. In most BYOK setups, the provider's key service still performs the cryptographic operations. The key is yours the way your coat is yours after you hand it to the coat check. Warm feeling. Zero possession.

A compelled provider can still decrypt. BYOK protects you from negligence and commingling. It does not protect you from a court order, which is presumably why you're reading this.

Option 3: HYOK, or actually holding the key (moderate)

The grown-up version: keys in an HSM or key manager that you run, outside the provider's control plane. AWS XKS, Google Cloud EKM, Azure's HSM tier. The provider has to phone your infrastructure to decrypt anything, and you get a log every time they call.

Now a compelled provider can hand over ciphertext and not much else. You've moved from a promise to a mechanism.

The costs are real. Latency. Availability coupling, meaning if your key service falls over, your cloud falls over with it. Plenty of services don't support it at all. And your data still gets decrypted in the provider's memory to be processed, which is the exposure that never fully goes away no matter how many acronyms you deploy.

Option 4: Encrypt before it leaves the building (moderate)

Client-side encryption. The hyperscaler stores ciphertext and never meets the key. For backups, archives, and object storage this is mature, cheap, and boring.

The catch: encrypted data can't be queried or processed by the provider's services. This is for data you store in the cloud, not data you compute in the cloud. Every company should be doing this for backups today. Almost nobody is. I've stopped asking why. The answers were depressing.

Option 5: Confidential computing (promising, young)

Hardware enclaves encrypt data while it's being processed. AMD SEV-SNP, Intel TDX, Nitro Enclaves. Genuinely good work, and worth watching.

Two footnotes before you put it on a slide as "solved": the workload support is narrow, and the attestation chain still runs through the provider and the chip vendor. You've shrunk the circle of trust. You haven't emptied it.

Option 6: Structural custody (what we build, hence the bias declaration below)

The last option stops trying to limit what one provider can see and instead arranges reality so that no single provider, in any single jurisdiction, ever holds a usable copy.

Our version at SkyeConnex: data gets erasure-coded into fragments and distributed across independent custodians in different jurisdictions, with a zero-knowledge key hierarchy rooted with the customer. Serve any one custodian with any one country's order, and you get mathematically meaningless fragments. Reconstruction needs a quorum that no single legal process can reach. The cryptography is deliberately boring: AES-256-GCM, post-quantum KEM and signatures per FIPS 203/204, standard erasure coding. Boring is a compliment in cryptography. Exciting cryptography is how you end up in a postmortem.

Nobody has to keep a promise, because nobody is in a position to break one.

The honest trade-off: this is an architecture, not a checkbox. It's for the data where compelled disclosure is a board-level problem. Regulated sectors, government, IP-heavy firms, anyone whose customers have started asking pointed questions with "CLOUD Act" in them. Your marketing site can stay where it is. Nobody is subpoenaing your pricing page.

What to actually do

1. Inventory your data classes against jurisdiction and disclosure exposure. This week. It's an afternoon.

2. Client-side encrypt your backups and archives. This quarter. It's a config change and a key ceremony.

3. Move your most sensitive workloads from BYOK to HYOK where supported.

4. For the data whose disclosure would be existential: stop renting promises. Put it somewhere disclosure is structurally impossible. Build it or buy it, but stop pretending the contract is doing that job.

The hyperscalers are excellent at what they do. Asking their contracts to do a job only architecture can do is not a strategy. It's a hope with a renewal date.

Elbows up. Shields up.

Bias Declaration: I founded SkyeConnex. We build Option 6 and charge money for it. Options 1 through 5 are still good advice, and I would honestly rather you did those than nothing, because the status quo is embarrassing us all.