For the features you mention: Yes, you need meta-data for this. But you don't need to see the payload, a picture of my naked 4 year old kid.
For the features you mention: Yes, you need meta-data for this. But you don't need to see the payload, a picture of my naked 4 year old kid.
FWIW, Proxylity supports plain UDP as well as DTLS so it’s possible to build a paas-through proxy for DTLS to Lambda, for example. But then you’ll need to implement DTLS in Lambda. People have done it, but it’s a heavy lift.
The idea with the DTLS support is protecting content in traffic, and the handling it in your own AWS account. For some cases it isn’t acceptable to have Proxylity or AWS to have any chance to seeing the data. But for the most it’s not a problem and the convenience of what the service provides is worth it.
But I hear the concern. I guess I just expect folks will make good decisions for their use cases.
Not everyone wants to (or their policy allows them to) manage TLS certs directly on their origin servers, and some services only allow plaintext HTTP origins, like AWS ALB/ELB. In that particular case it's "ok" because the load balancer is placed inside your VPC, so cleartext traffic is not visible to other customers or networks.
Also, ESNI/ECH would make TLS passthrough problematic.