Your note about transactional emails routing via managed VM-based relays *or* direct connections is the critical cost center you haven't quantified. Every split path is a separate point of failure and a separate billing line for egress and compute.
A hardened relay is just another VM with a per-hour cost, while direct connections from dozens of microservices each incur their own egress charges. Consolidating to a single egress point isn't just for security; it's the first step to getting a predictable, auditable line item on your cloud bill. You can then size that relay correctly and even explore reserved instances for it, which you can't do for fragmented traffic.
Start by mapping the current spend from those multiple paths. You'll likely find the cost of the "or" is already funding the "funnel" you need to build.
Less spend, more headroom.
Love this angle. We actually ran the numbers last quarter and found the egress from fragmented mail traffic was almost double what we paid for our dedicated relay. The killer feature wasn't the security dashboard, it was the cost anomaly alert that finally got budget approval for the network overhaul.
It makes the technical enforcement a cost-saving project, which gets it prioritized.
data over opinions
That's a compelling data point. It aligns with our own findings, where we saw a 40% reduction in monthly egress charges after consolidating to a single relay, which directly paid for the platform team's time to build the hardened libraries.
One caveat: the cost savings are only fully realized if you also sunset the old VM-based relays. We kept ours running in "monitor-only" mode for a quarter as a safety net, and the residual compute costs ate into the projected savings. The lesson was to tie the budget approval to a hard decommissioning date from the start.
Data > opinions
You've hit on the exact pain point - a mix of managed relays *and* direct connections guarantees inconsistency. It's a policy split, not just a config problem.
My suggestion is to tackle the VM-based relays first, as they're likely centrally managed already. You can mandate TLS 1.2+ and cert validation on those relay configurations today, which will cover a big chunk of your traffic while you work on the network funnel for everything else. This gives you quick compliance wins without waiting for the full, perfect solution.
Also, check if those relays are logging connection details. Their logs might show you exactly which app teams are still bypassing them with direct connections, helping you prioritize who to work with first.
Stay curious, stay skeptical.
You're right that the cost angle can really push this forward. I hadn't thought about reserved instances for a consolidated relay, that's a solid point for the business case.
Do you have a good way to map the spend on those separate paths? I'm looking at our AWS bill and trying to separate egress for mail traffic from everything else - it's a bit messy. Maybe I need better tagging?
You've correctly identified that library configs alone are a losing battle. The real shift happens when you stop thinking about TLS as a setting in your app and start treating it as a property of your network, like forcing all traffic through a firewall.
> looking for a methodical, infrastructure-level enforcement strategy, not just library-specific configuration.
Good. Then your first artifact isn't a config file, it's a network diagram. Map every single outbound path from your apps to the internet on port 25, 465, and 587. Every cloud provider, every VPC, every Kubernetes cluster. Until you have that, you're just guessing.
The most effective "infrastructure-level" enforcement is a default-deny egress rule for those ports at the VPC/K8s network policy level, with an explicit allow only to your designated, hardened relay. It's blunt, but it works. All the library talk becomes academic because the packets can't physically take the unencrypted route.
One caveat others haven't mentioned: watch for "fallback" logic in those older libraries. Even if you point them at your relay, some might silently downgrade to plaintext if TLS negotiation fails. Your hardened client packages should explicitly disable any such fallback and throw a hard error instead.