A compliance requirement states that traffic must be encrypted in transit. Your platform terminates TLS at the edge and speaks plain HTTP internally. How would you decide between leaving it as is, re-encrypting to every backend, and passing TLS through to the origin?

## Read the control before drawing the diagram The phrase "encrypted in transit" is doing a lot of work and is almost never self-explanatory. Different frameworks and different auditors mean: over public or untrusted networks only; across any boundary the organisation does not control; between every pair of components; or between components handling a specific data class. The engineering answers to those four are not the same, and choosing a topology before resolving the wording is how teams end up re-encrypting a hop nobody cared about while leaving a cross-region link in the clear. So the first move is to get the control's actual text, its scope statement, and — if there is a live audit — the auditor's interpretation, in writing. The second is to establish what data the control is about, because scope usually follows the data class rather than the hostname. ## Map the segments, not the products Then enumerate the wire segments a request actually crosses, and mark each with who owns the wire and whether it leaves a boundary: - client to edge (public internet — never in question), - edge to service tier (in-rack, cross-zone, or cross-region — very different answers), - service to service, - service to datastore and cache, - anything crossing into a third party, another account, or another provider. The segments that matter most are usually the least visible: a replica link to another region, a managed service reached over a shared network, an agent shipping logs. A tidy re-encryption story for the front door means nothing if the audit trail leaves over a plaintext connection. ## The three options against that map **Leave the internal hop plaintext.** Defensible only when the control's scope genuinely excludes the segment *and* the boundary is enforced rather than asserted — the network path is restricted, nothing else shares it, and there is a control that fails closed when someone changes it. The honest version of this argument names how it is enforced. "It is internal" is not an argument; "the segment is a dedicated link nothing else can route to, verified by a policy that fails closed" is. **Re-encrypt.** The common answer. The edge keeps every L7 capability — routing, inspection, caching, retries — and the wire is encrypted. The real costs are a second certificate lifecycle across the fleet and the discipline to *verify* the backend certificate rather than merely encrypting to it. An internal CA with short-lived, automatically renewed certificates makes this sustainable; a manual internal PKI makes it a recurring outage source. Budget for the automation, not the CPU. **Passthrough.** This answers a different question. It is not "more encrypted" than re-encryption on the wire; what it uniquely provides is that the edge never holds the key and never sees plaintext. Choose it when the edge is operated by someone else, when key custody must stay with one team or in specific hardware, or when you want the edge tier out of audit scope entirely. You pay for it in edge capability — no path routing, connection-level balancing only, no header insertion — and in distributing certificates and keys to every origin. ## What I would actually recommend A per-route decision, not a platform-wide mode. Terminate at the edge for the L7 work; re-encrypt on any segment that leaves a trust boundary — zone, region, account, provider — and for any route carrying data in the control's scope; keep passthrough for the specific routes where key custody or audit scope demands it. Mixed modes are normal and are usually cheaper than the uniform answer. Before committing I would pressure-test three things. Does this reduce audit scope enough to be worth its operational weight — sometimes re-encrypting a tier is cheaper than arguing about a boundary for two years. Does it survive change: who notices when a new service joins the plaintext segment, and what fails closed. And what does it cost in incident response — every encrypted hop is one you can no longer read in a packet capture at 2am, which pushes the burden onto structured logs and tracing that must exist beforehand. ## The organisational half The technical choice is the smaller half. The larger half is deciding which tier is permitted to hold private keys and see plaintext, who operates it, and how that is proven repeatedly rather than once. If a platform layer can make an encrypted, mutually authenticated hop the default that teams get without doing anything, that is usually a stronger long-term answer than a per-service configuration standard — because a standard degrades and a default does not. That trade, and not the cipher list, is what the question is really asking.